Problem with -extent

[el_supremo]

In viewtopic.php?f=1&t=15416, the OP is trying to add "homebrew" roundedrectangle corners to a thumbnail image. It works except that the thumbnail image is black. Writing intermediate results showed that the image was being correctly resized and the rounded rectangle applied correctly.

Using the logo: image, this is the command:

Code: Select all

convert logo: \
   -thumbnail "300x300>"  ( +clone  -threshold -1 \
   -draw "fill black polygon 0,0 0,25 25,0 fill white circle 25,25 25,0" \
   ( +clone -flip ) -compose Multiply -composite ( +clone -flop ) \
   -compose Multiply -composite ) +matte -compose CopyOpacity -composite \
   -background transparent -gravity center -extent 300x300 jan_logo.png

When extent has to make an image larger it must be creating the larger background and then compositing the image on top using the gravity or offset. The problem appears to be that it does not force the compose operation to be "Over" and what actually is done is to use whatever was the last -compose setting, in this case CopyOpacity.
The workaround for this example is to add "-compose Over" before the -extent operation.

Is this a bug or an undocumented feature of -extent?

Pete

[magick]

The extent option honors the image compose settings and therefore its not a bug. In most cases, users would want an "over" composite for an extent but there are some cases where another composite op is desirable. The fix, as you suggested, is to set the desired compose method with -compose.

[el_supremo]

Could the docs for -extent be modified to mention that the current -compose setting affects the result if the extent increases the size of the image?

Pete

[magick]

Done. Allow 24 hours for the patch to mirror world-wide.

[anthony]

Done. Allow 24 hours for the patch to mirror world-wide.

This was not done!

Extent documentation does not include information on the -compose effects. But then neither does -frame or -border which also use the same composition technique for the purposes of enlarging images.

References
http://www.imagemagick.org/Usage/crop/#extent
http://www.imagemagick.org/Usage/crop/#border
http://www.imagemagick.org/Usage/crop/#frame

And the specific reasons for the effects of these operators on 'transparent areas' which is another closely related issue!
http://www.imagemagick.org/Usage/misc/#border

[fmw42]

isn't -blur also affected by the -compose setting, too

[anthony]

isn't -blur also affected by the -compose setting, too

Nope. Blur does not use any composition at all.

It is a channel effected grayscale operator. In fact it is a 2 pass 1 dimentional convolution operator, as a opposed to -gaussian whcih is a 1 pass 2 dimentional convolution operator.

See Convolution, Gaussian vs Blur Kernels
http://www.imagemagick.org/Usage/morpho ... an_vs_blur
Which contains the nitty gritty low level explanation.

You may also like to look at the very old example at
Blurring Sharpening and Shadows, Blur vs Gaussian Blur Operators
http://www.imagemagick.org/Usage/blur/#blur_gaussian

[fmw42]

i thought you told me that -blur affected the alpha channel and that one had to reset -compose over when dealing with things after that.

[anthony]

-blur effects alpha channel only if -channel includes alpha.

-gaussian (actually -convolve) however had an error that caused to to not handle alpha in the same way -blur does. That is understand that alpha has no color if enabled. I fixed that in the old code just before copying that code for the morphology implementation.

The old code is still present as I have not switched either -blur, -gaussian, or -convolve over to using the new mophology code, though Cristy added his own 'hardware GPU' stuff. That was at the same time I was doing morphology whcih really confused things. I am not certian if he took some other recomendations, though he did find some normalization faults in his GPU convolve.