All, I want to upstream this change, or alternatively a more complete change, or if this change is fundamentally bogus – know how and why. Our practices have changed a lot since this patch was created, and if it’s going to create an onerous burden to get it accepted before the 4.7.1 release, we won’t hold it up for that. I’d also prefer to have a test to demonstrate the functionality.
It might take a day or two to identify our test case that corresponds to this change, and more time to turn that into something appropriate for the libtiff test suite – any advice would be greatly appreciated. Here is the original comment in the history- Author: Matthew Kuznicki [email protected]<mailto:[email protected]> Date: Fri Apr 6 17:34:11 2001 +0000 Added support for CMYK TIFF images as unconverted CMYK images, by removing the conversion in libtiff for non CMYK->RGB mapped TIFFs. Clarified comments on ICC profiles in CacheTIFF, fixed a late colorspace setting in CacheTIFF. With the original diff in a copy of libtiff ca. 2001 diff --git a/libtiff/tif_getimage.c b/libtiff/tif_getimage.c index 3439197b4..87dea8147 100644 --- a/libtiff/tif_getimage.c +++ b/libtiff/tif_getimage.c @@ -1036,6 +1036,11 @@ DECLAREContigPutFunc(putRGBUAcontig16bittile) * * NB: The conversion of CMYK->RGB is *very* crude. */ +/* MMK: Actually, the conversion has been removed. + * Sends infomation back in CMYK order, unconverted. + * Means we lose support for transparent CMYK TIFF + * images, but how often does one see one of _those_? + */ DECLAREContigPutFunc(putRGBcontig8bitCMYKtile) { int samplesperpixel = img->samplesperpixel; @@ -1044,14 +1049,14 @@ DECLAREContigPutFunc(putRGBcontig8bitCMYKtile) (void) x; (void) y; fromskew *= samplesperpixel; while (h-- > 0) { - UNROLL8(w, NOP, - k = 255 - pp[3]; - r = (k*(255-pp[0]))/255; - g = (k*(255-pp[1]))/255; - b = (k*(255-pp[2]))/255; - *cp++ = PACK(r, g, b); + UNROLL8(w, NOP, + pp[0]; + pp[1]; + pp[2]; + pp[3]; + *cp++ = PACK4(pp[0], pp[1], pp[2], pp[3]); pp += samplesperpixel); - cp += toskew; + cp += toskew; pp += fromskew; } } From: Leonard Rosenthol <[email protected]> Date: Thursday, September 4, 2025 at 11:02 AM To: Rob Boehne <[email protected]>, [email protected] <[email protected]> Subject: CMYK->RGB (was Re: [Tiff] 4.7.1 release) If I read that PR correctly, you are removing the “Red Book algorithm” for CMYK->RGB conversion, but you aren’t replacing it with anything other than just passing the values through. Is that the intent?? Leonard From: Tiff <[email protected]> on behalf of Rob Boehne via Tiff <[email protected]> Date: Thursday, September 4, 2025 at 1:00 PM To: [email protected] <[email protected]> Subject: Re: [Tiff] 4.7.1 release EXTERNAL: Use caution when clicking on links or opening attachments. Even, We opened a merge request recently that we would like to get in the next release. It implements CMYK to RGB conversion, and we have been patching libtiff with this for many years (so we have high confidence in it). https://gitlab.com/libtiff/libtiff/-/merge_requests/751/diffs I can get any feedback on the MR responded to today – so if there are any other potential problems we can get them resolved quickly. Thanks, Robert Boehne From: Tiff <[email protected]> on behalf of Even Rouault via Tiff <[email protected]> Date: Thursday, September 4, 2025 at 8:54 AM To: [email protected] <[email protected]> Subject: [Tiff] 4.7.1 release Hi, I see 4.7.0 was released about one year ago. I can issue a 4.7.1 release. Is there anything that should be included in it before? Even -- http://www.spatialys.com<http://www.spatialys.com/> My software is free, but my time generally not. _______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
