From: Andrew S. <an...@ne...> - 2000-10-29 10:35:03
|
enl...@li... said: > Enlightenment CVS committal > > Author : gilbertt > Project : e17 > Module : libs/imlib2 > > > Modified Files: > loader_png.c > > > Log Message: > > png loader now pays head to images "quality" tag, just like the jpeg > loader. Now, the png lib takes values 1-9 for compression. I decided > to standardise loaders on a 1-100 quality value, and do some sums in > the loader to convert to 1-9 compression. That was you can set quality > and not care what file format is used. Sound reasonable? Isn't PNG compression lossless? "Quality" is misleading I think... well, not that I really think it would be a problem ... *shrug* Andrew. -- Andrew Shugg <an...@ne...> http://www.neep.com.au/ "Just remember Basil, there's always someone worse off than yourself." "Oh, really? I'd like to meet him ... I could do with a good laugh." [ Sybil and Basil Fawlty, "Fawlty Towers" ] |
From: Peter K. <pet...@ax...> - 2001-08-12 14:06:24
|
> -----Original Message----- > From: enl...@li... > [mailto:enl...@li...] > Sent: Sunday, August 12, 2001 15:46 > To: enl...@so... > Subject: E CVS: libs/imlib2 gilbertt > > Enlightenment CVS committal > > Author : gilbertt > Project : e17 > Module : libs/imlib2 > > Dir : e17/libs/imlib2/loaders > > > Modified Files: > loader_db.c > > > Log Message: > safer > =================================================================== > RCS file: /cvsroot/enlightenment/e17/libs/imlib2/loaders/loader_db.c,v > retrieving revision 1.18 > retrieving revision 1.19 > diff -u -3 -r1.18 -r1.19 > --- loader_db.c 2001/08/12 13:41:11 1.18 > +++ loader_db.c 2001/08/12 13:45:32 1.19 > @@ -278,7 +278,9 @@ > tmp = strrchr(file, ':'); > if(!tmp) > return 0; > - *tmp = '\0'; > + *tmp++ = '\0'; > + if(!tmp) When will tmp ever be NULL here? strrchr() is not likely to return -1... You didn't mean if(!*tmp) per chance? > + return 0; > strcpy(key, tmp + 1); > if (exists(file)) //Peter |
From: Tom G. <to...@li...> - 2001-08-12 14:36:07
|
* Peter Kjellerstedt (pet...@ax...) wrote: > > - *tmp = '\0'; > > + *tmp++ = '\0'; > > + if(!tmp) > > When will tmp ever be NULL here? strrchr() is not likely to return -1... > You didn't mean if(!*tmp) per chance? Yes I did, sorry, I got 2 hrs sleep last night :) Tom. -- .^. .-------------------------------------------------------. /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | /( )\ | Open Source/UNIX consultant | to...@li... | ^^-^^ `-------------------------------------------------------' |
From: Hendryx <win...@he...> - 2001-10-08 16:35:05
|
> Log Message: > Once more into the breech. /me starts a crowd rouring well done fanfare for Mr giblet! - Hendryx |
From: Marlon S. <ma...@xe...> - 2001-10-09 00:38:22
|
On Mon, 8 Oct 2001 17:34:53 +0100 Hendryx <win...@he...> wrote: > > Log Message: > > Once more into the breech. > /me starts a crowd rouring well done fanfare for Mr giblet! > > - Hendryx /me joins that crowd :) -- /marlon |
From: Franz M. <fra...@mi...> - 2002-04-23 12:52:31
|
On Mon, 22 Apr 2002 enl...@li... wrote: > Enlightenment CVS committal > > Author : gilbertt > Project : e17 > Module : libs/imlib2 > > Dir : e17/libs/imlib2/src > > > Modified Files: > api.c > > > Log Message: > > A bugfix! > > draw_pixel had an inverted test for clipping and so was always calling the > wrong function. > > Will this fix ever see the light of day? Who knows?! :) > Oops. seems like I had way too much beer before writing the function... ;) Well, good you found it :) Maybe it's time to review all the imlib2 api and check for errors... Have fun, Lightman --------------------------------------------------------- Franz "Lightman" Marini Sys Admin and Software Analyst, Dept. of Physics, University of Milan, Italy. email : fra...@mi... --------------------------------------------------------- |
From: Till A. <ti...@ad...> - 2002-04-24 06:32:37
|
# Quoting enl...@li... (enl...@li...): [snipped and copied around] > Could someone with the ability do a release at some point? Lots of users > have reported problems with bug. I briefly talked to raster today and he has no objection to a release. So, Tom, if you gimme a day or two, I'll get back to you on this one, unless someone else volunteers. > Fix bug in ellipse drawing introduced who knows when by who knows who. > > The ellipse code is total shit, but at least now it does what it is supposed > to. Hm, maybe whoever added the ellipse stuff (sorry, I dont remember) could have a look at this and clean it up some before we do the release? Cheers, Till |
From: Christian K. <kre...@in...> - 2002-04-24 11:09:11
|
Till Adam wrote: > > # Quoting enl...@li... (enl...@li...): > > [snipped and copied around] > > Could someone with the ability do a release at some point? Lots of users > > have reported problems with bug. > > I briefly talked to raster today and he has no objection to a release. > So, Tom, if you gimme a day or two, I'll get back to you on this one, > unless someone else volunteers. Cool. Thanks Till. > > Fix bug in ellipse drawing introduced who knows when by who knows who. > > > > The ellipse code is total shit, but at least now it does what it is supposed > > to. Well thank you. Maybe one day you'll grow up enough Tom to handle this professionally and point out these things politely. We've all realized your opinion about imlib2 by now, I'm getting mighty tired of seeing comments like this one from you. There once was a time when *you* pointed at others when their commit comments were rude. Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Tom G. <to...@li...> - 2002-04-24 11:30:28
|
* Christian Kreibich (kre...@in...) wrote: > Till Adam wrote: > > > > # Quoting enl...@li... (enl...@li...): > > > > [snipped and copied around] > > > Could someone with the ability do a release at some point? Lots of users > > > have reported problems with bug. > > > > I briefly talked to raster today and he has no objection to a release. > > So, Tom, if you gimme a day or two, I'll get back to you on this one, > > unless someone else volunteers. > > Cool. Thanks Till. > > > > Fix bug in ellipse drawing introduced who knows when by who knows who. > > > > > > The ellipse code is total shit, but at least now it does what it is supposed > > > to. > > Well thank you. Maybe one day you'll grow up enough Tom to handle this > professionally and point out these things politely. We've all realized > your opinion about imlib2 by now, I'm getting mighty tired of seeing > comments like this one from you. There once was a time when *you* > pointed at others when their commit comments were rude. Um. I should point out at this stage, that the ellipse code is _mine_, and it is my code I am talking about. Noone elses. I never pretended to be a great mathematician. It's no wonder a bug was introduced, the code is and always was a mess, as I pointed out. Please don't tell me off for critisizing my own code :) Tom. -- .^. .-------------------------------------------------------. /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | /( )\ | Open Source/UNIX consultant | to...@li... | ^^-^^ `-------------------------------------------------------' |
From: Christian K. <kre...@in...> - 2002-04-24 11:35:10
|
Tom Gilbert wrote: > > Um. I should point out at this stage, that the ellipse code is _mine_, > and it is my code I am talking about. Noone elses. I never pretended to > be a great mathematician. > > It's no wonder a bug was introduced, the code is and always was a mess, > as I pointed out. > > Please don't tell me off for critisizing my own code :) HAHAHAHA ewps ;) Sorry then. Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Tom G. <to...@li...> - 2002-04-24 19:35:27
|
* Christian Kreibich (kre...@in...) wrote: > Tom Gilbert wrote: > > > > Um. I should point out at this stage, that the ellipse code is _mine_, > > and it is my code I am talking about. Noone elses. I never pretended to > > be a great mathematician. > > > > It's no wonder a bug was introduced, the code is and always was a mess, > > as I pointed out. > > > > Please don't tell me off for critisizing my own code :) > > HAHAHAHA ewps ;) Sorry then. Hey no problem, technically I'm grateful, you defended my code against my own attack on it! Tom. -- .^. .-------------------------------------------------------. /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | /( )\ | Open Source/UNIX consultant | to...@li... | ^^-^^ `-------------------------------------------------------' |
From: Tom G. <to...@li...> - 2002-04-24 11:43:59
|
* Till Adam (ti...@ad...) wrote: > # Quoting enl...@li... (enl...@li...): > > [snipped and copied around] > > Could someone with the ability do a release at some point? Lots of users > > have reported problems with bug. > > I briefly talked to raster today and he has no objection to a release. > So, Tom, if you gimme a day or two, I'll get back to you on this one, > unless someone else volunteers. Fanastic. Thanks. > > Fix bug in ellipse drawing introduced who knows when by who knows who. > > > > The ellipse code is total shit, but at least now it does what it is supposed > > to. > > Hm, maybe whoever added the ellipse stuff (sorry, I dont remember) could > have a look at this and clean it up some before we do the release? I did the ellipse code. However it used to be a lot more complex because it would antialias the ellipses if context_aa was set. As you can imagine, the fill/draw ellipse functions were much more complex when they had to do AA too. I also did the polygon code, and I never got AA working 100% for polygons - math, drawing and algorithms for AA are just not my forte', so it wasn't great work. Raster tore all the AA out of polygons deciding it was too hard a problem - at the same time he removed the AA code from the ellipse stuff (which worked, but it's silly to do AA ellipses and not polygons). That's when the bugs were introduced, the ellipse code still does all the pre-AA setup and doesn't do the AA, hence the mess, hence the clipping bug. It's nobodies fault, I was just pointing out that the ellipse code could use a rewrite. (I said it was shit because it really is shit, I wasn't trying to offend anyone, although I seem to have offended cK). However, my priority was to fix the bug as reported, as I did. I didn't want to rewrite the ellipse code as I'm the one who did a shitty job in the first place and I didn't want to break imlib2 when it's not really being maintained by the author any more. Tom. -- .^. .-------------------------------------------------------. /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | /( )\ | Open Source/UNIX consultant | to...@li... | ^^-^^ `-------------------------------------------------------' |
From: Christian K. <kre...@in...> - 2002-04-24 11:53:12
|
Tom Gilbert wrote: > > That's when the bugs were introduced, the ellipse code still does all > the pre-AA setup and doesn't do the AA, hence the mess, hence the > clipping bug. It's nobodies fault, I was just pointing out that the > ellipse code could use a rewrite. (I said it was shit because it really > is shit, I wasn't trying to offend anyone, although I seem to have > offended cK). Nah, no worries. Allow me to say that I'm having a tremendous headache today :) I'm glad to see you talking this neutrally and calmly about imlib2, really. Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Tom G. <to...@li...> - 2000-10-29 17:30:42
|
* Andrew Shugg (an...@ne...) wrote: > enl...@li... said: > > Enlightenment CVS committal > >=20 > > Author : gilbertt > > Project : e17 > > Module : libs/imlib2 > >=20 > >=20 > > Modified Files: > > loader_png.c=20 > >=20 > >=20 > > Log Message: > >=20 > > png loader now pays head to images "quality" tag, just like the jpeg > > loader. Now, the png lib takes values 1-9 for compression. I decided > > to standardise loaders on a 1-100 quality value, and do some sums in > > the loader to convert to 1-9 compression. That was you can set quality > > and not care what file format is used. Sound reasonable? >=20 > Isn't PNG compression lossless? "Quality" is misleading I think... > well, not that I really think it would be a problem ... *shrug* Yes, but I wanted to standardise, and changing the jpeg loader to use "compression" and reversing the logic would break a lot of apps out there. After all, we've released now and we can't make that kind of change nicely. Basically, the idea is not to have to care what filetype the file is saved as, but to have some kind of standard behaviour you can count on. Tom. --=20 .^. .-------------------------------------------------------. /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | /( )\ | Open Source hacker, advocate | to...@li... | ^^-^^ '-------------------------------------------------------' |
From: <ra...@ra...> - 2000-10-29 18:03:01
|
On 29 Oct, Andrew Shugg scribbled: -> enl...@li... said: -> > Enlightenment CVS committal -> > -> > Author : gilbertt -> > Project : e17 -> > Module : libs/imlib2 -> > -> > -> > Modified Files: -> > loader_png.c -> > -> > -> > Log Message: -> > -> > png loader now pays head to images "quality" tag, just like the jpeg -> > loader. Now, the png lib takes values 1-9 for compression. I decided -> > to standardise loaders on a 1-100 quality value, and do some sums in -> > the loader to convert to 1-9 compression. That was you can set quality -> > and not care what file format is used. Sound reasonable? -> -> Isn't PNG compression lossless? "Quality" is misleading I think... -> well, not that I really think it would be a problem ... *shrug* agreed - the db loader/saver uses "compression" instead of quality as its alos lossless - compression is a value 0-9 - just like png (since thhis si the compression values zlib accepts) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@va... ra...@en... ra...@li... ra...@zi... |
From: Tom G. <to...@li...> - 2000-10-29 22:04:58
|
* ra...@ra... (ra...@ra...) wrote: > agreed - the db loader/saver uses "compression" instead of quality as > its alos lossless - compression is a value 0-9 - just like png (since > thhis si the compression values zlib accepts) Oh. I didn't look at the db loader. So should I revert png to "compression"? Or do people think it is a good idea to standardise the loaders somehow (I don't care what we call it but I think it should be the same for each). Tom. --=20 .^. .-------------------------------------------------------. /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | /( )\ | Open Source hacker, advocate | to...@li... | ^^-^^ '-------------------------------------------------------' |
From: <ra...@ra...> - 2000-10-29 22:29:29
|
On 29 Oct, Tom Gilbert scribbled: -> * ra...@ra... (ra...@ra...) wrote: -> > agreed - the db loader/saver uses "compression" instead of quality as -> > its alos lossless - compression is a value 0-9 - just like png (since -> > thhis si the compression values zlib accepts) -> -> Oh. I didn't look at the db loader. So should I revert png to -> "compression"? Or do people think it is a good idea to standardise the -> loaders somehow (I don't care what we call it but I think it should be -> the same for each). i'd guess you should as thats what png actually does - and it uses compression levels 0-9 :) the application alreayd has to knwo to settheiimage format to png or jpeg to save it as that format - so i am guessing it shoudl knwo what options there are for that format :) - just hunch - but i do see your point though :) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@va... ra...@en... ra...@li... ra...@zi... |
From: Tom G. <to...@li...> - 2000-10-29 22:32:38
|
* ra...@ra... (ra...@ra...) wrote: > On 29 Oct, Tom Gilbert scribbled: > -> * ra...@ra... (ra...@ra...) wrote: > -> > agreed - the db loader/saver uses "compression" instead of quality = as > -> > its alos lossless - compression is a value 0-9 - just like png (sin= ce > -> > thhis si the compression values zlib accepts) > -> =20 > -> Oh. I didn't look at the db loader. So should I revert png to > -> "compression"? Or do people think it is a good idea to standardise the > -> loaders somehow (I don't care what we call it but I think it should be > -> the same for each). >=20 > i'd guess you should as thats what png actually does - and it uses > compression levels 0-9 :) >=20 > the application alreayd has to knwo to settheiimage format to png or > jpeg to save it as that format - so i am guessing it shoudl knwo what > options there are for that format :) - just hunch - but i do see your > point though :) Not necessarily. I am thinking of simple little apps that grab a filename from the user and then just imlib_save_image(filename); and let imlib do the rest. With each loader having different shit you add a layer of complexity. They have to parse the filename, determine filetype and do the right thing. I don't mind personally, but it just seems nicer to keep them all the same - somehow..... Tom. --=20 .^. .-------------------------------------------------------. /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | /( )\ | Open Source hacker, advocate | to...@li... | ^^-^^ '-------------------------------------------------------' |
From: <ra...@ra...> - 2000-10-29 22:55:08
|
On 29 Oct, Tom Gilbert scribbled: -> * ra...@ra... (ra...@ra...) wrote: -> > On 29 Oct, Tom Gilbert scribbled: -> > -> * ra...@ra... (ra...@ra...) wrote: -> > -> > agreed - the db loader/saver uses "compression" instead of quality as -> > -> > its alos lossless - compression is a value 0-9 - just like png (since -> > -> > thhis si the compression values zlib accepts) -> > -> -> > -> Oh. I didn't look at the db loader. So should I revert png to -> > -> "compression"? Or do people think it is a good idea to standardise the -> > -> loaders somehow (I don't care what we call it but I think it should be -> > -> the same for each). -> > -> > i'd guess you should as thats what png actually does - and it uses -> > compression levels 0-9 :) -> > -> > the application alreayd has to knwo to settheiimage format to png or -> > jpeg to save it as that format - so i am guessing it shoudl knwo what -> > options there are for that format :) - just hunch - but i do see your -> > point though :) -> -> Not necessarily. I am thinking of simple little apps that grab a -> filename from the user and then just imlib_save_image(filename); and let -> imlib do the rest. With each loader having different shit you add a -> layer of complexity. They have to parse the filename, determine filetype -> and do the right thing. I don't mind personally, but it just seems nicer -> to keep them all the same - somehow..... truye - but to save as a file type they have to parse the filename anyway for ythe output type(ie look at the extension) so they alreayd knwo the file type- and they knwo for certain formats certainoptions are suported etc. (ie quality for jpeg, compression for png and db) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@va... ra...@en... ra...@li... ra...@zi... |
From: Tom G. <to...@li...> - 2000-10-29 23:04:47
|
* ra...@ra... (ra...@ra...) wrote: > On 29 Oct, Tom Gilbert scribbled: > -> Not necessarily. I am thinking of simple little apps that grab a > -> filename from the user and then just imlib_save_image(filename); and = let > -> imlib do the rest. With each loader having different shit you add a > -> layer of complexity. They have to parse the filename, determine filet= ype > -> and do the right thing. I don't mind personally, but it just seems ni= cer > -> to keep them all the same - somehow..... >=20 > truye - but to save as a file type they have to parse the filename > anyway for ythe output type(ie look at the extension) so they alreayd > knwo the file type- and they knwo for certain formats certainoptions > are suported etc. (ie quality for jpeg, compression for png and db) They do? Hrm. let me give you an example. Here's what scrot does right now: [... some stuff to grab the screenshot as an Imlib_Image ] imlib_context_set_image(image); imlib_image_attach_data_value("quality", NULL, opt.quality, NULL); imlib_save_image_with_error_return(opt.output_file, &err); [... check for errors ] Done. Nice and simple. If the user runs "scrot shot.png" he gets a png. If he does "scrot shot.jpg" he gets a jpeg. I didn't need to parse anything, and I like that ;-) Now I know you are thinking of apps like gimp where there is a plethora of options, all file-type dependant. But in this case, it would be really nice to be able to set "quality" or "compression" and know the Right Thing will be done. I don't really want to write code to chop up what they selected and do the right thing. ALSO, imlib2's savers are modular, people could write savers separate from imlib2 that I don't know about (eg xcf loader). I haven't a clue what options that takes, and if someone writes a new one in 4 months and sticks it on Freshmeat, how am I supposed to deal with that? Surely it is better for loaders to take a standard set of tags, "compression", "interlace" etc, and either do the Right Thing or ignore tags they don't support? Then I don't have to update all my imlib2 apps (and everyone else) when someone finally writes an SVG loader :-) Tom. --=20 .^. .-------------------------------------------------------. /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | /( )\ | Open Source hacker, advocate | to...@li... | ^^-^^ '-------------------------------------------------------' |
From: Richard L. <ric...@bt...> - 2000-10-29 23:17:16
|
* ra...@ra... (ra...@ra...) wrote: > On 29 Oct, Tom Gilbert scribbled: > -> * ra...@ra... (ra...@ra...) wrote: > -> > On 29 Oct, Tom Gilbert scribbled: <snip> > > point though :) > -> > -> Not necessarily. I am thinking of simple little apps that grab a > -> filename from the user and then just imlib_save_image(filename); and let > -> imlib do the rest. With each loader having different shit you add a > -> layer of complexity. They have to parse the filename, determine filetype > -> and do the right thing. I don't mind personally, but it just seems nicer > -> to keep them all the same - somehow..... > > truye - but to save as a file type they have to parse the filename > anyway for ythe output type(ie look at the extension) so they alreayd > knwo the file type- and they knwo for certain formats certainoptions > are suported etc. (ie quality for jpeg, compression for png and db) i thought imlib_save_image() parsed the file extension. -- |*-------------------=| Richard Lowe |=------------------*| | ric...@bt... UIN: 74724348 | |*-------------------------------------------------------*| | Europe has the Kilogram and the Meter. | | America has the Pound and the Inch. | | Childrens TV has the Elephant and the Double Decker Bus | |*-------------------------------------------------------*| |
From: <ra...@ra...> - 2000-10-29 23:18:57
|
On 29 Oct, Richard Lowe scribbled: -> * ra...@ra... (ra...@ra...) wrote: -> > On 29 Oct, Tom Gilbert scribbled: -> > -> * ra...@ra... (ra...@ra...) wrote: -> > -> > On 29 Oct, Tom Gilbert scribbled: -> -> <snip> -> -> > > point though :) -> > -> -> > -> Not necessarily. I am thinking of simple little apps that grab a -> > -> filename from the user and then just imlib_save_image(filename); and let -> > -> imlib do the rest. With each loader having different shit you add a -> > -> layer of complexity. They have to parse the filename, determine filetype -> > -> and do the right thing. I don't mind personally, but it just seems nicer -> > -> to keep them all the same - somehow..... -> > -> > truye - but to save as a file type they have to parse the filename -> > anyway for ythe output type(ie look at the extension) so they alreayd -> > knwo the file type- and they knwo for certain formats certainoptions -> > are suported etc. (ie quality for jpeg, compression for png and db) -> -> i thought imlib_save_image() parsed the file extension. no it does not. you need to set the format explicitly - it is extension agositc when saving. (when loading it tries extension as a best guess for the format and loader to use first before it tries each loadre in recency sequence) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@va... ra...@en... ra...@li... ra...@zi... |
From: Matt M. <car...@do...> - 2000-10-29 23:36:11
|
On Sun, 29 Oct 2000, Tom Gilbert wrote: > * ra...@ra... (ra...@ra...) wrote: > > agreed - the db loader/saver uses "compression" instead of quality as > > its alos lossless - compression is a value 0-9 - just like png (since > > thhis si the compression values zlib accepts) > > Oh. I didn't look at the db loader. So should I revert png to > "compression"? Or do people think it is a good idea to standardise the > loaders somehow (I don't care what we call it but I think it should be > the same for each). Between quality and compression, I imagine compression would be a better term since quality doesn't really apply to the db or png loaders. However, this raises an issue with how the scale for the jpeg loader works. For the png loader, higher number means more compression, but for jpeg's, a higher number means less compression. Reversing the jpeg loader's quality scale will break just as many apps as if the quality tag is changed, so is there a right way to get them to act the same without breaking apps? Matt |
From: Tom G. <to...@li...> - 2000-10-29 23:53:35
|
* Matt McClanahan (car...@do...) wrote: > On Sun, 29 Oct 2000, Tom Gilbert wrote: >=20 > > * ra...@ra... (ra...@ra...) wrote: > > > agreed - the db loader/saver uses "compression" instead of quality as > > > its alos lossless - compression is a value 0-9 - just like png (since > > > thhis si the compression values zlib accepts) > >=20 > > Oh. I didn't look at the db loader. So should I revert png to > > "compression"? Or do people think it is a good idea to standardise the > > loaders somehow (I don't care what we call it but I think it should be > > the same for each). >=20 > Between quality and compression, I imagine compression would be a better > term since quality doesn't really apply to the db or png loaders. > However, this raises an issue with how the scale for the jpeg loader > works. >=20 > For the png loader, higher number means more compression, but for jpeg's, > a higher number means less compression. Reversing the jpeg loader's > quality scale will break just as many apps as if the quality tag is > changed, so is there a right way to get them to act the same without > breaking apps? >=20 > Matt Why not change them all to "compression" but leave the existing "quality" in the jpeg loader for apps that use it. I really want a standard for this. I'll commit it in 30 mins if I don't get an objection.... Tom. --=20 .^. .-------------------------------------------------------. /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | /( )\ | Open Source hacker, advocate | to...@li... | ^^-^^ '-------------------------------------------------------' |
From: <ra...@ra...> - 2000-10-30 00:42:19
|
On 29 Oct, Tom Gilbert scribbled: -> * Matt McClanahan (car...@do...) wrote: -> > On Sun, 29 Oct 2000, Tom Gilbert wrote: -> > -> > > * ra...@ra... (ra...@ra...) wrote: -> > > > agreed - the db loader/saver uses "compression" instead of quality as -> > > > its alos lossless - compression is a value 0-9 - just like png (since -> > > > thhis si the compression values zlib accepts) -> > > -> > > Oh. I didn't look at the db loader. So should I revert png to -> > > "compression"? Or do people think it is a good idea to standardise the -> > > loaders somehow (I don't care what we call it but I think it should be -> > > the same for each). -> > -> > Between quality and compression, I imagine compression would be a better -> > term since quality doesn't really apply to the db or png loaders. -> > However, this raises an issue with how the scale for the jpeg loader -> > works. -> > -> > For the png loader, higher number means more compression, but for jpeg's, -> > a higher number means less compression. Reversing the jpeg loader's -> > quality scale will break just as many apps as if the quality tag is -> > changed, so is there a right way to get them to act the same without -> > breaking apps? -> > -> > Matt -> -> Why not change them all to "compression" but leave the existing -> "quality" in the jpeg loader for apps that use it. -> -> I really want a standard for this. I'll commit it in 30 mins if I don't -> get an objection.... that would work best. savers can check multiple properties looking for save compression/quality quality can be 0-100 compression 0-9 saver can convert as it sees fit to what makes sense for the format :) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@va... ra...@en... ra...@li... ra...@zi... |