On Mon, 9 Jul 2007 17:54:29 +0200, peter sikking <peter@xxxxxxxxxxxx> wrote:> guys, what a thread.> > I say that the solution for all this lies in treating these lossy> (my spell-checker proposes lousy) formats the same we are (gonna)> handle indexed mode:> > import + export only. Eek! That would significantly break the flow for what must be themost common image format for photography. I prefer the currentbehavior in SVN, in which you get the dialog for the first time youselect Save, but subsequent saves of the same image (while you arestill working on it) will not force you to pick a new file name andvalidate the parameters again. > I have hard time believing that the reason a file is jpeg on> your camera memory card is the same as being jpeg at the end of> your workflow in GIMP. Afterwards it is about saving space on your> disk or saving bandwidth on the internet. Different requirements ==> different quality factor, I say. Before I started shooting only in raw format (so before I boughtlarger memory cards for my camera), I shot a lot of JPEG pictures. Ikept them all as they came out of the camera. But some of themrequired editing, such as removing red eyes or correcting obviouscolor casts. In these cases, I stored the edited images next to theoriginals (with a slightly different file name like"dsc0042_edited.jpg") and I was interested in getting files that wereabout the same quality and size as the unedited ones so that theysomehow fit in my collection. Making them "fit" (having similarsize/quality tradeoff) is not really a major concern, but I still tookthe time to experiment a bit with the sliders until I found out thatfor most of my photos, using a setting around 92-94 was reasonablyclose to what the camera produced. This value did not work for allphotos because some of them were shot with different camera settings,but at least that was a good estimate for most of them. If the patch provided by Tor was extended to support quantizationtables produced by other software than libjpeg (by finding theclosest match), then it would reduce the amount of guesswork. Side note: as suggested by Sven in #gimp, I just had a look atImageMagick to try and find out how they retreive or guess the qualitysettings from JPEG files. The code is about 100 lines long and can befound in ImageMagick-6.3.5/coders/jpeg.c, around line 830. It isbased on a comparison of the difference produced by the quantizationtables in the file with the 100 possible tables produced by libjpeg.If no exact match is found, then the closest one is selected. Theyuse pre-computed hashes and sums for the libjpeg tables in order tospeed up the comparisons. The license of ImageMagick is compatiblewith the GPL so we could even consider re-using their code. We wouldonly have to include their license with the jpeg plug-in. -Raphaël_______________________________________________Gimp-developer mailing listGimp-developer@xxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
