Legacy ImageMagick Discussions Archive

Hello, I'm encountering what seems like a bug in ImageMagick 6.8.0-1, which is running on OS X 10.8.2 Mountain Lion and was compiled with Apple clang version 4.1 (tags/Apple/clang-421.11.65) (based on LLVM 3.1svn).

I'm using vncsnapshot-png which outputs a PNG file to stdout. (In fact, that code as written does not allow outputting the PNG to stdout; I've patched it locally to allow that.) I want to pipe this to convert but I invariably get an error like this:

Code: Select all

$ vncsnapshot -quiet -passwd passwd localhost - | convert png:- png:- > foo.png
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 0 green 8 blue 16
convert: Expected 8192 bytes; found 8139 bytes `-' @ warning/png.c/MagickPNGWarningHandler/1777.
convert: Read Exception `-' @ error/png.c/MagickPNGErrorHandler/1751.
convert: corrupt image `-' @ error/png.c/ReadPNGImage/3791.
convert: no images defined `png:-' @ error/convert.c/ConvertImageCommand/3044.
$

There's no error if I redirect vncsnapshot's output PNG to a file, then have convert read that file; this is what makes me think it's a bug in ImageMagick, not in vncsnapshot-png.

Code: Select all

$ vncsnapshot -quiet -passwd passwd localhost - > tmp.png
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 0 green 8 blue 16
$ convert png:- png:- < tmp.png > foo.png
$

I'd like to avoid that extra I/O. There's also no problem if I use the original vncsnapshot which outputs JPEG instead of PNG, but I'd prefer to start with a non-lossy source.

It seems that ImageMagick assumes that if any data is available to read, then at least 8192 bytes will be available to read, which is not necessarily the case if a program is producing the PNG data slowly.

To isolate the problem away from the vncsnapshot program, I turned to the slowcat python script which simply outputs an input file slowly. My test input file was created by taking a snapshot of a portion of my OS X screen using the Command-Shift-4 keyboard shortcut and dragging a rectangle. It seems not all files are affected; I had to take two snapshots before I got one that exhibited the problem.

Code: Select all

$ file in
in: PNG image data, 426 x 294, 8-bit/color RGB, non-interlaced
$ cat < in | convert png:- png:- > out
$ file out
out: PNG image data, 426 x 294, 8-bit/color RGB, non-interlaced
$ ./slowcat.py < in | convert png:- png:- > out
convert: Expected 8192 bytes; found 4602 bytes `-' @ warning/png.c/MagickPNGWarningHandler/1777.
convert: Read Exception `-' @ error/png.c/MagickPNGErrorHandler/1751.
convert: corrupt image `-' @ error/png.c/ReadPNGImage/3791.
convert: no images defined `png:-' @ error/convert.c/ConvertImageCommand/3044.
$

GraphicsMagick 1.3.17 has no problem with a slow input stream:

Code: Select all

$ ./slowcat.py < in | gm convert png:- png:- > out
$ file out
out: PNG image data, 426 x 294, 8-bit/color RGB, non-interlaced
$

We can reproduce the problem and have a patch. Look for it in ImageMagick 6.8.0-2 Beta within a day or two. Thanks.

Legacy ImageMagick Discussions Archive

convert: Expected 8192 bytes; found 8139 bytes

convert: Expected 8192 bytes; found 8139 bytes

Re: convert: Expected 8192 bytes; found 8139 bytes

Re: convert: Expected 8192 bytes; found 8139 bytes