convert: Expected 8192 bytes; found 8139 bytes

[ryandesign]

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.

[ryandesign]

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
$

[magick]

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.