32 bpp PNG -> 8 bpp PNG problem

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
scraft
Posts: 3
Joined: 2012-06-20T10:00:20-07:00
Authentication code: 13

32 bpp PNG -> 8 bpp PNG problem

Post by scraft »

I'm not really sure if this is a bug or not... if not it is a help/advice request!

I have an input image: https://dl.dropboxusercontent.com/u/485 ... /Input.png

Image

I perform the following:

Code: Select all

Magick::Image img( "Input.png" );
img.write( "Output.png" );
And the following image is created: https://dl.dropboxusercontent.com/u/485 ... Output.png

Image

In Photoshop The input image is made up of a single colour, RGB( 139, 139, 139 ), the output image has been converted to grayscale (nothing wrong with that), however the colour is 45% i.e. RGB( 159, 159, 159 ). To me this feels like I bug; I understand (and appreciate) that ImageMagick is able to save out in optimal formats, however I'd expect the output image to match the input image (with a lossless format I'd expect a 100% match of the pixels).

So initially it definitely sounds like a bug, however, the images, when shown in a webpage (like this one) shows both images the same:

Image

Based on the webpage rendering of the images everything looks fine. My expectation at this stage is that Photoshop is doing something wrong (or perhaps looked at from a different viewpoint, Photoshop is treating the images in a way that Adobe deems as correct, but makes no sense to me)!

Any thoughts?
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: 32 bpp PNG -> 8 bpp PNG problem

Post by snibgo »

What version of IM, on what platform?

With IM v6.8.9-5 on Windows 8.1, the conversion:

Code: Select all

convert input.png c.png
... makes an output with all pixels (139,139,139), the same as the input.

However, I do get the warning:

Code: Select all

convert.exe: iCCP: Not recognizing known sRGB profile that has been edited `input.png' @ warning/png.c/MagickPNGWarningHandler/1831.
snibgo's IM pages: im.snibgo.com
scraft
Posts: 3
Joined: 2012-06-20T10:00:20-07:00
Authentication code: 13

Re: 32 bpp PNG -> 8 bpp PNG problem

Post by scraft »

Version:

Code: Select all

#define MagickPackageName "ImageMagick"
#define MagickCopyright  "Copyright (C) 1999-2014 ImageMagick Studio LLC"
#define MagickSVNRevision  "15693M"
#define MagickLibVersion  0x689
#define MagickLibVersionText  "6.8.9"
#define MagickLibVersionNumber  2,0,0
#define MagickLibAddendum  "-1"
#define MagickLibInterface  2
#define MagickLibMinInterface  2
Platform, Windows 7, using a static compiled ImageMagick++ library.
User avatar
glennrp
Posts: 1147
Joined: 2006-04-01T08:16:32-07:00
Location: Maryland 39.26.30N 76.16.01W

Re: 32 bpp PNG -> 8 bpp PNG problem

Post by glennrp »

ImageMagick has added the gAMA chunk (with gamma=1/2.2) to Output.png, so the brightness of Input.png and Output.png depends upon how the viewing software handles the gAMA chunk if present and what it assumes when the gAMA chunk is not present or if the iCCP chunk is present and handled correctly. About a year ago ImageMagick started assuming a default gamma of 1.0 (linear) for grayscale images, while it assumes 1/2.2 (approximately sRGB) for color images. libpng16.1.1 through libpng-1.6.9 reject the iCCP chunk in your Input.png, but libpng-1.6.10 through current libpng-1.6.13 accept it.
Post Reply