I've been battling with this error (bug?) in imagemagick:
% convert \
> \( logo: -crop 100x100+300+300 -gravity west \) \
> \( logo: -crop 100x100+300+300 -gravity west \) \
> +append out.png
convert: geometry does not contain image ("100x100+300+490") `LOGO' @ warning/transform.c/CropImage/599.
Where does the number 490 come from??
ImageMagick's example image logo:
is 640x480px. The crop geometry 100x100+300+300
is clearly entirely within the 640x480 bounds of logo:
.
Of course the output I am expecting is the side-by-side of two identical 100x100+300+300
crops from logo:
But I am getting this funky error instead. If a previous parenthesised input image has a -gravity
switch, then subsequent parenthesised inputs have their crop geometries warped in different ways:
% convert \( logo: -gravity east \) \( logo: -crop 10x10+630+470 \) +append out.png
convert: geometry does not contain image ("10x10+0+705") `LOGO' @ warning/transform.c/CropImage/599.
How can I prevent any -gravity
switches in parenthesised input images from affecting other parenthesised inputs?
Three suggestions...
First, the "-gravity" setting should be before the operation that uses it.
After the operation that the uses the "-gravity" setting put just "+gravity" to end the setting.
If you use "-respect-parenthesis" before the parentheses, then the "-gravity" settings you make inside the parentheses won't continue to be in effect after them. You can use "+respect-parenthesis" to end that setting.