On Mon, 9 Jul 2007 17:54:29 +0200, peter sikking <[EMAIL PROTECTED]> 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 the
most common image format for photography.  I prefer the current
behavior in SVN, in which you get the dialog for the first time you
select Save, but subsequent saves of the same image (while you are
still working on it) will not force you to pick a new file name and
validate 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 bought
larger memory cards for my camera), I shot a lot of JPEG pictures.  I
kept them all as they came out of the camera.  But some of them
required editing, such as removing red eyes or correcting obvious
color casts.  In these cases, I stored the edited images next to the
originals (with a slightly different file name like
"dsc0042_edited.jpg") and I was interested in getting files that were
about the same quality and size as the unedited ones so that they
somehow fit in my collection.  Making them "fit" (having similar
size/quality tradeoff) is not really a major concern, but I still took
the time to experiment a bit with the sliders until I found out that
for most of my photos, using a setting around 92-94 was reasonably
close to what the camera produced.  This value did not work for all
photos 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 quantization
tables produced by other software than libjpeg (by finding the
closest match), then it would reduce the amount of guesswork.

Side note: as suggested by Sven in #gimp, I just had a look at
ImageMagick to try and find out how they retreive or guess the quality
settings from JPEG files.  The code is about 100 lines long and can be
found in ImageMagick-6.3.5/coders/jpeg.c, around line 830.  It is
based on a comparison of the difference produced by the quantization
tables in the file with the 100 possible tables produced by libjpeg.
If no exact match is found, then the closest one is selected.  They
use pre-computed hashes and sums for the libjpeg tables in order to
speed up the comparisons.  The license of ImageMagick is compatible
with the GPL so we could even consider re-using their code.  We would
only have to include their license with the jpeg plug-in.

Gimp-developer mailing list

Reply via email to