GNOME Bugzilla – Bug 665230
Support 12bits/component in file-jpeg plug-in
Last modified: 2018-05-24 13:07:07 UTC
Created attachment 202466 [details] [review] Patch to support 12bits/components jpeg files When used with a libjpeg compiled with 12bits/components support, the jpeg plug-in crashes when loading such images.
Can you attach or point to a 12-bit JPEG file which you are using? I can review your patch with it. Also, your patch says "16-bit per channel". Doesn't JPEG support a maximum of 12-bits per channel? Also I have to check if libjpeg needs to be compiled with support for 12-bits per channel to support it.
Created attachment 202485 [details] [review] Corrected patch My first patch was incorrect. As you stated, it said "16 bits" instead of "12 bits" (because I copied the warning message from the tiff plug-in), and indeed, this was the conversion I had implemented. I has not noticed it because the image I first tested on was made of fully saturated colors. I'll post a test image too.
Compiling libjpeg to support 12bits/component is explained in install.txt: The JPEG standard allows either 8-bit or 12-bit data precision. (For color, this means 8 or 12 bits per channel, of course.) If you need to work with deeper than 8-bit data, you can compile the IJG code for 12-bit operation. To do so: 1. In jmorecfg.h, define BITS_IN_JSAMPLE as 12 rather than 8. 2. In jconfig.h, undefine BMP_SUPPORTED, RLE_SUPPORTED, and TARGA_SUPPORTED, because the code for those formats doesn't handle 12-bit data and won't even compile. (The PPM code does work, as explained below. The GIF code works too; it scales 8-bit GIF data to and from 12-bit depth automatically.) 3. Compile. Don't expect "make test" to pass, since the supplied test files are for 8-bit data.
Created attachment 202486 [details] 12bits/components jpeg test image
With your patch, what happens when you try loading 8-bit files? I'm inclined to simply close this bug: 1. 12-bit files are very rare.. much more rarer than even arithmetic coded files. 2. 12-bit files are not supported by _ANY_ general purpose libjpeg that's distributed, as compile-time configuring it for 12-bits disables support entirely for 8-bit JPEGs. 3. The current behavior when you try to load a 12-bit JPEG file using a stock configuration, is that the plug-in displays an error and returns early. It does not crash. The crash probably happens when libjpeg is compiled for 12-bit operation, were all bets are off in the plug-in which is written for 8-bit operation which libjpeg no longer would support. There are other assumptions regarding _writing_ 12-bit files (when libjpeg only supports 12-bit JPEGs, then both load/save plug-ins need to support that mode), such as use of optimized tables by default, etc.
(In reply to comment #5) > With your patch, what happens when you try loading 8-bit files? It works as before with 8-bit files, provided you use a libjpeg compiled for 8-bit support. > I'm inclined to simply close this bug: > > 1. 12-bit files are very rare.. much more rarer than even arithmetic coded > files. Indeed, I didn't even it existed until a few days ago. > 2. 12-bit files are not supported by _ANY_ general purpose libjpeg that's > distributed, as compile-time configuring it for 12-bits disables support > entirely for 8-bit JPEGs. True, but why not make a step in that direction ? > 3. The current behavior when you try to load a 12-bit JPEG file using a stock > configuration, is that the plug-in displays an error and returns early. It does > not crash. The crash probably happens when libjpeg is compiled for 12-bit > operation, were all bets are off in the plug-in which is written for 8-bit > operation which libjpeg no longer would support. > There are other assumptions regarding _writing_ 12-bit files (when libjpeg only > supports 12-bit JPEGs, then both load/save plug-ins need to support that mode), > such as use of optimized tables by default, etc. You've a got a point. Image cannot be saved in 12-bit. So this is a major regression. But it could be worked around easily I think.
Created attachment 202506 [details] [review] Patch to support 12bits/components jpeg files This new patch adds support for saving jpegs using 12bits/component.
GIMP 2.10 might be a good point to decide about this, as it will finally make sense to work with more than 8 bit per component in GIMP.
Hi schumaml (In reply to comment #8) > GIMP 2.10 might be a good point to decide about this, as it will finally make > sense to work with more than 8 bit per component in GIMP. I'd recommend against implementing this support in GIMP. The basic problem is that (IIRC) libjpeg can be compiled only in 8-bit or 12-bit mode (either this or that, but not supporting both). * It's unlikely OS distributions will ship 12-bit libjpeg as it'll break every application that wants to open 8-bit JPEGs. * While I see that there is a 12-bit JPEG image attached to this bug, I'm not sure if it's valid. Though the JPEG standard supports 12 bits per channel, it's not certain if the file format (JFIF/EXIF) permits it. It doesn't say anything about including 12-bit JPEG data, but the specification on what should be in the file is for 8-bit data. Other containers can support 12-bit JPEG streams, but maybe not JFIF. One case is if someone wants to build a local copy of libjpeg and build GIMP against that, which will cause GIMP to not support 8-bit JPEGs. Is it worth supporting this use-case? The number of people who may want this is so small (and the steps required so lengthy) that they could use some other tool to convert the image to another format such as PNG before importing it into GIMP. An alternative is to support a separate 12-bit JPEG plug-in that links against a different libjpeg and GIMP ends up supporting both 8-bit and 12-bit JPEGs. This also seems like something out of the way to pursue.
Comment on attachment 202506 [details] [review] Patch to support 12bits/components jpeg files Rejecting this - but thanks for the code. GIMP has progressed further along to high bit depth support in general, and comment #9 advises against using this approach.
-- 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/388.