Legacy ImageMagick Discussions Archive

Hi all,

I'm having trouble combining a couple of operations, each of which involves some padding:

Command 1:

convert \( -resize '113%' -crop 512x67+604+17 mask.png \) -gravity SouthWest -extent 512x512 output1.png

Command 2:

Code: Select all

convert start.png -gravity SouthWest -extent 512x512 output1.png -compose copy_opacity -composite -channel A -threshold 50% final.png

The first command takes a slice of an image, resizes it and then pads it. This then acts as an alpha mask during the second command, which also must be padded in order to line up properly.

My attempts at combining the commands so far have not been successfull, e.g.

Code: Select all

convert start.png -gravity SouthWest -extent 512x512 \( -resize '113%' -crop 512x67+604+17 mask.png \) -compose copy_opacity -composite -channel A -threshold 50% final.png

The goal is to produce a 512x512 image that is transparent everywhere except the bottom, the input image (start.png) rests.

Images in above commands:

start.png

mask.png

final.png

Any ideas? I've spent some time reading the documentation on combining multiple commands (http://www.imagemagick.org/Usage/basics/#cmdline) and checked the forums, but have not been able to figure this one out yet.

Any help would be appreciated.

Thanks!

The goal is to produce a 512x512 image that is transparent everywhere except the bottom, the input image (start.png) rests.

If this is all you need then try (as the mask image is not important)

convert start.png -background none -gravity southwest -extent 512x512 result.png

Otherwise, you have a number of other problems. First you need to put your input image before your processing commands and use +repage after a crop and specify the background color for -extent

convert mask.png -resize '113%' -crop 512x67+604+17 +repage -gravity SouthWest -extent 512x512 output1.png

then I am not sure what you are doing with -channel A -threshold 50% at the end. Any alpha processing should likely be done on the mask image before compositing it as the alpha channel.

If the mask image is needed as you want some parts transparent and some opaque, then try this.

convert \( start.png -gravity SouthWest -extent 512x512 \) \
\( mask.png -resize 113% -crop 512x67+604+17 +repage \) \
-alpha off -compose copy_opacity -composite final.png

Hi fmw,

fmw42 wrote: If this is all you need then try (as the mask image is not important)

convert start.png -background none -gravity southwest -extent 512x512 result.png

Sorry, I should have been more clear. The masking is an important part of the procedure, even though in the example images it is barely noticeable (it results in the black border in the top-right corner of start.png being removed).

fmw42 wrote: Otherwise, you have a number of other problems. First you need to put your input image before your processing commands and use +repage after a crop and specify the background color for -extent

convert mask.png -resize '113%' -crop 512x67+604+17 +repage -gravity SouthWest -extent 512x512 output1.png

Hmm. I've never seen the -repage command before, I'll try that out.

fmw42 wrote: then I am not sure what you are doing with -channel A -threshold 50% at the end. Any alpha processing should likely be done on the mask image before compositing it as the alpha channel.
If the mask image is needed as you want some parts transparent and some opaque, then I need to understand a bit more what you are trying to do to help further.

Oops. I didn't really need to include the thresholding for the purpose of this example.

If you are interested in knowing why I have that there, the full command I'm using includes several other adjustments to the final image, one of which is a reduction in the number of colors used (-colors 256). Since the starting image is an 8-bit indexed PNG, and the only difference I wanted in the final image was to make some parts of the image completely transparent, I needed to include the color quantization command to make sure the image wasn't expanded up to a 24-bit image. This worked fine by itself in earlier version of IM (6.3.9), but when using the same command on later versions (6.5.1), the resulting color quantization created a number of semi-transparent colors that didn't need to be there. The "-channel A -threshold 50%" was a way I could force the color quantization to only select one transparent pixel.

To give you a better idea of the original problem, my ultimate goal is to select a sub-region of a binary mask image, and use that to specify which regions should be transparent in a second image. Basically I will am starting with some arbitrary rectangular slice (possibly at a higher/lower magnification) of an image of the Sun's outer atmosphere which looks something like this:

If you are interested in what it is, the data comes from the SOHO satellite: http://sohowww.nascom.nasa.gov/

Previously, the images I was working with already included their own alpha channels which made the task much simpler. In order to save space, however, we have decided to use a single static alpha mask for all images, and simply offset it as necessary.

Hopefully my post makes a little more sense now. I'm going to take a look into the repage param and see if that will help me. Thanks for your suggestion fmw!

Interesting example.

+repage (not -repage) see http://www.imagemagick.org/Usage/crop/#crop_repage

Did you try:

convert \( start.png -gravity SouthWest -extent 512x512 \) \
\( mask.png -resize 113% -crop 512x67+604+17 +repage \) \
-alpha off -compose copy_opacity -composite final.png

It seemed to work for me.

If you are interested in knowing why I have that there, the full command I'm using includes several other adjustments to the final image, one of which is a reduction in the number of colors used (-colors 256). Since the starting image is an 8-bit indexed PNG, and the only difference I wanted in the final image was to make some parts of the image completely transparent, I needed to include the color quantization command to make sure the image wasn't expanded up to a 24-bit image. This worked fine by itself in earlier version of IM (6.3.9), but when using the same command on later versions (6.5.1), the resulting color quantization created a number of semi-transparent colors that didn't need to be there. The "-channel A -threshold 50%" was a way I could force the color quantization to only select one transparent pixel.

Not sure about your color quantization, but if you want to make your result 8-bit pseudocolor with alpha, rather than 24-bits (actually 32-bits with alpha), then you can try -depth 8 -type palettematte (or -type optimize) at the end just before your final output result. And/or use PNG8:final.png for the output.

see http://www.imagemagick.org/script/comma ... s.php#type and http://www.imagemagick.org/Usage/formats/#png_formats

Thanks for all of the information.

convert \( start.png -gravity SouthWest -extent 512x512 \) \
\( mask.png -resize 113% -crop 512x67+604+17 +repage \) \
-alpha off -compose copy_opacity -composite final.png

I did try this command, and it was *almost* what I wanted, however, the result seems to apply the wrong section of the transparency mask. e.g. compare the result below with
the desired result (final.png) from my first post.

Any ideas?

Cool! I just realized what the problem was with the color quantization. Your earlier suggestion about doing alpha processing on the mask image before compositing was what tipped me off. Even though the alpha mask *was* monochrome to begin with, it seems that after cropping and resizing it, it is no longer stored internally as a monochrome image. Simply adding a "-monochrome" switch to masking portion of the command (e.g. "mask.png -monochrome -resize 113% -crop 512x67+604+17 +repage") fixed the problem.

I'm going to keep reading up on repage, and playing around with different option to try and get the masking right, but I have a couple other quick questions for you:

1. You mentioned that the input image should be specified *before* the actions being performed on it. Is that always the best way write commands? Some of the examples in the documentation for example seem to put the switches first (e.g. http://www.imagemagick.org/script/comma ... hp#extract).

2. Also, does using parentheses around an input image and a group of operations function in the same way as it does in a mathematical expression? They do seem to behave that way, and have been very useful, but I just wanted to make sure I am using them correctly.

Thanks!

1. You mentioned that the input image should be specified *before* the actions being performed on it. Is that always the best way write commands? Some of the examples in the documentation for example seem to put the switches first (e.g. http://www.imagemagick.org/script/comma ... hp#extract).

Except when reading in something like a PDF or reading in part of a JPG (or perhaps raw format), the operations usually follow the image name. The PDF and JPG situations are special. PDF needs to define its resolution when reading it in and so the resolution comes first. Reading in the size of part of a JPG helps speed up the processing. See http://www.imagemagick.org/Usage/basics/#cmdline and http://www.imagemagick.org/Usage/formats/#jpg_read. All of this has to do with read modifiers, but you are using write modifiers; that is, processing of the image to create a new image. So the operators (options) come after reading the image. Specifying all the operators before the input and output images was the old IM 5 and legacy IM 6 format.

2. Also, does using parentheses around an input image and a group of operations function in the same way as it does in a mathematical expression? They do seem to behave that way, and have been very useful, but I just wanted to make sure I am using them correctly.

The parentheses allow one to restrict the operations to only the image in question, otherwise, any operations after an image is read will be applied to all specified images. See http://www.imagemagick.org/Usage/basics/#parenthesis.

Not sure about your resulting image getting the wrong mask area. Perhaps it has to do with the subsection you specified or the use of -gravity with -extent, possibly using the wrong compass direction for the padding. See http://www.imagemagick.org/Usage/crop/#extent.

The other issue could be your not using +repage. That means that the virtual canvas is still in place and your subsection would not match what you thought you wanted to use as it would still refer to the original images 0,0 coordinates. So it may be likely that you specified the wrong subsection for using +repage after the crop. Try your separate commands again with the +repage and see if there is a difference in your result. see http://www.imagemagick.org/script/comma ... php#repage and http://www.imagemagick.org/Usage/basics/#page and http://www.imagemagick.org/Usage/crop/#crop

By the way, I would put the -monochrome at the end after the +repage as -resize will not make a binary result, but will have some grayscale at the border between black and white due to the filtering it uses as default.

Hi fmw,

Thanks for the suggestions and for answering my questions. I spent some more time reading up on the links you sent me, and am much more comfortable with the structuring of commands, etc.

I still have not had any luck unifying the two steps. I tried your suggesting of testing the initial 2-step process both with/without +repage. Although the canvas associated with the mask sub-image does indeed vary depending
on whether +repage was used:

Code: Select all

convert mask.png -resize '113%' -crop 512x67+604+17 +repage -monochrome mask1.png
convert mask.png -resize '113%' -crop 512x67+604+17 -monochrome mask2.png
identify mask1.png mask2.png 
  mask1.png PNG 512x67 512x67[color=#BF0000]+0+0[/color] 8-bit PseudoClass 2c 354b 
  mask2.png[1] PNG 512x67 1175x1175[color=#BF0000]+604+17[/color] 8-bit PseudoClass 2c 396b

...the end result of the next step (applying the alpha mask) does not seem to matter.

Here are a few more ideas I played around with, each of which was close but not exactly what I needed:

Code: Select all

// 0. Baseline: works perfect, now just need to pad image to 512x512 and have visible portion sit at bottom of image
convert start.png \( mask.png -resize '113%' -crop 512x67+604+17 +repage -monochrome \) -compose copy_opacity -composite show:

// 1. Correct masking, but final image lies at top of padding instead of bottom
convert start.png -extent 512x512 \( mask.png -resize 113% -crop 512x67+604+17 +repage -monochrome \) -alpha off -compose copy_opacity -composite show:

//2. Correct position in padding, but incorrect masking
convert start.png -gravity SouthWest -extent 512x512 \( mask.png -resize 113% -crop 512x67+604+17 +repage -monochrome \) -alpha off -compose copy_opacity -composite show:

//3. Same thing
convert start.png -gravity SouthWest -extent 512x512 \( mask.png -resize '113%' -crop 512x67+604+17 -gravity SouthWest -extent 512x512 +repage -monochrome \) -compose copy_opacity -composite show:

//3. Looks pretty good! But why is the change in offset required when using a single command?
convert start.png -gravity SouthWest -extent 512x512 \( mask.png -resize 113% -crop 512x67+604+1070 +repage -monochrome \) -alpha off -compose copy_opacity -composite show:

//4. Different approach: attempting to do padding last, however, only mask shows up at the end
convert \( start.png \( mask.png -resize '113%' -crop 512x67+604+17 +repage -monochrome \) -compose copy_opacity -composite \) -gravity South -extent 512x512 show:

So ultimately I'm still stuck doing it as two separate commands: one to select the sub-region of the mask needed and resize it accordingly, and the second to apply the mask and pad to get a final image:

Code: Select all

convert \( mask.png -resize '113%' -crop 512x67+604+17 +repage -monochrome  \) -gravity SouthWest -extent 512x512 -background black output1.png
convert start.png -gravity SouthWest -extent 512x512 -background black output1.png -alpha off -compose copy_opacity -composite final.png

For now simply generating the required mask sub-region (output1.png) and then removing the file once the final processing has been done is probably sufficient. Any other suggestions of course would be appreciated

try this, i think it does it:

convert \( start.png -gravity SouthWest -background black -extent 512x512 \) \
\( mask.png -resize 113% -crop 512x67+604+17 +repage -monochrome -background black -extent 512x512 \) \
-alpha off -compose copy_opacity -composite final.png

Hmm. still no luck. Result is same as a couple posts above.

Sorry I keep confusing the direction of the diagonal cut. Try this. I forgot the -gravity southwest in the mask and added -respect-parethesis (same as -respect-parentheses). The latter is the key. It seems that -gravity is getting confused in some way in the mask.png processing. see http://www.imagemagick.org/script/comma ... arentheses and http://www.imagemagick.org/Usage/basics/#controls . Usually -respect-parenthesis is not needed, but does at times when gravity, geometry and/or compose settings are used in multiple parens (in my experience).

convert -respect-parenthesis \( start.png -gravity SouthWest -background black -extent 512x512 \) \
\( mask.png -resize 113% -crop 512x67+604+17 +repage \
-monochrome -gravity SouthWest -background black -extent 512x512 \) \
-alpha off -compose copy_opacity -composite final.png

This also works by turning off the -gravity from start.png parens from affecting the mask.png parens by adding +gravity

convert \( start.png -gravity SouthWest -background black -extent 512x512 \) \
\( mask.png +gravity -resize 113% -crop 512x67+604+17 +repage \
-monochrome -gravity SouthWest -background black -extent 512x512 \) \
-alpha off -compose copy_opacity -composite final.png

or

convert \( start.png -gravity SouthWest -background black -extent 512x512 \) +gravity \
\( mask.png -resize 113% -crop 512x67+604+17 +repage \
-monochrome -gravity SouthWest -background black -extent 512x512 \) \
-alpha off -compose copy_opacity -composite final.png

Perfect!

It's funny: I had read about the -respect-parentheses switch, but at the time I didn't think it was what I needed. I never even though of using "+gravity"!

Thanks a lot for all of your help fmw. This is just what I was looking for

Best,

Legacy ImageMagick Discussions Archive

Question about combining two operations involving padding

Question about combining two operations involving padding

Re: Question about combining two operations involving padding

Re: Question about combining two operations involving padding

Re: Question about combining two operations involving padding

Re: Question about combining two operations involving padding

Re: Question about combining two operations involving padding

Re: Question about combining two operations involving padding

Re: Question about combining two operations involving padding

Re: Question about combining two operations involving padding

Re: Question about combining two operations involving padding

Re: Question about combining two operations involving padding