separate modifies channel values!

[anthony]

Looks like -separate is modifying channel values (gamma values) when they shouldn't make any changes at all,
just seperate as grayscale images without any change to the channel values.

These two command should produce different outputs (in linear-gray colorspace)

Code: Select all

convert rose: -colorspace RGB -separate +append show:
convert rose: -colorspace sRGB -separate +append show:

but, they produce exactly the same output!!!

Stranger still I get different results using the IMv7 "magick" command.

Code: Select all

magick rose: -colorspace RGB -separate +append show:
magick rose: -colorspace sRGB -separate +append show:

Again these two images should be different but aren't!
But they are different to IMv6 "convert", and that should not happen either.

[snibgo]

Code: Select all

convert rose: -colorspace RGB -separate +append show:
convert rose: -colorspace sRGB -separate +append show:

If I understand correctly, the images from "-separate" are greyscale, so IM applies the usual rule of converting them (if necessary) to RGB.

"rose:" is sRGB. The first command converts it to RGB, then separates the channels. As the channels are already RGB, "-separate" does no conversion.

In the second command "-colorspace sRGB" does nothing because the image is already sRGB. "-separate" separates the channels and converts each one to RGB.

Thus, the results are the same, as I would expect. This has been the behaviour since before v6.7.9.

[fmw42]

convert rose: -colorspace RGB -separate +append show:
convert rose: -colorspace sRGB -separate +append show:

My understanding is that they should be the same as snibgo says.

-separate converts each sRGB channel to linear grayscale.

The first command uses -colorspace RGB to convert each channel to linear grayscale (gamma = 1). Then -separate sees that they are already linear and so does not further conversion except to separate the channels.

In the second command, -colorspace sRGB does nothing as snibgo says, since rose: is already sRGB. Thus -separate applies the same linear transform as -colorspace RGB since it sees the image is not linear (gamma != 1) and then separates the channels.

This is not the case for

convert rose: -set colorspace RGB -separate +append show:
convert rose: -set colorspace sRGB -separate +append show:

The first one will be lighter as no conversion by -separate is done other than setting the gamma=1. The pixels are not converted. The second one will be darker because -separate sees the gamma !=1 and converts the pixels so that gamma = 1.

[anthony]

Code: Select all

convert rose: -colorspace RGB -separate +append show:
convert rose: -colorspace sRGB -separate +append show:

If I understand correctly, the images from "-separate" are greyscale, so IM applies the usual rule of converting them (if necessary) to RGB.

"rose:" is sRGB. The first command converts it to RGB, then separates the channels. As the channels are already RGB, "-separate" does no conversion.

Yes to grayscale... No to conversion... The purpose of -seperate is to seperate the channels as seperate images, NOT convert the values.

If the image is sRGB, the grayscale images will be sRGB values even though the grayscale itself is meant to be 'linear-gray'.

The same goes with the reverse -combine. It merges the channel values without any changes to those values (the colorspace to set for the resulting image is a different matter).

-separate converts each sRGB channel to linear grayscale.

YES it should convert each channel to linear-greyscale, but without any change to the input channel values. The resulting greyscale images may be regarded as linear-gray, but really it is just a greyscale image storing sRGB channel values, and the colorspace is not a consideration. The values should remain unchanged, not get distorted just because the colorspace is not linear.

Take seperating a Lab colorspace image.. -separate should get geryscale images of L, A, and B channels as is... the L channel should not be converted to a linear Intensity, it should remain a unadulterated Luma channel. The same should be for sRGB images
the values should remain, unchanged.


The actual working problem is an attempt to resize in a special DIY colorspace (LAB with a linear intensity instead of 'L') I am having major problems with channel extractions.
viewtopic.php?f=22&t=21415&start=120#p97214

[fmw42]

If the image is sRGB, the grayscale images will be sRGB values even though the grayscale itself is meant to be 'linear-gray'.

As far as I know, it has not been that way since grayscale was converted to linear. The process of separating channels means grayscale images and are thus gamma corrected to linear. In all my scripts since about 6.7.8.3, I have had to use -set colorspace RGB (also when converting to other colorspaces) before separating channels to preserve non-linear grayscale for the channels when doing -separate.

[anthony]

and that is the point ... You should not be needing to.

In your email to me you have

Code: Select all

convert lena.jpg -colorspace HSL -separate lena_hsl_%d.png
convert lena.jpg -colorspace YUV -separate lena_yuv_%d.png
convert lena.jpg -colorspace HCL -separate lena_hcl_%d.png

Would you want the greyscale images to be different to actual channel values!!!! No of course not. You want the values as is, so you can compare them.

I just reporting that this is NOT what is happeneing for sRGB images.

AND we get a different result in IMv7 to what was happening in IMv6. In IMv7 the two images (sRGB and RGB separations) are still the same but they are 'lighter' versions. It is still wrong, but wrong in the opposite sense.

[magick]

We can reproduce the problem you posted and have a patch in ImageMagick 6.8.5-0 Beta available by sometime tomorrow. Thanks.

[anthony]

Great,, yes it is fixed for IMv6

And fixed in IMv7 too... great

[shadowhand]

I believe this has resulted in a regression. It used to be that this command would return "0" for any image without an alpha channel, but now results in "1" for images without an alpha channel:

Code: Select all

// expected to return a value between 0.1 and 1
convert rgb-alpha.png -channel a -separate -format "%[fx:maxima]" info:
// expected to return a value of 0
convert rgb-no-alpha.png -channel a -separate -format "%[fx:maxima]" info:

Before version 6.8.5 this worked as expected, but now the second command returns "1" for images without alpha channels.

[snibgo]

Images without alpha channels are fully opaque. alpha=1 represents fully opaque. I would hope the result from a file without alpha is 1.

Code: Select all

convert xc:black b.png
convert" b.png -channel a -separate -format "%[fx:maximal]" info:

This returns 1 for a variety of IM versions, including 6.8.5-0 and 6.8.6-10. It seems good to me.

[shadowhand]

As it turns out, there is an easy work around. The value of

Code: Select all

%[fx:minima]

can be compared to maxima. If the value of maxima is not 1, or the values are not equal, the image must have variation in the alpha channel.

[shadowhand]

Actually that doesn't seem to be correct either, because minima still returns 0 for an image with no alpha channel:

Code: Select all

// this should output: 1 1
// but instead it outputs: 0 1
convert rgb-no-alpha.png -channel a -separate -format '%[fx:minima] %[fx:maxima]' info:
// this should output: 0 1
convert rgb-alpha.png -channel a -separate -format '%[fx:minima] %[fx:maxima]' info:

But this behavior appears to be different between 6.8.6-3 and 6.8.6-9, with the latter (more recent) version exhibiting the incorrect result.

EDIT: here are my test files: http://sta.sh/2gmji5z9dw4.

[snibgo]

There seems to be at least one weird bug. Using the "no-alpha" file provided by shadowhand, which "identify -vebose" confirms contains no alpha channel:

D:\web\im>"%IMG68610%convert" rgb_no_alpha.png -channel a -separate -format "%[fx:minima] %[fx:maximal]" info:
1 1

D:\web\im>"%IMG68610%convert" rgb_no_alpha.png -channel a -separate -format "%[fx:minima]" info:
0.999893

D:\web\im>"%IMG68610%convert" rgb_no_alpha.png -channel a -separate -format "%[fx:maximal]" info:
1

[shadowhand]

D:\web\im>"%IMG68610%convert" rgb_no_alpha.png -channel a -separate -format "%[fx:minima]" info:
0.999893

On Mac with IM v6.8.6-3 I get a result of "1", not your less-than-1 float:

Code: Select all

% convert rgb-no-alpha.png -channel a -separate -format "%[fx:minima]" info:                                                                                                   
1

But on Linux (Debian) with v6.8.6-9 I get a different result:

Code: Select all

# convert rgb-no-alpha.png -channel a -separate -format "%[fx:minima]" info:
0

[fmw42]

On my Mac OSX IM 6.8.6.10 Q16 it works fine. But try adding +channel after the -separate and see if that makes a difference


convert rgb_no_alpha.png -channel a -separate -format "%[fx:minima]\n" info:
1
convert rgb_no_alpha.png -channel a -separate +channel -format "%[fx:minima]\n" info:
1