[dvipdfmx] bug with inclusion of a PNG

[Shunsaku Hirata]

I don't know if it is the right way for dvipdfmx to ignore gAMA and
cHRM settings
as in other applications.

But for the moment, I would suggest choosing one of the following solutions:

1. Add the following special command somewhere (probably at the beginning of the
first page)

\special{pdf:pageresources  <<
   /ColorSpace <<
    /DefaultRGB [ /CalRGB <<
      /WhitePoint [.95046 1 1.08906]
      /Gamma [2.19998 2.19998 2.19998]
      /Matrix [.41239 .21264 .01933 .35758 .71517 .11919 .18048 .07219 .95053]
    >> ]
   >>
>>}

This declares that DeviceRGB color space should be adjusted similarly as in
PNG file A.png and B.png.
Note that this will cause slight changes of all colors used in your
PDF document.

2. Remove gAMA and cHRM chunks from your PNG files.


Thanks,
Shunsaku Hirata

2021年1月14日(木) 1:10 Shunsaku Hirata <shunsaku.hirata74 at gmail.com>:
>
> Hi Paulo,
>
> > I did see that XeTeX has company in Libre Office, but that is about it. All other programs I tried -- Adobe InDesign, Photoshop, Illustrator, MS Word, MS Publisher do it just like pdfTeX and LuaTeX, and ignore the calibration data on the PNG.
>
> Even Chrome which utilizes cHRM when displaying seems to ignore
> it when printing to PDF. I don't know the reason behind this...
>
> > And on another point, reading the PNG specification (http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html) I saw the following text:
> >
> >         An sRGB chunk or iCCP chunk, when present and recognized, overrides the cHRM chunk.
> >
> > that seems to imply the calibration chunk should be ignore in the presence of an sRGB chunk -- which I believe is our case, isn't it?
>
> No, it isn't. As pointed by Philip, it doesn't contain sRGB nor iCCP.
> And also, the presence of an sRGB chunk does not imply using DeviceRGB.
> The sRGB and iCCP chunk settings take precedence over cHRM.
>
> Thanks,
> Shunsaku Hirata
>
> > Many thanks for your help in understanding this,
> > Paulo Ney
> >
> >
> > On Tue, Jan 12, 2021 at 8:10 AM 平田俊作 <shunsaku.hirata74 at gmail.com> wrote:
> >>
> >>
> >>
> >> 2021/01/13 0:05、Paulo Ney de Souza <pauloney at gmail.com>のメール:
> >>
> >> 
> >> Thanks Shunsaku, I am sorry I have more questions that on the first e-mail...
> >>
> >> On Tue, Jan 12, 2021 at 6:37 AM Shunsaku Hirata <shunsaku.hirata74 at gmail.com> wrote:
> >>>
> >>> Sorry there is a correction.
> >>>
> >>> 2021年1月12日(火) 21:10 Shunsaku Hirata <shunsaku.hirata74 at gmail.com>:
> >>> >
> >>> > Hi Paulo,
> >>> >
> >>> > Your PNG images A.png and B.png actually use a calibrated color space
> >>> > as specified in gAMA and cHRM chunks of PNG images. Hence CalRGB
> >>> > should be used.
> >>
> >>
> >> What do you use for checking the ColorSpace of an image?
> >>
> >>
> >> This time I just used TweakPNG program to inspect the PNG files. I don’t know if there is any tool which can be used to check the color space of images in general.
> >>
> >>> > Colors specified in the DeviceRGB color space may look differently on
> >>> > different devices.  Indeed, your color.pdf doesn't show a color difference on
> >>> > my smartphone whereas it does on my laptop screen.
> >>>
> >>> This is wrong. I was checking a different file.
> >>
> >>
> >> I think that now it isincorrect. The file "color.pdf" as processed by xelatex under TL'20
> >> show differences in tonality on laptops and tvs, but not on phones.
> >>
> >>
> >>>
> >>> Further inspecting it I found that the calibrated color space used in the
> >>> provided PNG files seems to be using an approximated sRGB space.
> >>> This seems to be causing a subtle difference in the color.
> >>
> >>
> >> Would you mind go into a bit more detail? The differences in color are completely
> >> gone after one opens and export it in GIMP. How is GIMP able to calculate the
> >> correct color? THat ought to be part of the original image, no?
> >>
> >>
> >> This is because GIMP removed the color calibration information originally stored. I think the correct color was not calculated but the calibration information was simply ignored and was omitted when the image was exported.
> >>
> >> Although your original PNG files contain some extra information which is required for reproducing the same color across different devices, PNG files exported by GIMP only contain RGB values with no associated information required for color calibration.
> >>
> >> As you have specified the background color as device dependent RGB color values and now GIMP exported PNG also uses the same color specifications, the color must look exactly the same as long as the same RGB values are specified.
> >>
> >>
> >>>
> >>>
> >>> > If this is not as you intended, please remove the PNG chunks mentioned
> >>> > above.
> >>>
> >>> I think dvipdfmx output is correct and I suggest doing the above.
> >>
> >>
> >> Would you mind go into a bit more detail here as well? If dvipdfmx is correct here then
> >> latex,  pdflatex and lualatex are wrong.
> >>
> >>
> >> I think pdflatex and lualatex don’t fully support  color calibration information in PNG format and ignore such information as in GIMP export.
> >>
> >> The problem occurs because dvipdfmx tries to preserve the color calibration information stored in PNG files and uses device independent color space CalRGB for images while the background color is specified in the device dependent DeviceRGB color space.
> >>
> >>
> >> Thanks,
> >> Shunsaku Hirata