GNOME Bugzilla – Bug 331798
JPEG compression maps
Last modified: 2018-05-24 11:44:58 UTC
When saving a JPEG, let me supply a map like this: black = max compression grey = medium quality and compression white = max quality (or the other way around) The idea is to let the user choose max quality for important (foreground) parts of the image, and max compression for the unimportant (background) parts of the image. I suppose that each color channel of the map ought to apply to a color channel of the result. (green for Y, red for Cr, blue for Cb) Normally one would just use greyscale; conversion of the map ought to happen as needed. The easiest place to put the map is at the bottom of the layer stack. That way it is saved in XCF files, but it doesn't show up in the JPEG unless someone is weird enough to want that. Probably the user should get a down-down that lets them choose a layer, layer mask, other image, or none. ("none" meaning to enable the normal global quality value settings) Compress a block at the highest quality setting found in the map area describing that block. (well, better would be to control things at a level that is smaller than a compression block, considering the vertical and horizontal DCT separately... but that sounds really painful to implement) Rather than just disabling or ignoring the normal quality setting, it might be better to give the user two settings: one for the black parts of the map, and one for the white parts of the map. Then there is no need to change the map when one wants to tweak the settings a bit. This also eliminates the need to decide if max quality is represented by black or by white.
Does libjpeg support such maps at all? How useful is this? Why would anyone want to spend so much effort on optimizing a JPEG file?
Yes, libjpeg has the necessary support. The library has two or three different interfaces. I don't think this is all that much effort unless the user gets really picky. (same as with making an alpha channel or the image itself: how accurate do you want to be?) It would be very little effort if the selection mask were available as an input choice. All you'd have to do is paint a selection over the foreground, make the normal JPEG compression choices, and select a second compression value.
I would suggest that we give the user the possibility to use the selection mask then. Using other layers and/or layer masks is only going to complicate the plug-in, both code-wise and from a user's point of view. Currently the plug-in only accepts flat images and we should probably stick with that.
One related idea I had a long time ago would be to enable near-lossless partial edits (red-eye removal, for instance) of JPEG files: keep a map at suitable granularity (the 16x16 pixel jpeg blocks) of where the image has been "touched". When saving the image back, if most of the image hasn't been touched, use the original data for those blocks, and only recompress the parts that have been touched. Does this make any sense, or am I on crack? I need to read up on the JPEG format again.
I mean 8x8, of course ;)
Please try to stay on-topic here. Your suggestions are already handled in bug #105623.
Some additional ideas borrowed from other non-famous graphics application: * such maps could be generated automatically (allowing user to modify them afterwards). these could take into account objects such as text or shapes and make sharp edges look much better. * it could be generalazed a bit and used for indexed images as well (gif and png).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/181.