Possible bug related to the ‘geometry’ property

[to7m]

Hi all,

I think I found a bug in the ‘convert’ program.

convert -size 15x4 xc:#000000 1.png
convert -extract 12x4+3+0 1.png 2.png
convert 2.png -resize 3 3.png
convert -extract 2x1+0+0 3.png 4.png
identify *

If I'm right, 4.png should be a 2x1 file, but it is instead 1x1. These seems dependent on the ‘geometry’ property as listed by ‘identify’. Could someone confirm this is a bug, or if it isn't explain the ‘geometry’ property to me please?

Version: ImageMagick 6.9.9-13 Q16 x86_64 2017-09-13

[glennrp]

Confirmed the behavior you observed.
You can get the result you expected by adding "+repage" to the third line:

Code: Select all

convert 2.png -resize 3 +repage 3.png

The recorded offset is interfering somehow with the conversion.
You can also get the result you expected by using PPM instead of PNG for the
files (PPM doesn't store offsets).

[to7m]

Perfect, thank you!

[fmw42]

extract creates a virtual canvas that is saved in the png. You need to remove that using +repage before saving to png.

Try

Code: Select all

convert -extract 12x4+3+0 1.png +repage 2.png
identify 2.png
2.png PNG 12x4 12x4+0+0 8-bit sRGB 2c 259B 0.000u 0:00.009
convert 2.png -resize 3 3.png
identify 3.png
3.png PNG 3x1 3x1+0+0 8-bit sRGB 2c 258B 0.000u 0:00.009
convert -extract 2x1+0+0 3.png +repage 4.png
identify 4.png
4.png PNG 2x1 2x1+0+0 8-bit sRGB 2c 258B 0.000u 0:00.000

[to7m]

Thanks

I should also mention this seems to happen with .mpc too.

[fmw42]

Several image formats; notably PNG, TIFF, MIFF, MPC all save the virtual canvas data. JPG and GIF do not. So you need to be careful which format to which you save or just use +repage to be sure to get rid of it when you do not want to keep it.

[to7m]

Thank you, noted Could you link me to something that explains the virtual canvas data please?

[snibgo]

http://www.imagemagick.org/Usage/basics/#virtual_canvas