How do I get the color including alpha value at a pixel?

[fmw42]

In IM 6.4.1-6 Q16 HDRI, I tried:

convert rose: -channel RGBA -matte rose_alpha.png
convert rose_alpha.png -verbose info:
convert rose_alpha.png -format "%[pixel:u.p{0,0}]" info:


The verbose info shows:

Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
alpha: 1-bit
Channel statistics:
red:
min: 35 (0.137255)
max: 255 (1)
mean: 145.712 (0.57142)
standard deviation: 69.2953 (0.271746)
green:
min: 22 (0.0862745)
max: 255 (1)
mean: 89.2602 (0.35004)
standard deviation: 52.4698 (0.205764)
blue:
min: 24 (0.0941176)
max: 255 (1)
mean: 80.4683 (0.315562)
standard deviation: 55.1114 (0.216123)
alpha:
min: 0 (0)
max: 0 (0)
mean: 0 (0)
standard deviation: -0 (-0)

So there is clearly an alpha channel with value 0.

But when I do the last step above:

convert rose_alpha.png -format "%[pixel:u.p{0,0}]" info:

I get back only rgb(48,47,45)

Should this be reporting the alpha channel value? If so, then a bug. If not, then is there another way?

I also tried:

convert rose_alpha.png -fx "i==0&&j==0?debug(u):0" null:
rose_alpha.png[0,0].red: u=0.188235
rose_alpha.png[0,0].red: u=0.188235
rose_alpha.png[0,0].red: u=0.188235
rose_alpha.png[0,0].green: u=0.184314
rose_alpha.png[0,0].blue: u=0.176471


This did not report the alpha either.

Also why is the red channel repeated 3 times?


But, when I do

convert rose_alpha.png -fx "i==0&&j==1?debug(u):0" null:
rose_alpha.png[1,0].red: u=0.184314
rose_alpha.png[1,0].green: u=0.180392
rose_alpha.png[1,0].blue: u=0.172549

I only get the red channel reported once!

Why the difference between pixel 0,0 and pixel 0,1?

Note also that the x,y values are reported as y,x here? Is this intentional?



OK. I have made some progress, but am still puzzled.

If I add an alpha channel to the rose image such that it is opaque, then this works:

convert rose_alpha.png -format "%[fx:u.p{0,0}.r],%{0,0}.g],%[fx:u.p{0,0}.b],%[fx:u.p{0,0}.a]" info:
0.188235, 0.184314, 0.176471, 1 (I added spaces here to emphasize 4 values)

But if the alpha channel makes the image transparent, then the rgb values are masked and the same command

convert rose_alpha2.png -format "%[fx:u.p{0,0}.r],%[fx:u.p{0,0}.g],%[fx:u.p{0,0}.b],%[fx:u.p{0,0}.a]" info:
0,0,0,0

returns zero for all rgb values even though as above they are not zero.

Please clarify this for me.

Is there some way to see the actual color values independent of the alpha channel and get the alpha channel value at the same time, that is without having to strip off the alpha channel?

Thanks

Fred

[anthony]

You are not getting a alpha color because it is opaque, and thus not important.

Also -fx did not report it as you did not process the alpha channel

Code: Select all

  convert rose_alpha.png -channel RGBA -fx "i==0&&j==0?debug(u):0" null:

ROSE[0,0].red: u=0.188235
ROSE[0,0].red: u=0.188235
ROSE[0,0].red: u=0.188235
ROSE[0,0].red: u=0.188235
ROSE[0,0].green: u=0.184314
ROSE[0,0].blue: u=0.176471
ROSE[0,0].opacity: u=1

I have no idea WHY you get 3 extra red output lines. but you only get them when i==0 and j==0. Looks a little like a minor bug to me.

The simpliest way however is using txt:- output

Code: Select all

convert rose: -matte -crop 1x1+1+1 txt:-

# ImageMagick pixel enumeration: 1,1,255,rgba
0,0: ( 48, 47, 45, 0) #302F2D rgb(48,47,45)

Note that the color comments also automatically do not report the matte channel as the color is fully-opaque. However as the image has an alpha/matte channel you will get the four image values. The output is also 8 bit depth as that is what the input image (internally) used. Add -depth 16 to force 16 bit depth values. depth is in the output file on the header line, along with the colorspace of the image.

PS: I recently reported a bug for the color comments for CMYK images...

Code: Select all

convert xc:blue xc:white -colorspace CMYK txt:-

# ImageMagick pixel enumeration: 1,1,65535,cmyk
0,0: (65535,65535, 0, 0) #FFFFFFFF00000000 yellow
0,0: ( 0, 0, 0, 0) #0000000000000000 black

The color comments are correct in the values were in RGB space, but are incorrect in the above (CMYK space). - REPORTED BUG
Also as two images are involved a second image 'header' should have been output to define the start of the second image. - REPORTED BUG
IM currently can not read concatenated 'TXT' format images. It sees only the first header and assumes all the following lines are for just the one image, even if multiple headers are give to define multiple images. - BUG NOT YET REPORTED