Legacy ImageMagick Discussions Archive

Hey dear supporters,

first of all: thanks a lot for this great software and for your restless assistace. It gives nearly limitless graphical programming options to the world.

My version: ImageMagick 6.6.1-5 2010-05-01 Q16
But I'm developing a software based on ImageMagick so I can't really be shure about the version used.

I'm trying to multiply an overlay with shadow information into a background image containing an alpha channel.

first attempt:convert overlay_garbage.png overlay_lighting.png -compose Multiply -composite overlay_result.png

The result in Imagemagick seems to remove alpha information of the background and replaces it with image information of the overlay.

I tried a lot with alpha information, the best result was with inserting alpha information later again but the result isn't usable in this case.

second attempt: convert \( overlay_garbage.png overlay_lighting.png -compose Multiply -composite \) overlay_garbage.png -compose DstIn -composite overlay_result.png

The result of this attempt "washes out" the pixels with less opacity and white overlay because of the color information added in the first step (better seen on another black layer)

I know how boring it feels to get compared to other software but just as an example what I want to achieve please have a look at what Gimp is doing while simply multiplying the overlay on the background with alpha information. When I add a third layer underneath the background I get the output I'm looking for. (The third layer is just for imagination and not part of the overall rendering process)

So it seems I don't understand the behaviour of alpha channels in ImageMagick at all :/ I would really appreciate some hints that head me in the right direction.

Thanks a lot in advance, cheers, markus.

Your 2overlay_lighting.png has a perfectly opaque alpha channel so it is of no use. Just extract the alpha channel from the first image, multiply the two, then add the alpha channel of the first image back to the product.


convert overlay_garbage.png overlay_lighting.png \
\( -clone 0 -alpha extract \) \
\( -clone 0 -clone 1 -compose multiply -composite \) \
-delete 0,1 +swap -alpha off -compose copy_opacity -composite overlay_result.png

With the later versions of IM you can use a -channel A to get composition to multiply alpha.
Without setting the channel value IM will do a SVG defined multiple which multiplies color channels, but with 'over' alpha blending.

For details (which uses multiply as an example, see..
Image Channel Mathematics using Image Composition
http://www.imagemagick.org/Usage/compose/#image_math

Anthony,

The first thing I tried was

convert overlay_garbage.png overlay_lighting.png -channel rgba -alpha on -compose Multiply -composite overlay_result.png

and it did not work as expected.

IM 6.7.3.1 Q16 Mac OSX Tiger

Hmmm... I do not understand the 'gimp' image result that was originally given as it does not seem to have any alpha in it!

Okay... You have one image overlay_garbage.png which appears black with alpha
You have another image overlay_lighting.png which looks like it is a greyscale mask.

The two types of image are not compatible! Either you need to convert both images to a grayscale masks and multipy (as fred suggested) or convert the grayscale mask to a shaped image (alpha mask), at which point you can multiply just the alpha channels (the mask has no color component)

Try this (preserves color components of the destination (first image) as it only multiply alpha channels An alternative is to use a Duff porter compostion alpha blend method. like this
That is any part of the destination that is 'IN' the shape forms by the second image. The latter may be easier to understand, and I think may be equivalent to just a alpha channel multiply.

Actually yes they are equivalent, except that full-transparent pixels are set to fully-transparent black in the duff-porter image, where the direct multiply leaves them alone. This is being caused by a quirk of the mathematics that is being applied. Visually there is no difference in the two methods.

You learn something new every day!

Hey!

Thank you very very much for trying to help me out of my misery. And sorry for my late reply - I'm the idiot who forgot to check the box "Notify me when a reply is posted". (addendum: if you give up while facing this f**ing huge amount of text I can understand that.)

Unfortunately none of your suggested solutions is fixing this problem :/

The idea fmw42 has posted is really close to my second attempt - the slightly blended pixels receive the color of the overlay_lighting. Result is: if I compose this result onto a new black layer, all of the tiny elements get kind of a light halo around them like in this image. Anthony brought in some good points but unfortunately they are missing the final result, too - although the link into the manual (and the section above the link targe hg update -C -r 3
hg update -C -r 3
hg update -C -r 3
hg update -C -r 3
t) really helped me in my dragging understanding. If I got you totally wrong please bear with me since english is not my mothertongue at all.

So I try to explain the problem a little more accurate.

I have a picture of the earth that looks like this one. It is generated by xplanet and imagemagick, so the lighting of the sun is dynamicaly altered over the day or depending on the settings of a user.

Then I have this overlay image I want to compose on top of the rendered earth. For this particular template the overlay consists of about 100.000 tiny sattelites rendered with blender and masked with gimp. The sattelites are coloured, not simply black and white. The layer has a grayscaled alpha channel so the hg update -C -r 3
hg update -C -r 3
outer pixels of the sattelites are partly transparent to blend nicely with the earth layer.

Composing this sattelite- or garbage layer with the earth layer works fine but looks ugly because of the missing lighting. They stand out to much on the shadow- or night area of the earth.

To get a at least partly realistic impression I have to darken the sattelites on the side the sun doesn't reach, so I render another image with xplanet that just contains the lighting of the earth (white on black) and blur it with imagemagick to get the lighting information for the garbage layer.

And this is the point where my problem hits.

I need to darken the garbage without loosing alpha information and without changing any other colour channel in the garbage layer than in the parts that have to be darkened. Every other attempt with multiplying the lighting layer with the garbage layer changes the borders of the sattelites. This is mostly invisible until you render the result on top of the earth (or a simple black test layer). Then the sattelites don't blend with the water or the clouds because of the little halo around. Compare this image (imagemagick) with this one (gimp). The first result has the halo effect while the result in gimp is exactly what I need. Here are both versions without the black layer underneath: [url=http://mein-neues-blog.de/files/xplanet ... verlay_res hg update -C -r 3
hg update -C -r 3
ult.png]imagemagick[/url] and gimp.

I did exactly the same in gimp: opening the sattelites, opening the lighting layer as a new one above the sattelites, set it to multiply - export. Then I added a black layer underneath - like I did in imagemagick to make the result visible. hg update -C -r 3


If imagemagick does these thing completely different from gimp I just had an idea for a workaround: using the lighting image as alpha cannel of a completely black layer and use this one to multiply it with the sattelites - that should prevent the sattelites in the lit area from receiving white colour in the partly transparent pixels since there isn't any white colour in the lighting layer anymore. Do I get that right?
hg update -C -r 3

This was just the first step in doing this template - I don't know if I have to lighten up the garbage in the lit area or how much I have to dull te shadowed ones down, I was stuck directly after having the rendering of sattelites done.

Wow what an aria. So thank you very much for even reading this stuff. But be sure that I'll mention your patience and help particularly to the users of xplanetFX and especially to the two guys who had this bloody template request.

Cheers, markus.

(Notify me when a reply is posted - check.)

Okay now I understand, something that was not very clear in the original request. (I did not follow your 'on black' examples at all).

All you really want to multiply color, and leave alpha alone!

Test image (black background)... That looks like your gimp version. Now to save while reserving he background use. The second -compose is important for the first 'test' result, other wise -flatten also uses 'multiply compose'.

In the second compose is reset as for some reason IM saves the last 'compose' setting applied to images in some image file formats, causing havoc when you use the image! This last I consider a bug! (something I am looking into making more useful in IMv7)

NOTE: all those really black (night time) satellites will likely make the nigth-time earth lights very dim!

Hey Anthony,

thanks a lot again for staying tuned in this issue!

After continuing reading your example pages and manuals I think I can break the problem down to the version I'm actually using:
And your manual states the following:

As of IM v6.6.1-6 the ability to use the mathematical operator on alpha channels was added to all the Mathematical Compose Methods[...]

Here are the results of your examples from your last post with the version I'm actually using: first and second.

As I said in my first post - this script will be run on different systems I have not that much influence on the installed versions to so I have to try to keep the requirements as low as possible. My test system is an Ubuntu LTS 10.04 which is quite commonly used by the users of xplanetFX - and on this one the default imagemagick is the one I stated above :/

So I tested a lot again today and finally came out with this solution:
... which gives me this result I am quite happy with. (I modified the garbage layer with gimp and raised the gamma a bit)

I think we all invested more than enough time and brain into this particular rendering step of this single template to declare it as done. Next step is to think about a solution how to tell the moon whether he is in front or behind this garbage layer - or to simply switch it off in this template.

So thank you very much for your struggle and your know-how which was a great help in breaking down the problems and which gave me lots of insights in the processing of ImageMagick! I will state a really favorable mention on your efforts and selfless support together with the release of this template (hopefully in a few days).

Cheers, markus.

Really: thanks a lot guys!

boomshop wrote:And your manual states the following:

As of IM v6.6.1-6 the ability to use the mathematical operator on alpha channels was added to all the Mathematical Compose Methods[...]

As I said in my first post - this script will be run on different systems I have not that much influence on the installed versions to so I have to try to keep the requirements as low as possible.

Okay. try this This uses the duff-porter 'src-in' composition to restore the alpha channel. That is get the colors from the second image (produce by the parenthesis) but get the alpha from the first image.
The -alpha off is vital to prevent the SVN defined alpha blending (just multiple color channels).

If your IM is old than the addition of -alpha replace -alpha off with +matte With that change it should work for any IM later than v6.1
(around year 2005).

Wow! That's exactly the result I was looking for. Anthony - thanks a very lot for your investigation and your support in this problem! This particular procedure will be the base for all the next render steps like brightening up garbage on top of the specular sun spot and the like. And the icing on the cake truly is the downward compatibility - awesome. Really learned a lot about the internals of ImageMagick now.

Thank you very much indeed, cheers, markus.