GNOME Bugzilla – Bug 105623
JPEG file rewriter could avoid some recompression artifacts
Last modified: 2009-08-19 16:26:05 UTC
A JPEG file rewriter plugin could avoid recompression artifacts in cases where only selective parts of the image are edited (such as in the case of red-eye removal, in photos). It could also avoid the disposal of the original file's metadata blocks. I'm imagining that the rewriter plugin would re-decompress the file and do a macroblock-wise comparison with the new image. Only the macroblocks that contained differing pixel content would be rebuilt (using the source file's original quantization tables, of course). Furthermore, there should be an option to preserve the source file's metadata blocks. Perhaps, in theory, it shouldn't be necessary to do any more than use the same quantization tables & sampling structure, but I'm concerned that the results of decimating the chroma channels will yield slightly different pixel values than the file originally encoded. This will have the effect of introducing more quantization noise into those channels (which will leak into the Y channel, when the image is reloaded and resaved). If I had time, I'd write this, myself. Unfortunately, it could be years before I get around to it. Also, while I've hacked around in the IJG sources & built an optimized MJPEG codec with them, it might be easier for someone else to whip this up, due to my unfamiliarity with GNOME/GIMP.
See also bug 56443.
actually, the GEGL people should look at this and see how GEGL can be designed with this in mind. GEGL should also solve the problem of world peace. :) There doesn't seem to be a GEGL product -- is there a cc that can be added?
In the shorter term, I had an idea on this one. We could simply (?) re-read the file at save time, if it exists, and compare, tile-by-tile, whether the data has changed. If it hasn't write out the old compressed data, if it has, compress and write out new data. I'm not sure how easy this would be to do with libjpeg, we'd be getting pretty close to implementing jpeg compression/decompression in the plug-in, I think. Adding Adam as a CC to see what he makes of this. Cheers, Dave.
I've never used libjpeg's API for writing. I guess I probably haven't used enough of the gnarly parts of its reading API either, though from a cursory look you can use it to grab the data in various stages of decompression (I'm pretty sure that we'd have to at least partially repack/rehuff whole chunks of the jpeg between restart markers, but that's lossless if it get it soon enough). It might all be pretty academic -- IIRC Raphaël Quinet (or was it tml?) did a series of successive-repacking tests at various quality levels several years ago when this question came up before and ISTR that the conclusion was that this isn't worth bothering with -- successive save/loads at similar quality did NOT continually degade the saved image, in fact it converged very quickly on something that was 'stable' pixel-for-pixel.
I would vote to close this as WONTFIX, on the grounds that it just isn't GIMP's job to do direct file -> file manipulations. It is nowadays possible to find image browsers that do lossless jpeg rotation -- gthumb is an example.
In response to comment #3: yes, that's exactly what I had in mind. In response to comment #4: I'm not concerned about successive loading/saving, I'm only concerned about the first time a file is written with slightly different quantization tables (imagine cases where corresponding coefficients are of similar magnitude but relatively prime). In response to comment #5: The focus was oriented towards touch-ups. As described, the plugin would not typically perform lossless rotations. Anyhow, the key thrust of the idea was to provide this functionality in a way that is completely non-intrusive to GIMP and could (conceivably) be completely isolated within a plugin. While I'm familiar with some plugin APIs, I know very little about GIMP plugins - so much of this is speculation (on the GIMP end of things, anyway). For the JPEG part, I think libjpeg gives you all the hooks you'd need to avoid writing much/any low-level JPEG code. However, I'm not going to write this, because I don't have the time and I don't need it. I only submitted the bug report because I thought others might be interested in the idea (maybe enough so to actually write it). Since it's had ample opportunity to be adopted, and yet seems to have aroused little interest, there would seem to be little value in keeping it open. Therefore, it would not really upset me to see this discarded (as if that even matters, given that I'm not a GIMP contributor). In fact, I'm a bit surprised it survived this long. Actually, I should thank you all for even considering it.
While I agree that this feature doesn't fit into the current architecture, it's still a noble goal and it doesn't hurt to keep a feature request open for it.
*** Bug 142261 has been marked as a duplicate of this bug. ***
*** Bug 326627 has been marked as a duplicate of this bug. ***
Since I don't see how clever reuse of JPEG macroblocks would help us fulfil our productvision, I'm closing this as WONTFIX. It surely is an interesting problem to solve, but it doesn't add considerable value to the users we are targeting. Keeping the metadata of imported JPEG images around is of course something we should do, but that is taken care of in other bug reports.