Potential Bug "%@" string format IM 6.9.1.10 Q16 Mac OSX SnowLeopard

[fmw42]

# create a 256x256 black image and trim and repage to make a 1x1 fully transparent white pixel image

Code: Select all

convert -quiet -size 256x256 xc:black -trim +repage tmp.png
convert tmp.png -format "%c" histogram:info:

1: (255,255,255, 0) #FFFFFF00 graya(255,0)

# string form "%P%O" gives correct result

Code: Select all

convert -quiet tmp.png -format "%P%O\n" info:

1x1+0+0

# string format "%@" seems to have the size and offsets switched

Code: Select all

convert -quiet tmp.png -format "%@\n" info:

0x0+1+1

[fmw42]

Alternate test with similar results

Code: Select all

convert -size 200x100 xc:black -background white -gravity center -extent 300x300 -trim +repage tmp.png

# correct

Code: Select all

convert tmp.png -format "%P%O\n" info:

200x100+0+0

# reversed size and offsets

Code: Select all

convert  tmp.png -format "%@\n" info:

convert: geometry does not contain image `' @ warning/attribute.c/GetImageBoundingBox/247.
0x0+200+100

[magick]

The %@ format appears to be working properly. You get an exception of "geometry does not contain image" which means the geometry is undefined. You don't see the exception because you added -quiet to your command-line.

[fmw42]

The %@ format appears to be working properly. You get an exception of "geometry does not contain image" which means the geometry is undefined. You don't see the exception because you added -quiet to your command-line.

I purposely put in the -quiet in the first example to avoid the message, but that made no difference when it was not there. The result either way is a 1x1+0+0 image virtual canvas per identify -verbose.

Page geometry: 1x1+0+0

(Since the +repage is there, there could/should not be any non-zero offsets). So %@ has the size and offsets swapped.

The second example above shows this better, since it does not trim the image down to 1 pixel (but to 200x200). Look at those results again. The %@ says the image size is 0x0 and offsets are +200+200. That is wrong. The %P%O says the image size is 200x200 and the offsets are +0+0, which is correct.

Thanks

[fmw42]

# reversed size and offsets

Code: Select all

convert  tmp.png -format "%@\n" info:

convert: geometry does not contain image `' @ warning/attribute.c/GetImageBoundingBox/247.
0x0+200+100

The reason for the warning is the geometry size and offsets are swapped with %@. There is no warning and the geometry is correct with %P%O


This problem seems to be a very old one. It goes back at least as far as 6.8.3.10, which is as far back as I can go without recompiling older versions of IM.

[snibgo]

As I understand it, format %@ gives the result we would get from a trim. tmp.png is an entirely black image. A trim of a single-colour image gives an invalid result. So IM correctly reports that ...

Code: Select all

convert tmp.png -format "%@\n" info:

the "geometry does not contain image".

The actual result of the format is garbage, and should be ignored. We know from the first part "0x0" that it is garbage.

EDIT: well, "garbage" is the wrong word. The result is 0x0 pixels, ie no image at all, with a geometry outside the bounds of the input.

[fmw42]

Snibgo, you are right. Thanks for pointing that out. I made a mistake and did not quite understand %@ and %P. I should have tested the following for the second example:

Code: Select all

convert -size 200x100 xc:black -background white -gravity center -extent 300x300 -format "%@\n" info:

200x100+50+100

and

Code: Select all

convert -size 200x100 xc:black -background white -gravity center -extent 300x300 -trim tmp.png

convert tmp.png -format "%P%O\n" info:

300x300+50+100

Code: Select all

convert tmp.png -format "%wx%h\n" info:

200x100

Which are all correct. I was thinking that %P%O should be the same as %@, but the WxH from %@ is the trimmed size and the WxH from %P is the page geometry (virtual canvas).

So my comparison should have been between %@ and %wx%h%O

Code: Select all

convert tmp.png -format "%wx%h%O\n" info:

200x100+50+100



After a +repage, the virtual canvas will be reset, so

Code: Select all

convert tmp.png +repage -format "%P%O\n" info:

0x0+0+0

and

Code: Select all

convert tmp.png +repage -format "%wx%h%O\n" info:

200x100+0+0

So I think I now understand %@ and %P and %wx%h properly


In the trim everything away case, the only proper result seems to be the last one below, even though they all show warnings.

Code: Select all

convert -size 100x100 xc:black -format "%@" info:

convert: geometry does not contain image `' @ warning/attribute.c/GetImageBoundingBox/247.
0x0+100+100

Code: Select all

convert -size 100x100 xc:black -trim -format "%P%O" info:

convert: geometry does not contain image `black' @ warning/attribute.c/GetImageBoundingBox/247.
100x100-1-1

Code: Select all

convert -size 100x100 xc:black -trim -format "%wx%h%O" info:

convert: geometry does not contain image `black' @ warning/attribute.c/GetImageBoundingBox/247.
1x1-1-1

Code: Select all

convert -size 100x100 xc:black -trim +repage -format "%wx%h%O" info:

convert: geometry does not contain image `black' @ warning/attribute.c/GetImageBoundingBox/247.
1x1+0+0

This is confirmed by identify -verbose.

Code: Select all

convert -size 100x100 xc:black -trim +repage tmp.png
identify -verbose tmp.png

Geometry: 1x1+0+0

 Histogram:
 1: (255,255,255,  0) #FFFFFF00 graya(255,0)

Page geometry: 1x1+0+0

So there seems to be a 1x1 fully transparent white pixel according to identify -verbose.

If I append another image, the result is bigger by 1 pixel.

Code: Select all

identify -format "%wx%h\n" rose:

70x46

Code: Select all

convert tmp.png rose: +append -format "%wx%h\n" info:

71x46

But interestingly, if I extend tmp.png I get an image the size and color of the extent and there is no sign of the single transparent pixel.

Code: Select all

convert tmp.png -background black -extent 100x100 tmp2.png
identify -verbose tmp2.png

 Geometry: 100x100+0+0

 Histogram:
 10000: (  0,  0,  0) #000000 gray(0)

Page geometry: 100x100+0+0

So I am not really sure what is happening with the trimmed away result.

Is there really a 1x1 pixel image or as you seem to suggest only a null image with a virtual canvas 1x1+0+0.


I think the extent is just recoloring the transparent data, since I can do the following and get a fully black image with no sign of the transparent result.

Code: Select all

convert -size 10x10 xc:"#ffffff00" -alpha on -channel rgba \
-gravity center -background "#000000FF" -extent 30x30 tmp3.png

[snibgo]

I recall, some years ago, making the case that IM doesn't handle 0x0 images well. As some operations can result in a 0x0 image, I thought (and still think) that IM should be able to correctly continue processing. For example, adding a border width 1 to a 0x0 image would create a 2x2 result.

But that's not how IM works. It can't handle 0x0 images, and may substitute a 1x1 image.