Sven Neumann writes:
> If someone wants to try to recover some of the JPEG save settings when
> loading the JPEG file, feel free.
There are some scenarios in which blindly reusing the quality factor
guesstimated from loading an image is not a good idea, even if the
guesstimate is very accurate. (Which happens when the loaded image's
quantization tables exactly match the JPEG standard's sample tables
scaled in libjpeg's manner with said factor).
I mean cases where the entire image contents has been replaced with a
fresh (original quality) one. Or if the image has been scaled down. Or
if some filter(s) that modifies all of the image substantially has
been applied to the whole image. In cases like these it perhaps
doesn't make sense to blindly re-use the original jpeg file's quality
factor, but one should let the user decide.
Maybe a good heuristic would be only use the original quality factor
if available to increase the user's default setting, never decrease
it. Show the settings dialog, as in current SVN, and if there is a
guesstimated scale factor from the original image and it is better
than the one in the user's default jpeg settings, use that initially
in the dialog instead of the default.
Anyway, I think that to really be able to to advanced tricks, the jpeg
saving needs to re-decompress the original image while saving the new
version. When it makes sense it should reuse the exact same
quantization tables and subsamplig parameters. Then it could do tricks
like avoid recompression artefacts for blocks that haven't
changed. That would be really cool. One could load and save a JPEG
image as much as one likes, just touching up small parts here and
there (like correcting red-eye), with no quality degradation for the
rest of the image.
BTW, is there any reason to keep the "DCT method" choice? Why not just
use floating-point always? Is there any significant speed difference
on modern machines?
Gimp-developer mailing list