GIMP vs Photoshop vs other imports of a PDF: gamma differences

Software GIMP
1

Hi! I’m trying to understand why my files are not printing as I expect, and I’ve noticed a difference between GIMP and Photoshop that I don’t understand.

TLDR: is there a difference between how Adobe products render bitmaps (especially gamma/tone curve) in PDFs compared to GIMP, and if so, can anything be done on the FOSS side to emulate this?

This file: http://caseyconnor.org/pub/calendar/gry.pdf
…has two grey rectangles (overlapping a little). One is a vector element with rgb(120,120,120) and the other is a GIMP-exported PNG with pixels of value rgb(120,120,120) (no color profile embedded, though it doesn’t seem to make a difference anyway.)

If I import that PDF into GIMP, the result is a single solid grey rectangle – i.e. the two areas are indistinguishable, as expected. Same result if I view the PDF in Okular, Firefox, etc. I get the same result if I open it in Adobe Illustrator.

But if I open it in Photoshop, the bitmap rectangle is different (significantly lighter). (I have ancient CS2 versions of Adobe software in a virtual XP machine.)

This is a problem because I’m generating SVGs programatically, including photos I’ve processed in GIMP, converting to PDF with inkscape, and sending them to a printing place to be printed, and the colors of the vector elements aren’t matching the images (I believe the print house is using Adobe products in its printing chain.) It seems as if a very different tonal curve is being applied to the bitmap images.

GIMP’s results seem more intuitive to me: I’m not using any unusual color profiles and would expect the rectangles to match. Yet the end result of this FOSS production chain is that I can’t design stuff and know how it will look when printed: the vector elements don’t match the bitmaps.

Does anyone know why this might be happening? And/or a way to use GIMP/Inkscape/my custom SVG generation/etc to generate files that will print predictably? My first thought was to embed GIMP’s sRGB profile into the SVG in the hopes that it would be picked up downstream, but that may not even be an option: the library I’m using (svgwrite) doesn’t appear to support that, and I’m not sure it’s possible to convert the generated SVG in Inkscape either…

I don’t mean to ask Photoshop questions here; I know it’s not the place. But it’s hard to find an ideal place to ask questions that overlap five pieces of software. :slight_smile:

Thanks for any insight.

2

Yikes… There is a lot going on there. First thing I’d check is that your using the same ICC profile for everything in your toolchain.

If you’re going to print via PDF, then Scribus is likely your only option to produce a PDF that is acceptable.

3

Yes, that is a lot of steps. Make sure you go through each to see where the weak point of the chain lies. I have a feeling it has to do with Inscape and / or SVG.

4

Thanks for the responses — I think it led me to some partial answers.

It seems that when inkscape saves a PDF, it somehow sets some kind of brighter tone curve for bitmap images that is noticed by Adobe products but not by GIMP et al., but this is apparently only relevant for grayscale images. When I export the same SVG to PDF via Scribus, as you suggested, the colors render properly in Adobe products (although I have to use the “screen/web” setting in the color tab on export or the colors will be altered). In all cases the results are read properly by GIMP et al. It’s just the Adobe products that seem affected by the Inkscape PDF.

I’ve been inspecting my PNGs with “identify -verbose file.png”. Interestingly, even if I am editing an RGB-mode image in GIMP which contains only gray pixels, and export to PNG while manually setting the pixel format to “8bpc RGB”, it still exports to a “Type: Grayscale” PNG, and the non-matching issue occurs in Adobe products when exporting from Inkscape. If I change to the grayscale color mode in GIMP, and export to grayscale PNG, the resulting PNG is still in “Type: Grayscale” but now has an additional “Colormap:” section that specifies the grey levels. I have some things to learn about PNGs. At any rate, it was yet another issue that threw me off, as I didn’t think of my grey test patches as being materially different from my photographs, when in fact the GIMP PNG export was changing them to “Grayscale” mode despite me explicitly trying to avoid that. (Adding one pixel with chroma content prevents this from happening.)

The big irony is that I went down this rabbit hole because the vector elements in my prints didn’t match my screen, but none of these issues applied to those elements (since they are not Grayscale mode PNGs), which means that my original issue is just due to my incorrect expectation that the print would be brighter than it actually was. So I didn’t solve that problem, but that’s on me, not the software. :slight_smile:

edit: P.S. – do you reckon I should report this as an Inkscape bug, or is this one of those “at the discretion of the implementer” kinds of things?

5

PNG files have metadata describing color and tone aspects of the image, including a specific gamma chunk:

http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.gAMA

do a exiftool -G file.png and look for it.

Regarding images in PDF, I wasn’t able to find anything before supper…

6

Thanks – no gAMA chunks to be found, at least in the original PNGs. I don’t know a way to test what is actually getting embedded in the PDFs – maybe Inkscape is doing it on the way out. (Subsequent importing/conversion back to SVG, and decoding of the base64 from the SVG, reveals no gAMA chunks either, in either the Inkscape or Scribus PDFs, for whatever that may be worth.)

When testing this, I made four PNG files, all starting with RGB-mode in GIMP with all pixels at rgb 120,120,120.

The first is all gray as described but has a single red pixel and is exported with pixel format “8bpc RGB”.
The second has all gray pixels and is exported with pixel format “8bpc RGB”.
For the third I change to color mode grayscale in GIMP, then export with pixel format “8bpc RGB”.
The fourth stays in color mode grayscale and exports with pixel format “8bpc GRAY”.

The first works fine, the last three exhibit the issue (but again, only when exporting to PDF from Inkscape, and only when importing into Adobe products.)

The last three are all “Type: Grayscale” (which is revealed via identify -verbose, but not exiftool), although they have varying metadata depending on which version they are. The impression I’m getting is that GIMP exports RGB-mode-but-actually-grayscale images to Grayscale data, but when told to use “RGB” pixel format it sets a PNG header saying “this is actually an RGB image”, rather than writing a real RGB PNG, to save space or whatever. But the Grayscale PNG type is apparently what triggers the issue, so all of the latter three exhibit the problem.

7

Just thinking aloud. May or may not apply to you.

1 PNGs have always been sketchy, even though support has improved incrementally over the years.

2 When importing bitmaps, there is a possibility for the data to dissociate from the metadata, so an app may apply its own assumptions or interpretation to the output file.

3 In terms of grey scale, sometimes the app works on one channel G or I instead of 3. That could cause trouble in blending situations, which happens often in SVG / PDFs.

8

I’ll see what they say over at Inkscape… maybe it’s just one of those discretionary issues. Regardless, it’d be nice if GIMP/Inkscape/Scribus could harmonize on it so there aren’t the nasty surprises when it comes to printing somewhere…

9

I recently read a long article about image file storage, and it flatly stated that PNG should not be used. If I can find the link, I will update this post.

Here’s a link to a different article, but it is in agreement with the one I read a while back.

https://99designs.com/blog/tips/image-file-types/

10

In case anyone finds this, here’s the update:

A bug has been filed for Inkscape – it’s not clear to me if Inkscape is really doing anything wrong, but hopefully the developers there will have something to say. It seems (from inspection of the images embedded in the exported PDF) that Inkscape is changing some things about the PNG, as shown in the results of “identify -verbose”.

I’m still curious about why GIMP exports to grayscale PNGs even when 8bpc RGB is forced on the output, but maybe that’s just what’s expected when you export an actually-grayscale image to PNG, I wouldn’t know.

11

These statements about png are wrong, and article is rather sketchy and amateurish. As long as data is stored and not corrupted in bitmap any of formats are good, except animated gifs. You will probably have problems with old printers that couldn’t work with some formats. It is comes down to image resolution, not compression method or container.

12

Just to update the thread: this was accepted as a low-priority bug at Inkscape: Inconsistent tone curve with embedded grayscale PNGs when exporting to PDF and importing to Photoshop, or converting on zamzar.com (#1934) · Issues · Inkscape / inkscape · GitLab

…not sure what its odds of it getting fixed are, but one can track it over there. And as Nathan Lee mentioned (on that bug), Inkscape now supports the option of using Scribus (if it’s installed) to export PDFs, which as far as I know should avoid the bug.

1 Like