possible bug in -fx and alpha component IM 6.6.6.3

[fmw42]

IM 6.6.6.3 Q16 (hdri) Mac OSX Tiger.

This seems like a bug to me, but perhaps I misunderstand how -fx handles the alpha channel.


convert -size 1x1 xc:"rgb(0,0,128,0.5)" -channel rgba -alpha on -format "%[fx:1-u.a]" info:
0


Seems to me that I should get 0.5.

Also both of these seems give the same result of 1.


convert -size 1x1 xc:"rgb(0,0,128,0)" -channel rgba -alpha on -format "%[fx:u.a]" info:
1
convert -size 1x1 xc:"rgb(0,0,128,1)" -channel rgba -alpha on -format "%[fx:u.a]" info:
1

Am I misunderstanding how -fx uses the alpha channel?

[magick]

N'est-ce pas?

• convert -size 1x1 xc:"rgba(0,0,128,0.5)" -channel rgba -alpha on -format "%[fx:1-u.a]" info:
  0.5

[fmw42]

Doh! I accidentally forgot to add the "a" to the end of rgba and use rgb. (I keep doing that - Ugh!)

Thanks for catching that for me. Sorry for the false alarm.


Curious! Why does IM need the a at the end of rgba, if it sees 4 components, should it not know that there is alpha in something that says rgb(...)?

[magick]

We follow the SVG standard as best we can which requires that RGB have 3 values. Use rgba() to specify the alpha component. Its part of the CSS standard. Some browsers support it in SVG (such as Firefox). ImageMagick introduced cmyk() for CMYK and cmyka() for CMYK with alpha.

[fmw42]

Thanks for the explanation. I understand your desire to follow some standard or convention. I just have to keep trying to remember to add the "a" to the end of rgb when I add the alpha value in the parens.

[anthony]

Code: Select all

convert -size 1x1 xc:"rgb(0,0,128,0.5)" -channel rgba -alpha on -format "%[fx:1-u.a]" info:

As a FYI -channel RGBA with -FX specifies what channels onf the image should be processed.

However for %[fx:...] it has no meaning as the expression is only executed once per image in memory only. channel is fixed to R (red), unless you specifically specify a specific channel value.
Simularly the pixel location i,j is also fixed to 0,0.

Also remember 'u' is first image v, is second image, and 's' is the CURRENT image being processed.



Current Pet peeve....

However 't' is the current "scene number of current image in sequence", that is the image index number for the 's' image.

convert rose: rose: rose: -format "%[fx:t]" info:
0
1
2

Unfortunatally that does not work with image meta-data assignments! Arrggghhhh

convert rose: rose: rose: -set mylabel "%[fx:t]" -format "%[mylabel]" info:
0
0
0

The cause is the way "convert" currently handles "mogrify" or single image type operations. At this time it separates each image into a single image sequence, then processes it as a individual image.

In the first example "info:" is the operator (a assumed -write operation) with is a image sequence operator, so when -format is applied it knows what the image index is. But -set is not an image sequence operator, so it sees each image as a completely separate image, and thus all has a image index of 0.

This is also why you can not use 'v' in a %[fx:...] in a set operation! There is no second image!

BUT if we try to fix this mogrify will not be able to use -set, and that change is definitely not desirable.