PNG: simple read/write changes image, color count

[tc33]

Hi,

Using IM 6.8.0.2 x64 debug build on Win7, a simple file read & file write noticeably changes the shading of the following image:

Source file: http://cssignet.free.fr/png-test-corpus ... dbe-c0.png

I am using the Magick++ interface, but was also able to reproduce this same behavior with convert.exe

Convert.exe:

Code: Select all

convert "01-c3-shouldbe-c0.png" "01-c3-shouldbe-c0.converted.png"

Magick++ (same behavior)

Code: Select all

Image input;
input.read( "01-c3-shouldbe-c0.png" );
input.write( "01-c3-shouldbe-c0.imread.png" );

using Irfanview, I also noticed the color count decreases from 149 -> 146.

Update: Looping on a read/write causes the progressive degradation of the image. Here is some sample code which continually degrades the image, in visual display, color count, and file size. It gets worse with each iteration. Why?

Code: Select all

void png_degrade_test( const string& file_name )
	{
		Image img;
		img.read( file_name );

		for ( int i = 0; i < 5; i++ )
		{
			string ofname = file_name + "." + util::to_string( i ) + ".png";  
			img.write( ofname );
			img.read( ofname );
		}

	}	

What am I doing wrong? I would expect simple read/write operations to be lossless

Thanks

[glennrp]

If the image has only gray pixels, there may be a confusion of sRGB versus RGB, and it's possible that a loop is continually converting back and forth and losing precision each time around. I have noticed that that happens when converting between PNG and PNG24 formats, unless -colorspace RGB is used. I have not yet nailed down exactly what is happening but am working on it (I didn't try looping the command but assume the the loss would accumulate; I'll test that now).

edit: Yes, the number of colors decreases continually unless I use "-colorspace rgb".

[fmw42]

I believe that is because since IM 6.7.8.3 grayscale images are now treated as linear and thus display darker. see viewtopic.php?f=4&t=21269

add to your command after reading the input and before the output

convert grayimage.png -set colorspace RGB newgrayimage.png

That fixes the output for me on IM 6.8.0.2 Q16 Mac OSX Snow Leopard.

[tc33]

Thanks for the replies. What can I do to detect/work around this issue programmatically? I'm in the process of creating some specialized image manipulation routines in C++ ; I have a requirement to be able to handle a variety of inputs, and produce a lossless output. I'm assuming I can't just globally assume a single colorspace for all image inputs? Or is this just an edge case/bug I'll have to live with for a while?

Thanks again

[fmw42]

In looking at the input and output verbose information. They both look the same. (Using IM 6.8.0.2 Q16 Mac OSX Snow Leopard).

convert 01-c3-shouldbe-c0.png 01-c3-shouldbe-c0_conv.png

Image: 01-c3-shouldbe-c0.png
Geometry: 292x285+0+0
Page geometry: 292x285+0+0
Class: PseudoClass
Colorspace: sRGB
Type: Palette
Depth: 8-bit
Alpha: False
Channels: srgb
Rendering intent: Perceptual
Gamma: 0.454545
Chromaticity:
red primary: (0.64,0.33)
green primary: (0.3,0.6)
blue primary: (0.15,0.06)
white point: (0.3127,0.329)
Colors: 149
Overall:
min: 107 (0.419608)
max: 255 (1)
mean: 189.221 (0.742042)
standard deviation: 56.3259 (0.220886)


Output:

Image: 01-c3-shouldbe-c0_conv.png
Geometry: 292x285+0+0
Page geometry: 292x285+0+0
Class: PseudoClass
Colorspace: sRGB
Type: Palette
Depth: 8-bit
Alpha: False
Channels: srgb
Rendering intent: Perceptual
Gamma: 0.45455
Chromaticity:
red primary: (0.64,0.33)
green primary: (0.3,0.6)
blue primary: (0.15,0.06)
white point: (0.3127,0.329)
Colors: 146
Overall:
min: 37 (0.145098)
max: 255 (1)
mean: 146.939 (0.576231)
standard deviation: 89.5031 (0.350992)


The only difference I see is a change in number of palette colors and change in statistics. There is no indication of a change from sRGB to (linear) grayscale, though the output image does seem to indicate that behavior or something similar, which could be due to the reduction in number of colors.


Therefore I am not sure why the result has been darkened or made linear? This appears to be a bug to me and I would suggest you post to the bugs forum and reference this topic in the user's forum. Also post your image there and the output image and your IM version and platform.



P.S. It might have something to do with the PNG meta data, but I tried -strip and the output was still the same darker grayshades after converting from png to png. I am not sure -strip should affect that data, however.

Magick or glennrp would need to look at this to decide if there is really a bug somewhere in the colorspace management.

P.S. 2 It looks like Glenn is already looking into this from his post above, which I missed or was posting at the same time earlier.

[tc33]

Thanks for the reply and your assistance with this issue. Bug posted as requested:

viewtopic.php?f=3&t=22130