Dear Bill Here is the example:
http://www.berlininart.com/timeless-beauty-at-co-berlin/ (Teen Vogue - preview above, full image below - this falls under art...) http://www.berlininart.com/wp-content/uploads/2012/08/1330_Kim.jpg You can download and open the full image with Jpegcrop and see the approximate display. Other viewers like XnView or FastStone give similar results (on Windows, also using IJG library). But with IrfanView and the Windows integrated Image Preview component the colors appear more correct. These tools apparently use a special CMYK bitmap mode in the Windows display system which runs over kindof color management. I have found that apparently the newer Windows graphics display interfaces GDI-Plus or WPF have such mode, and I plan to investigate that further and also include such option later in Jpegcrop to get more clarity in this regard. Interesting: If I load the image with IrfanView under Windows 98 (good to have such oldies available for such kind of tests), IrfanView also does only the approximate (oversaturated) display, because the system function is apparently not yet available on this system. Also interesting: If I convert the image to arithmetic coding (with new Jpegcrop now possible), IrfanView can no longer display the image. That means that IrfanView apparently lets Windows do the complete decode in CMYK/YCCK case, which doesn't support arithmetic coding yet (IrfanView otherwise does). Here I would try to make it better than IrfanView by letting the system only convert the bitmap received from own codec from CMYK to RGB. Note that all this consideration does not affect the core codec (library): The core codec only receives or supplies the CMYK/YCCK data and at most performs the YCCK<->CMYK conversion, where the 'K' value is passed through unchanged, while everything else (conversion to RGB) is left to the application. The supported color spaces in libjpeg are now (jpeglib.h): /* Known color spaces. */ typedef enum { JCS_UNKNOWN, /* error/unspecified */ JCS_GRAYSCALE, /* monochrome */ JCS_RGB, /* red/green/blue, standard RGB (sRGB) */ JCS_YCbCr, /* Y/Cb/Cr (also known as YUV), standard YCC */ JCS_CMYK, /* C/M/Y/K */ JCS_YCCK, /* Y/Cb/Cr/K */ JCS_BG_RGB, /* big gamut red/green/blue, bg-sRGB */ JCS_BG_YCC /* big gamut Y/Cb/Cr, bg-sYCC */ } J_COLOR_SPACE; Note that the BG_RGB mode is defined in IEC 61966-2-1 only for 10 or more bits sample precision. It can be easily extended for 9 bits precision (and we allow that), but not easily for 8 bits (so we don't allow that), that's why it is actually not useful in the 8 bits implementation. However, the BG_YCC mode CAN be used easily also with 8 bits precision (although it is also formally defined in IEC 61966-2-1 only for 10 or more bits), while retaining the full luminance precision and reducing only the color components, which can be partially compensated by adapted quantization in the JPEG context! That's why I have introduced the cjpeg -bgycc switch, for demonstration that there is now an opportunity to exchange wide gamut color images in standard JPEG file interchange format (will be automatically clipped for normal RGB output, see jdcolor.c). Note that you cannot actually generate wide gamut colors by this option with cjpeg, because cjpeg actually supports only normal RGB input - it just generates a wide gamut capable encoding format. But an appropriate application can feed wide gamut colors directly to the library in this way. The IEC 61966-2-1 standard is not freely available, but you can find an identical British Standard version (including the important amendment) to read online (not possible to save or print): http://www.doc88.com/p-694270296039.html Regards Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
