Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PNG vs JPG color off by 1
#1
I am automating a process in Python and I am loading a PSD into GIMP, changing a fill layer's color, and then exporting the result to JPG and PNG.
I am setting the fill layer to a light grey #3F3F3F (63,63,63). e.g. with
Quote:gimp_color = gimpcolor.RGB(int(rgb[0]), int(rgb[1]), int(rgb[2]))
pdb.gimp_context_set_foreground(gimp_color)
mylayer.fill(FILL_FOREGROUND)

The JPG output has that same color as expected (#3F3F3F).
The PNG output has changed that area to #3E3E3E (62,62,62).
Some other color areas I set are also off by 1 in the PNG, but not the JPG. Out of 6 different fill layers, 4 are correct and 2 are off.
I would like to correct this. In fact, I was thinking PNG would be better because I do have some artifacts in the JPG where the compression changes things a bit and the PNG should be lossless.

I noticed these messages in the output which I thought might be related:

Quote:gimp_color_transform_new: using babl for 'sRGB IEC61966-2.1' -> 'GIMP built-in sRGB'
gimp_color_transform_new: using babl for 'GIMP built-in sRGB' -> 'sRGB IEC61966-2.1'
gimp_color_transform_new: using babl for 'sRGB IEC61966-2.1' -> 'GIMP built-in sRGB'
gimp_color_transform_new: using babl for 'GIMP built-in sRGB' -> 'sRGB IEC61966-2.1'
gimp_color_transform_new: using babl for 'GIMP built-in sRGB' -> 'sRGB IEC61966-2.1'
void gimp_gegl_convert_color_profile(GeglBuffer*, const GeglRectangle*, GimpColorProfile*, GeglBuffer*, const GeglRectangle*, GimpColorProfile*, GimpColorRenderingIntent, gboolean, GimpProgress*): converting buffer took 0.0109 seconds
Any tips on how I can avoid this issue of the color values in the PNG export being slightly off from what I set?
The two places I am seeing the "wrong" value in the PNG is (1) loading it into Paint.net and (2) in a WebGL shader that uses it as a texture. In both of those programs the values I am seeing are the same.
Reply
#2
There could be a bug(*). But in practice, Gimp 2.10 doesn't work with integer values for color channels, all the processing is done in floating point,  and your [0..255] colors are converted to floating point after applying a gamma correction, which for some values can put them close to a tipping point for a round-off. The integer values are accepted in scripts for compatibility.

IMHO unless you are using a rare built-in Gimp filter there are more efficient ways to do you image processing. There are image processing libraries around (pillow, the Python binding for ImageMagick....). Also, the image processing core of Gimp is called GEGL and can be used independently of Gimp.


(*) feel free to report it here.

PS: gimpcolor.RGB(int(rgb[0]), int(rgb[1]), int(rgb[2])) ? gimpcolor.RGB(*map(int,rgb))!
Reply
#3
(06-17-2021, 07:28 AM)Ofnuts Wrote: There could be a bug(*). But in practice, Gimp 2.10 doesn't work with integer values for color channels, all the processing is done in floating point,  and your [0..255] colors are converted to floating point after applying a gamma correction, which for some values can put them close to a tipping point for a round-off. The integer values are accepted in scripts for compatibility.

IMHO unless you are using a rare built-in Gimp filter there are more efficient ways to do you image processing. There are image processing libraries around (pillow, the Python binding for ImageMagick....). Also, the image processing core of Gimp is called GEGL and can be used independently of Gimp.


(*) feel free to report it here.

PS: gimpcolor.RGB(int(rgb[0]), int(rgb[1]), int(rgb[2])) ? gimpcolor.RGB(*map(int,rgb))!

Thank you for your reply, and for thinking beyond the scope of the original question.

1. Regarding the integer color values, that does not explain why the JPG output has the expected values but the PNG output does not. I need to get the PNG output to match the color values (like the JPG output).

2. Yes, I am aware of other processing tools we could use. The source PSD files from the design team have multiple groups, layers, and masks, and GIMP is a great tool for creating a composite for these in an unattended and automated environment without writing extra code. The existing PSD libraries for Python are not able to do this. Image Magick does not appear to have the features we need either. I am very familiar with pillow and magick and we use those (and even Blender) for image processing in other parts of our pipeline.

It sounds like you are very knowledgeable -- do you have any other ideas on how we might get the same output in the PNG to match an RGB input like we see when we export the composite to JPG?

Oh also I'll share how the composite is created and saved. Perhaps I should look at using file_jpeg_save (maybe quality 1.0 would work for me to avoid compression) or file_png_save (would any parameters help with this issue) instead?
Quote:file_jpeg_savenew_image = pdb.gimp_image_duplicate(image)
layer = pdb.gimp_image_merge_visible_layers(new_image, CLIP_TO_IMAGE)
pdb.gimp_file_save(new_image, layer, export_file, '?')
pdb.gimp_image_delete(new_image)
Reply
#4
No idea besides filing a bug with an example file (btw, can you attach a small XCF that reproduces the problem, with instructions to create JPG and PNG from it).

Otherwise see if exporting to some 3rd format (TIFF, TGA, BMP) does the right colors and then convert with an external tools (IM or else).
Reply
#5
(06-17-2021, 07:32 PM)Ofnuts Wrote: No idea besides filing a bug with an example file (btw, can you attach a small XCF that reproduces the problem, with instructions to create JPG and PNG from it).

Otherwise see if exporting to some 3rd format (TIFF, TGA, BMP) does the right colors and then convert with an external tools (IM or else).

Ok, thank you for the suggestions, I will look into these. I was hoping maybe it was a simple matter of somehow telling GIMP to convert everything to some generic/default color space before I made my changes and saved, but maybe not.
Reply
#6
(06-17-2021, 07:52 PM)af_luther Wrote:
(06-17-2021, 07:32 PM)Ofnuts Wrote: No idea besides filing a bug with an example file (btw, can you attach a small XCF that reproduces the problem, with instructions to create JPG and PNG from it).

Otherwise see if exporting to some 3rd format (TIFF, TGA, BMP) does the right colors and then convert with an external tools (IM or else).

Ok, thank you for the suggestions, I will look into these. I was hoping maybe it was a simple matter of somehow telling GIMP to convert everything to some generic/default color space before I made my changes and saved, but maybe not.

I assumed that your designers are using sRGB...
Reply
#7
Yikes, this is embarrassing, but I will share it anyway. In looking to create a small example to reproduce and digging deeper into the issue I discovered that the colors are correct in the immediate PNG output from GIMP, but another downstream process (using Image Magick) that makes a lower-resolution web-ready version of the PNG is where the colors are getting changed slightly. I mixed up the two files in my earlier analysis. Thanks again I do appreciate the help.
Reply
#8
(06-17-2021, 08:59 PM)af_luther Wrote: Yikes, this is embarrassing, but I will share it anyway. In looking to create a small example to reproduce and digging deeper into the issue I discovered that the colors are correct in the immediate PNG output from GIMP, but another downstream process (using Image Magick) that makes a lower-resolution web-ready version of the PNG is where the colors are getting changed slightly. I mixed up the two files in my earlier analysis. Thanks again I do appreciate the help.

Thanks for sharing. Nothing to be ashamed of. You can't fathom the number of bug reports or questions to StackOverflow that I eventually kept to myself because I found my error while making a watertight demo Smile
Reply


Forum Jump: