I have (a couple) of PNG images with a background color of, for example, RGB(80,64,83):

One color image with the same background

Same background with a slash

that when placed on a page of the same background color with graphicx -- they show a distinct tonality against the background -- which is of the same color, when run under XeLaTeX. There are no problems under pdfLaTeX or LuaLaTeX.









enter image description here

Checking the colors in the included files one can see they have changed from (80,64,83) to (71,56,74) in the included images.

Just opening the images on GIMP and exporting it as-is with the default choices of

Default settings

fixes everything and the new inclusion now gets the exact color they were set to begin with, the same as the background, as shown below (second line). Also processing the images with pdflatex or lualatex does not show the problem.

All four images together

What is that XeTeX needs from the PNG's to preserve their color when included in a page?

For experimentation here are the same images, after opening and closing with GIMP:

enter image description here

enter image description here

Edit on Jan 10, 2021: The problem only displays when run under XeLaTeX. There are no problems under pdfLaTeX or LuaLaTeX.

Edit on Jan 11, 20201: Ulrike Fischera (at TeXhax) have determined the problem lies with dvipdfmx, the backend of xetex processing. She and and David Purton (below) looking at the PDF found that it uses the wrong color space (CalRGB) for the first two images and DeviceRGB for the last two.

  • 1
    LaTeX cannot modify the Images in any way. Using your MWE \pagecolor{bgcolor} match with the four backgroungs of your images, and using \definecolor{bgcolor}{RGB}{71,56,74} match only with nested darker images (2nd and 3th image). It is a problem of the original files that is not in what you posted. The difference of colors seems that of a CMYK to RGB conversion (afaik, PNG cannot manage information in CMYK format).
    – Fran
    Commented Jan 9, 2021 at 7:00
  • HI Fran, I tried to make the images smaller in the posting (using the "m" at the end of the URL) and SX converted them from PNG to JPEG's. I undid everything, and you now have the real images (all four) used in the MWE -- the first two images of the posting and the last two. Some of the other things you bring up seem to be a misunderstanding. LaTeX has clearly changed the image. You can see that on the third image and if you use a color picker you can see the RGB values have been changed from (80,64,83) in the images by itself to (71,56,74) in the included image.
    – Paulo Ney
    Commented Jan 9, 2021 at 18:25
  • ... continuing, the background matches the last two images, but not the first two. It matches only the ones that have been opened and saved in GIMP, even though all RGB values are the same. And finally, there are no CMYK steps in this process, all images have been generated as PNG's using RGB and the LaTeX file is fully in RGB as well.
    – Paulo Ney
    Commented Jan 9, 2021 at 18:30
  • Do your PNG files have embedded colour profiles? Commented Jan 10, 2021 at 10:08
  • @DavidPurton That could be the difference. That GIMP goes there and embeds the profile in the PNG. How do you check for profiles in a PNG?
    – Paulo Ney
    Commented Jan 10, 2021 at 18:11

2 Answers 2


There are some colour space related differences between your original images and the ones saved through Gimp.

You can see them using identify -verbose from ImageMagick.

Inspecting the resulting PDF file shows that your original PNGs end up using the CalRGB colour space, while the Gimp ones just use DeviceRGB. This is enough to create the colour shift in your PDF.

I think your best option is to remove all the ICC colour profile information from your original PNG files. This will ensure that the images in the PDFs are treated in the same way as your solid colours.

Again, you can do this using ImageMagick:

Just run: mogrify -strip A.png.

  • @DavidPuton, I did compare the output of identify -verbose of both images and there were two things that called my attention, one was the value of Gamma changing from 0.45455 to 0.454545 and the other was the value of Background color changing from srgb(254.012,254.012,254.012) to white. Besides these two, are there anything else that jumps at you as being different?
    – Paulo Ney
    Commented Jan 11, 2021 at 5:23
  • I also should say that I already knows several ways to make the image blend with the background: 1) Open up in GIMP and save it, 2) Use pdflatex, 3) Use lualatex ... but that is not what I am after. What I am after is: 1) What is wrong with the initial image that trows off xelatex? Or 2) What is xelatex doing wrong with the image.
    – Paulo Ney
    Commented Jan 11, 2021 at 5:26

Three PNG images created with GIMP with RGB values of 71,56,74; 79,62,82 and 80,64,83, respectively:

1.png: 1.png      2.png: 2.png      3.png: 3.png

Now framed: The first row have frames in a distinctive color for reference. The second row have the same frmaes but frames with color defined in LaTeX that should match the image color. The other two rows have the same frames with in different position for close comparison of the three colors.



As you can see here, LaTeX defined colors match perfectly by the RGB values of the images.

Note that your first original PNG is not the "color3" in my example, but "color2" (at least in Chrome, Xviewer or color-picker, the RGB value is 79,62,82).

For some reason, in your first file (but not in my file 2.png) that have 79,62,82 ("color2") is showe in LaTeX PDF as 71,56,74 ("color1") whereas in Gimp window changed to 80,64,83 ("color3"). I have no idea if this happens because your file is indexed, corrupt or something else. With three different interpretations of the same file is hard to say which program is wrong or why. But when the PNG is made or saved by Gimp (2.png) there are not different interpretations of what it should be in the PDF of LaTEX, the imaged posted here, or in the Gimp window, so it seems not a problem of LaTeX, but of the original image. Maybe a non-standard PNG file header?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .