Implicit geometry arguments for -vignette are affected by %

[Taemojitsu]

ImageMagick version

6.9.11-60

Operating system

Linux

Operating system, version and so on

Ubuntu 21.10

Description

Vignette is supposed to default to 20% of each dimension, or 10% on each side, being outside the central ellipse. If the "%" symbol is included in '-vignette's geometry argument, the default or implicit values for the "+X+Y' parts are treated as percents, resulting in the ellipse shrinking to zero size as image size approaches 500.

That is, IM is calculating default values as 10% of the dimension, in pixels, but this pixel number is being treated as a percent. At +50+50, the ellipse has zero size.

Note: this bug does not affect me, as I have decided that general use of 'vignette' should be done by operating on a smaller image and resizing it, like so:
resize=">1920x"; i=alpha_image.png; WxH=$(identify -ping -format '%wx%h' "$i"); convert -quality 85 -sampling-factor 2x2 -size 120x120 xc:black -background grey90 -vignette "%24x24+20+2" -shave "%25x25" \( +clone -flip -flop \) -compose blend -define compose:args=50 -composite -resize 200% -alpha off xc:"#605A5C" +swap -compose copy-opacity -composite \( gradient:'#2C2420-#E4E7D5' -gamma 0.7 +level %50,100 \) -resize "$WxH"\! +swap "$i" ${resize:+-resize} $resize +swap -compose src-over -background none -flatten "${i/%png/jpg}"
This is 15~20 times faster than using vignette with appropriate values for circle radius and sigma for an image about 3000x3000 in size (around 150, since they scale directly with image size). (I know this has an unnecessary resize for the added layers, but fixing requires either replicating IM's math or an extra read of the image with resize to get final size.)

However, users who are using vignette directly on an image, and who think that radius and sigma are affected by "%" (they are not), might be confused by this bug.

And if this is already fixed in 7.x, that's great.

Steps to Reproduce

Ellipse fills the screen:
convert -size 100x100 xc:black -background grey70 -vignette "8x8" x:

Same output, with "%":
convert -size 100x100 xc:black -background grey70 -vignette "%8x8" x:

Larger image without "%" has a larger circle, with same absolute blur but less relative blur:
convert -size 400x400 xc:black -background grey70 -vignette "8x8" x:

Larger image with "%" has a smaller circle, with same absolute blur:
convert -size 400x400 xc:black -background grey70 -vignette "%8x8" x:

Not sure if bug:
Is the "+8" value being used for anything? Sharp circle:
convert -size 400x400 xc:black -background grey70 -vignette "%8+8" x:

Invalid option (convert-im6.q16: invalid argument for option `-vignette': 8+8 @ error/convert.c/ConvertImageCommand/3131):
convert -size 400x400 xc:black -background grey70 -vignette "8+8" x:

I thought the position of "%" didn't matter, but it is somehow turning an invalid argument into one where one of the values is possibly being used. Encountered this because I accidentally used an argument like "%8+8+20+20", which is apparently ignoring some or all of the values without giving an error, since the first "+" should be an "x".

Images

No response

[snibgo]

That is, IM is calculating default values as 10% of the dimension, in pixels, but this pixel number is being treated as a percent. At +50+50, the ellipse has zero size.

Please show an example. For example:

magick toes.png -background Blue -vignette 0x2+50+50 x.png

For IM v7.1.0-32 and v6.9.9-50, this seems to work as documented, with a gap of 50 pixels at top, bottom, left and right of the ellipse.

Radius and sigma are not affected by "%", as you say. Perhaps the documentation at https://imagemagick.org/script/command-line-options.php#vignette could be clearer.

Starting the arguments with "%" is a bad idea. This is because IM v7, when using "magick", allows for percent escapes, including "%[fx:...]", in that position. For example:

magick toes.png -background Blue -vignette "%wx%w" x2.png

magick toes.png -background Blue -vignette "%[fx:w/4]x%w" x3.png

The language is ambiguous, so if you start with "%", IM does not know if that starts an expression or qualifies the x and y as percentages.

[urban-warrior]

We clarified the documentation.