Re: [Tiff] CMYK->RGB (was Re: 4.7.1 release)

2025-09-07 Thread Rob Boehne via Tiff 
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]
Date:   Fri Apr 6 17:34:11 2001 +

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 
Date: Thursday, September 4, 2025 at 11:02 AM
To: Rob Boehne , [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  on behalf of Rob Boehne via Tiff 

Date: Thursday, September 4, 2025 at 1:00 PM
To: [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  on behalf of Even Rouault via Tiff 

Date: Thursday, September 4, 2025 at 8:54 AM
To: [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
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

Re: [Tiff] CMYK->RGB (was Re: 4.7.1 release)

2025-09-04 Thread Even Rouault via Tiff 
As I mentionned in the merge request, this changed seems to be 
fundamentally inappropriate for upstreaming, and ressembles more to a 
hack on your side (nothing against hacks by themselves, but they don't 
below to the upstream software), because the TIFFReadRGBAImage() 
function should obviously returns RGBA images, not CMYK pretending to be 
RGBA. If you want to get the raw CYMK values the appropriate functions 
to use are TIFFReadEncodedTile()/TIFFReadEncodedStrip()


Le 04/09/2025 à 22:43, Rob Boehne via Tiff a écrit :


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]

Date:   Fri Apr 6 17:34:11 2001 +

    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 
*Date: *Thursday, September 4, 2025 at 11:02 AM
*To: *Rob Boehne , [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  on behalf of Rob Boehne 
via Tiff 

*Date: *Thursday, September 4, 2025 at 1:00 PM
*To: *[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  on behalf of Even Rouault 
via Tiff 

*Date: *Thursday, September 4, 2025 at 8:54 AM
*To: *[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 
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


--
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

Re: [Tiff] CMYK->RGB (was Re: 4.7.1 release)

2025-09-04 Thread Matt Kuznicki via Tiff 
Hi everyone, it’s been some time since I made this change in the copy of 
libtiff in question. I would encourage looking further into this change and not 
just taking it as-is. In brief:

> 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??

Yes, that’s the intent.

The impetus behind this change was to retrieve CMYK color data for TIFF images 
where color data is stored in CMYK directly, instead of going through a CMYK -> 
RGB color conversion as performed by the TIFFReadRGBAImage API. When I made 
this change, at that time in libtiff I’d found that the CMYK color values were 
stored in the pp values. My change removed the very crude CMYK->RGBA conversion 
and replaced it with passing the CMYK values through directly. The CMYK values 
are assumed stored in the ICC color profile included in the CMYK tiff. 
Transparency is not a concern as there is no implicit background to a CMYK TIFF 
image, if memory serves correctly.

At a minimum, to bring the change into libtiff I would encourage looking at the 
method name and aligning that with what’s returned; this may be better suited 
to an API of more accurate name.

HTH,
- Matt

Matt Kuznicki  | Engineering Manager |  Adobe  |  C 773 330 5408  |  
[email protected]

From: Rob Boehne 
Date: Thursday, September 4, 2025 at 2:44 PM
To: Leonard Rosenthol , [email protected] 
, Matt Kuznicki 
Cc: Patrick Gallot 
Subject: Re: CMYK->RGB (was Re: [Tiff] 4.7.1 release)

EXTERNAL: Use caution when clicking on links or opening attachments.


Adding Patrick too, he’s also interested in spelunking this issue 😉

From: Leonard Rosenthol 
Date: Thursday, September 4, 2025 at 2:43 PM
To: Rob Boehne , [email protected] 
, Matt Kuznicki 
Subject: Re: CMYK->RGB (was Re: [Tiff] 4.7.1 release)
Well Matt works for Adobe now - so let’s add him and see what he remembers 😉.

Hey @Matt Kuznicki...


From: Rob Boehne 
Date: Thursday, September 4, 2025 at 4:43 PM
To: Leonard Rosenthol , [email protected] 

Subject: Re: CMYK->RGB (was Re: [Tiff] 4.7.1 release)

EXTERNAL: Use caution when clicking on links or opening attachments.


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]
Date:   Fri Apr 6 17:34:11 2001 +

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 
Date: Thursday, September 4, 2025 at 11:02 AM
To: Rob Boehne , [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  on behalf of

Re: [Tiff] CMYK->RGB (was Re: 4.7.1 release)

2025-09-04 Thread Rob Boehne via Tiff 
Adding Patrick too, he’s also interested in spelunking this issue 😉

From: Leonard Rosenthol 
Date: Thursday, September 4, 2025 at 2:43 PM
To: Rob Boehne , [email protected] 
, Matt Kuznicki 
Subject: Re: CMYK->RGB (was Re: [Tiff] 4.7.1 release)
Well Matt works for Adobe now - so let’s add him and see what he remembers 😉.

Hey @Matt Kuznicki...


From: Rob Boehne 
Date: Thursday, September 4, 2025 at 4:43 PM
To: Leonard Rosenthol , [email protected] 

Subject: Re: CMYK->RGB (was Re: [Tiff] 4.7.1 release)

EXTERNAL: Use caution when clicking on links or opening attachments.


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]
Date:   Fri Apr 6 17:34:11 2001 +

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 
Date: Thursday, September 4, 2025 at 11:02 AM
To: Rob Boehne , [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  on behalf of Rob Boehne via Tiff 

Date: Thursday, September 4, 2025 at 1:00 PM
To: [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  on behalf of Even Rouault via Tiff 

Date: Thursday, September 4, 2025 at 8:54 AM
To: [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
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

Re: [Tiff] CMYK->RGB (was Re: 4.7.1 release)

2025-09-04 Thread Leonard Rosenthol via Tiff 
Well Matt works for Adobe now - so let’s add him and see what he remembers 😉.

Hey @Matt Kuznicki...


From: Rob Boehne 
Date: Thursday, September 4, 2025 at 4:43 PM
To: Leonard Rosenthol , [email protected] 

Subject: Re: CMYK->RGB (was Re: [Tiff] 4.7.1 release)


EXTERNAL: Use caution when clicking on links or opening attachments.

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]
Date:   Fri Apr 6 17:34:11 2001 +

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 
Date: Thursday, September 4, 2025 at 11:02 AM
To: Rob Boehne , [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  on behalf of Rob Boehne via Tiff 

Date: Thursday, September 4, 2025 at 1:00 PM
To: [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  on behalf of Even Rouault via Tiff 

Date: Thursday, September 4, 2025 at 8:54 AM
To: [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
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

Re: [Tiff] CMYK->RGB (was Re: 4.7.1 release)

2025-09-04 Thread Rob Boehne via Tiff 
Wow, this is really interesting.  We will have to dig into this and look at 
this 25-year-old issue again ;)

From: Even Rouault 
Date: Thursday, September 4, 2025 at 2:03 PM
To: Rob Boehne , Leonard Rosenthol , 
[email protected] 
Subject: Re: [Tiff] CMYK->RGB (was Re: 4.7.1 release)

As I mentionned in the merge request, this changed seems to be fundamentally 
inappropriate for upstreaming, and ressembles more to a hack on your side 
(nothing against hacks by themselves, but they don't below to the upstream 
software), because the TIFFReadRGBAImage() function should obviously returns 
RGBA images, not CMYK pretending to be RGBA. If you want to get the raw CYMK 
values the appropriate functions to use are 
TIFFReadEncodedTile()/TIFFReadEncodedStrip()
Le 04/09/2025 à 22:43, Rob Boehne via Tiff a écrit :
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 +

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 <mailto:[email protected]>
Date: Thursday, September 4, 2025 at 11:02 AM
To: Rob Boehne <mailto:[email protected]>, 
[email protected]<mailto:[email protected]> 
<mailto:[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 <mailto:[email protected]> 
on behalf of Rob Boehne via Tiff 
<mailto:[email protected]>
Date: Thursday, September 4, 2025 at 1:00 PM
To: [email protected]<mailto:[email protected]> 
<mailto:[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 <mailto:[email protected]> 
on behalf of Even Rouault via Tiff 
<mailto:[email protected]>
Date: Thursday, September 4, 2025 at 8:54 AM
To: [email protected]<mailto:[email protected]> 
<mailto:[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?

Eve