Dear Bill
I received the following bug report, and I very much appreciated your opinion about it. <http://bugs.debian.org/718604>
I'm very thankful that this subject is brought up now, because there have been clarifications in the color support department in recent IJG JPEG development, and I'll use the chance here to report about them. First, djpeg handles INTERCHANGE JPEG streams, it does not claim to support anything else! The term JPEG FILE INTERCHANGE FORMAT (JFIF) primarily refers to the range of supported color space encodings, and it will be redefined by IJG in the upcoming IJG JPEG 9a release, see http://www.infai.org/jpeg/ This is the major new feature of that new libjpeg version! (Interestingly, http://www.w3.org/Graphics/JPEG/ claims that JFIF was invented by IJG anyway, although http://www.jpeg.org/jpeg/ tells a bit different...) The YCCK/CMYK color space encodings are actually NOT part of JFIF! The new redefined JFIF version 2 refers ONLY to the IEC 61966-2-1 (aka sRGB) standard which contains unambiguous definitions for various RGB and YCC color space encodings, which are therefore suitable for common image interchange and which are therefore all supported by libjpeg 9a. See the new jccolor.c/jdcolor.c modules in new version as given above (and cjpeg got a corresponding new -bgycc switch, see also usage.txt for description). Note that this version is the first REAL SOURCE code regarding this subject, because it contains exact mathematical derivations for the conversions, which are lacking in prior versions and in all other so-called "source" codes! It is interesting that with this approach we can support ALL color with ANY gamut without going into complicated color management issues! We want to do IMAGE CODING and COMMON INTERCHANGE here, not device-specific COLOR MANAGEMENT! The IEC 61966-2-1 standard allows us to separate these different issues, so that we can constrain our attention on image coding and interchange, and not need to open up Pandora's box with all kinds of issues regarding color management functions. These are different subjects. The YCCK/CMYK color spaces, while NOT part of the current JFIF, are supported to SOME EXTENT by the JPEG library. A full support would need to include some sort of color management functions (see later), and we actually don't want to do that here. So what we actually do is to provide a PARTIAL support for YCCK/CMYK handling, as far as it fits in our constraints, and leave the other part to do for the application interface. This works well if you understand this division of labor. I have done this in the Jpegcrop sample application, see: http://jpegclub.org/jpegcrop.txt Release history =============== 2013.07: - IJG JPEG 9a develop version code base. 2013.06: - Add approximate CMYK/YCCK display support. Note here that it says APPROXIMATE support! It uses a code for the conversion which is similar to your suggested patch version, find it here in the application interface modules for the JPEG library in the Jpegcrop source packages as given on page http://jpegclub.org/jpegtran/ (file jpegdib.cpp in the Windows version, file jpegimage.cpp in the Unix version). Note that this code is only a simplified version for approximate support, it does not give you the true results, and that is the reason why we must not include it in the reference libjpeg! I will give you a nice example in next message. You will notice that the approximated display shows quite oversaturated colors. This may be acceptable for fast image viewing and for tools like Jpegcrop where the display has only secondary function for operation, but it is not the true thing. I assume that for true conversion at least the 'K' channel has to undergo a special transfer function, similar to an 'A' channel in alpha modes, and this is best handled in a dedicated color management framework, or a display system which supports dedicated CMYK pixel maps (see later). Regards Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
