Color changing under graphic inclusion with graphicx

[Paulo Ney de Souza]

The plot thickens ....

I posted to the `dvipdfmx` mailing list as suggested by Ulrike,
and after a lot of discussions with Shunsaku Hirata (平田俊作),
I am getting more and more convinced that this is a bug with
pdflatex and lualatex and that xelatex is doing the right thing.

He explained to me that the two images {A,B}.png, as manufactured
by ImageMagick, are defined in a ColorSpace called CalRGB and
do contain calibration settings.

GIMP is not able to handle the calibration data and ignores it when
exporting -- which is why {A,B}-gimp.png do not contain any such
data and are written in the DeviceRGB ColorSpace.

The work is somewhat hard because one needs to look inside the
PNG to check this up -- apparently there are NO tools to detect
the ColorSpace of a PNG, despite claims by ImageMagic "identify"
suite.

He says, that just like GIMP, both pdftex and luatex are NOT able
to handle the calibration data either, so that is why -- when all of
them drop the data -- you see no differences in the border of images.
The two top images are now being handled in the wrong ColorSpace
inside PDF (DeviceRGB instead of CalRGB).

Could anyone suggest the next steps? This seems to render pdfTeX
and luaTeX unusable for color-production work.

Paulo Ney










On Mon, Jan 11, 2021 at 2:53 PM Paulo Ney de Souza <pauloney at gmail.com>
wrote:

>
>
> On Mon, Jan 11, 2021 at 1:14 PM Ulrike Fischer <news3 at nililand.de> wrote:
>
>> Am Sun, 10 Jan 2021 11:20:20 -0800 schrieb Paulo Ney de Souza:
>>
>> > As Phil has already determined, the problem only occurs in XeTeX (not in
>> > pdfTeX or LuaTeX).
>>
>> Yes, why didn't you mention directly which engine you are using?
>>
>
>
> Because we are only humans Ulrike. Sorry! I know the drill very well, but
> it was
> an incredibly hard bug to pin down -- and I am not sure we are done. It was
> caught in a Production Suite we developed for a publisher, in the final
> printing
> of a cover for a book, by someone with a very good eye. For many weeks we
> (erroneously) treated as some sort of problem  at the printer end (we do
> have
> a fair share of those) or some bad conversion of the PDF.
>
> There were many levels and a lot of software packages involved
> (ImageMagic,
> GIMP, TeX, LaTeX packages, ICC profiles, Acrobat ... and whatever else the
> printers do to it) and finding the colors, producing the images for the
> MWE was
> incredibly complex. Soo much so that I initially forgot about noting the
> pdf,xe,luatex
> differences. Phil picked up gracefully and pretty quickly.
>
>
>
>> Well the backend of xelatex, dvipdfmx, has quite extended PNG
>> support, see the documentation (texdoc dvipdfmx).
>>
>> And looking at the pdf one can see that your images are included
>> with different color spaces. The "wrong" uses CalRGB
>>
>> <</ColorSpace[/Indexed[/CalRGB<</WhitePoint[.95046 1
>> 1.08906]/Gamma[2.19998 2.19998
>> 2.19998]/Matrix[.41239 .21264 .01933
>> .35758 .71517 .11919 .18048 .07219 .95053]>>]1<504053ffffff>]
>>
>> The other one DeviceRGB:
>>
>> <</ColorSpace[/Indexed/DeviceRGB 1<504053ffffff>]
>>
>> pdftex uses DeviceRGB in both cases.
>>
>> I have no idea if  this can be configured, you could check the
>> documentation or ask on the dvipdfmx mailing list.
>>
>> --
>> Ulrike Fischer
>> https://www.troubleshooting-tex.de/
>
>
>
> Many thanks will follow up with them.
>
> Paulo Ney
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/texhax/attachments/20210112/16d32a89/attachment.html>