Legacy ImageMagick Discussions Archive

I'm trying some commands from here: http://www.fmwconcepts.com/imagemagick/ ... .php#alpha
and they don't seem to work as per Fred's examples. Is Fred wrong or is ImageMagick broken?
Version: ImageMagick 6.6.7-10 2011-03-01 Q16 http://www.imagemagick.org on Slackware 13.0 x86_64
Test If Image Has Alpha Channel
Fred's "Method 1" gives the same results here, but "Method 2" doesn't.
e.g. Fred's "Method 2" example:
convert -size 100x100 xc:white white.png
convert white.png -format "%A" info:
False
convert white.png -alpha on white_alpha.png
convert white_alpha.png -format "%A" info:
True
But I get:
convert -size 100x100 xc:white white.png
convert white.png -format "%A" info:
False
convert white.png -alpha on white_alpha.png
convert white_alpha.png -format "%A" info:
False

Measure The Average Opacity Or Transparency Of An Image
Fred says:
Set 60% Opacity (40% Transparency)
convert logo.jpg -alpha on -channel o -evaluate set 60% logo_opacity60.png
convert logo_opacity60.png -format "%[fx:u.o]" info:
returns opacity of 0.6
convert logo_opacity60.png -format "%[fx:u.a]" info:
returns alpha/transparency of 0.4
But I get:
convert logo_opacity60.png -format "%[fx:u.o]" info:
0.4
convert logo_opacity60.png -format "%[fx:u.a]" info:
0.6

Cheers,
Peter

geep999 wrote:Test If Image Has Alpha Channel
Fred's "Method 1" gives the same results here, but "Method 2" doesn't.
e.g. Fred's "Method 2" example:
convert -size 100x100 xc:white white.png
convert white.png -format "%A" info:
False
convert white.png -alpha on white_alpha.png
convert white_alpha.png -format "%A" info:
True
But I get:
convert -size 100x100 xc:white white.png
convert white.png -format "%A" info:
False
convert white.png -alpha on white_alpha.png
convert white_alpha.png -format "%A" info:
False

I'm using the latest SVN version 6.6.8-6
I also get False False

However this may be due to a recent optimization for PNG file format (to make it smaller)
The image after all does not actually have any transparency, so really does not need a alpha channel.

However saving to png32:white_alpha.png should have forced PNG coder to save a alpha.
But I still get False.

Measure The Average Opacity Or Transparency Of An Image
Fred says:
Set 60% Opacity (40% Transparency)
convert logo.jpg -alpha on -channel o -evaluate set 60% logo_opacity60.png
convert logo_opacity60.png -format "%[fx:u.o]" info:
returns opacity of 0.6
convert logo_opacity60.png -format "%[fx:u.a]" info:
returns alpha/transparency of 0.4
But I get:
convert logo_opacity60.png -format "%[fx:u.o]" info:
0.4
convert logo_opacity60.png -format "%[fx:u.a]" info:
0.6

I get the same as You, which is the correct result.

But then Fred probably wrote that in the early days of evaluate when it had not be set to work with alpha values. Initially (like -level, and -threshold) it worked with the value actually stored internally with images, 'matte' or 'opacity' values.



There is nothing more constant, as change. And things do change, generally for the better, especially in a operators earily days. The -evaluate operator is one of them. PNG is still being worked on to allow the coder to generate better optimized images, specifically indexed PNG when warranted.

Another recent change was to make sparse-color to preserve channels values it is not modifying, so you can now use it to add alpha gradients to image without disturbing existing colors.
http://www.imagemagick.org/Usage/canvas/#sparse_channel

Similarly a couple of months ago Mathematical Compose methods, can now modify individual channels, where previously it ignored the -channel setting and only did composition as defined by SVN with all channels and blending.
(which is still its default)
http://www.imagemagick.org/Usage/compose/#image_math

And only two days ago I submitted updates that make %p, %n %[fx:t] and %[fx:n] work correctly outside "identify" and "info:" output. This means the actual current Image index is now available to things like, -annotate, -set, -distort, and -sparse-colors. Up until this point it only returned useless values of either 0 or 1
This means I can do things like... Animated Distorts!
http://www.imagemagick.org/Usage/anim_mods/#distort
And that is only the beginning of what that change now allows us to do.

Some changes I like to see made (perhaps by me) that is less backward compatible is...

• For -level work with alpha values instead of matte values
• And make -blur and -gaussian automatically handle color transparency BY DEFAULT, and only do separate channel blurring if the -channel setting was set. This by the way is how the -morphology convolution blurs work.

It is only backward compatibility concerns with these very old operators that is preventing me proceeding, so they are changes that may have to wait for a 'MAJOR' version update

Thanks for confirming it's not just me.
And for the pointers to the new features - I'll read up on the. It certainly keeps the little grey cells active.
Cheers,
Peter

see bug reports that I recently filed in response to these issues:

viewtopic.php?f=3&t=18350
and
viewtopic.php?f=3&t=18349

I have updated some of these issues in my Tidbits page.

From tidbits page...

-channel o and -channel a mean the same thing. Originally they both referred to opacity.

These have always meant the same thing even in IM v5 and before that!
Basically apply/limit channel operation to transparency channel.

It is up to individual operators how it looks at teh transparency channel.

Internally transparency is stored as matte, bascially as clearing image data would then generate a 'black' background regardless of it transparency is on or not. This has been a mistake, and one that IM is still paying for in constantly having to convert between matte and alpha values.

Because of this internal storage, almost all operators always looked at transparency as matte values, from color input, to channel extraction.

With IM v6, Composition and other 'Convolution' type operators (including resize and blur' started having to deal with transparency as alpha, simply because either that was how the rest of the world handled transparency (mathematically), or to prevent 'halo' effects coming from the color that transparent pixels contained.

With that start new operators typically handle transparency as alpha, as that is the expectation.

However some VERY OLD operators like -separate, -level, -threshold, still deal with transparency channels as matte values. These are hold out, and left unchanged due to backward compatibility issues.

The idea solution would be a re-write of ImageMagick and just about all operators, so transparency is stored and handled purely as alpha, as is the general expectation of the world. However this would be a major effort, prone to lots of mistakes, as each MagickCore function, module, and coder is checked and modified appropriately. Such as change would have to be classed as a move to IM v7, and released as 'alpha' and 'beta', while preserving IMv6 as a separate development tree in the mean time.