Some PNG images get corrupted

[Jason S]

Here's a small 16-bit RGB PNG image with binary transparency:


Run it through "convert", with no options. Using the Cygwin 6.7.6-3 release, the top row gets corrupted:


With 6.7.6-9 on Cygwin, I get similar but not identical corruption. With a Linux 6.7.6-9 Q16 build, just two pixels near the top incorrectly become transparent. With a native Windows build, I haven't seen any corruption.

The same problem occurs with other (all?) small (under about 750 pixels?) images of the same type.

[fmw42]

I don't see any corruption of your input or output image. Repeating

convert ctest.png ctest2.png

Still no corruption.

compare -metric rmse ctest.png ctest2.png null:
0 (0)


I am using IM 6.7.6.10 beta (doing some testing of other issues), Mac OSX Snow Leopard.

If I compare your two images, I see some colorization differences. This may(?) be due to the recent changes in how IM handles sRGB especially in PNG from sRGB with rendering intent=undefined to sRGB with rendering intent=perceptual. However, it should not affect the actual pixel data, only the viewing of the images. So I am not sure why you get this much difference.


compare -metric rmse ctest.png ctest-cygwin-6.7.6-3.png null:
1406.47 (0.0214614)

You could try upgrading as I don't see that issue.

I will defer to the IM developers on this one, if it is not caused by the change in rendering intent and possible bugs along the way.

[Jason S]

There is some unknown factor that determines whether this problem occurs, so I don't expect everyone to be able to reproduce it.

But if you're suggesting the two images in my report are visually identical to you, I don't really know what to say.

Note that 'compare' appears to also be affected by the problem, so its calculations on these images should not be trusted.

[fmw42]

There is some unknown factor that determines whether this problem occurs, so I don't expect everyone to be able to reproduce it.

But if you're suggesting the two images in my report are visually identical to you, I don't really know what to say.

Note that 'compare' appears to also be affected by the problem, so its calculations on these images should not be trusted.

Sorry if I was not clear. I said there was a slight visual color difference and that the compare shows a significant difference, but only with the images you presented. I could not reproduce the situation as my own processing and compare showed no difference visually or in the pixel data.

[Jason S]

Using valgrind, I get dozens of "uninitialised value" warnings that I don't get with other types of PNG images.

For example,

Code: Select all

 Use of uninitialised value of size 8
    at 0x4C2A291: memcpy (mc_replace_strmem.c:635)
    by 0x5296466: ??? (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4)
    by 0x5296937: ??? (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4)
    by 0x5297B49: deflate (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4)
    by 0x5078F65: ??? (in /lib/x86_64-linux-gnu/libpng12.so.0.46.0)
    by 0x50793DA: ??? (in /lib/x86_64-linux-gnu/libpng12.so.0.46.0)
    by 0x507D025: png_write_row (in /lib/x86_64-linux-gnu/libpng12.so.0.46.0)
    by 0x4FB609: WriteOnePNGImage (png.c:10487)
    by 0x4FF8B5: WritePNGImage (png.c:11576)
    by 0x540298: WriteImage (constitute.c:1228)
    by 0x540B4F: WriteImages (constitute.c:1377)
    by 0x5DB9A4: ConvertImageCommand (convert.c:3026)

[glennrp]

Jasom, I'm not sure this is relevant but from the traceback you seem to be using an old libpng (1.2.46) and zlib (1.2.3.4)
That should be OK but you never know... I don't see anything in the libpng CHANGES file that would explain a
change in behavior from 1.2.46 to the current 1.2.49 though.

Does "convert -list format | grep PNG" say the same?

[glennrp]

It may be due to png.c doing things like

• quantum_info->format=UndefinedQuantumFormat;
  quantum_info->depth=image_depth;

instead of using

• SetQuantumDepth(...) and SetQuantumFormat(...)

It's possible that some members of quantum_info are not being
set this way. I will look into this more later.

[Jason S]

I was using an old version version of libpng and zlib in that case (because I used what was provided by the Ubuntu distribution managers). Sorry for the lack of details, but I didn't expect this to be hard for others to reproduce.

I've had a chance to try it with the latest libpng, and it didn't help.

Code: Select all

      PNG* rw-   Portable Network Graphics (libpng 1.5.10)

"valgrind --track-origins=yes" gives more details, such as

Code: Select all

 Conditional jump or move depends on uninitialised value(s)
    at 0x6A3CCE: png_write_find_filter (pngwutil.c:2620)
    by 0x6A0D13: png_write_row (pngwrite.c:814)
    by 0x533118: WriteOnePNGImage (png.c:10487)
    by 0x536ADF: WritePNGImage (png.c:11576)
    by 0x576FD2: WriteImage (constitute.c:1228)
    by 0x5793D0: WriteImages (constitute.c:1377)
    by 0x63C838: ConvertImageCommand (convert.c:3026)
    by 0x657AA5: MagickCommandGenesis (mogrify.c:159)
    by 0x40AC24: main (convert.c:81)
  Uninitialised value was created by a heap allocation
    at 0x4C2415D: malloc (vg_replace_malloc.c:195)
    by 0x555B2E: OpenPixelCache (cache.c:3913)
    by 0x55876A: GetImagePixelCache (cache.c:2092)
    by 0x5589B1: QueueAuthenticPixelCacheNexus (cache.c:4367)
    by 0x5568B0: QueueAuthenticPixels (cache.c:4530)
    by 0x528819: ReadOnePNGImage (png.c:2888)
    by 0x529140: ReadPNGImage (png.c:3670)
    by 0x577967: ReadImage (constitute.c:590)
    by 0x578B4A: ReadImages (constitute.c:903)
    by 0x63A725: ConvertImageCommand (convert.c:598)
    by 0x657AA5: MagickCommandGenesis (mogrify.c:159)
    by 0x40AC24: main (convert.c:81)

which suggests a patch that is probably overkill, but does seem to work.

Code: Select all

--- magick/cache.c.orig 2012-05-06 14:59:24.000000000 -0400
+++ magick/cache.c      2012-05-17 15:26:03.143246372 -0400
@@ -3912,6 +3912,7 @@
   cache_info->mapped=MagickFalse;
   cache_info->pixels=(PixelPacket *) AcquireMagickMemory((size_t)
     cache_info->length);
+  if (cache_info->pixels) ResetMagickMemory(cache_info->pixels,0,cache_info->length);
   if (cache_info->pixels == (PixelPacket *) NULL)
     {
       cache_info->mapped=MagickTrue;