Legacy ImageMagick Discussions Archive

I wanted to use convert as a CMYK colour separator, exploiting the LCMS engine.

But (a few trials later) I find that even trivial RGB separation is not behaving according to my understanding
of the documentation.

I'm working from here:

http://www.imagemagick.org/Usage/color_basics/#separate

Even the most basic command don't work as expected.
(I added the identify to see what was going on, and to eliminate the possibility that the tiff writing was having side effects).

It appears that -separate is NOT generating "the current contents of each channel as a gray-scale image".

ETA: BugBear

You are selecting one channel, with "-channel R". If you want all channels, don't select just one. should create a tiff file with three greyscale images, representing the R, G and B channels of rose.

snibgo wrote:You are selecting one channel, with "-channel R".

That was my intent. I want a single (separated) channel. And I wanted it grayscale
(single byte samples).

But the result, as per -identify, and/or opening the output in GIMP is (still) RGB,
albeit RGB that "looks like" a single separated channel.

BugBear

So your output has three channels, but they are equal at each pixel?

For me, the output has a single channel. This is for both v6.7.9 and v6.8.5. However, these versions give slightly different results because of how IM treated greyscale files between those versions.

I suspect the v6.8.5 gives the same result as your rather old 6.7.7 (but with only one channel in the output).

IM 6 does not allow single channel grayscale. It will produce a grayscale image with all 3 channels the same. IM 7 will be the first version of IM to allow true single channel images.

As fmw42 says, internally there is no single channel grayscale in IM. You will have three equal channels. I found this very confusing; the grayscale gamma issue mentioned by snibgo too. But you should be able to get a grayscale output file. Like snibgo, I do (checking with IM, Windows, and GIMP). I am on Windows, and I believe snibgo is too.

depending upon the version of IM you may need to add -set colorspace RGB to get a grayscale image that is as one might expect. From IM 6.7.8.3 until recently 6.8.4.x (not sure of the last minor version) you would need to add that, so you do not get a darker result than expected.

convert image -set colorspace RGB -channel R -separate +channel result

The problem is greyscale has no linear or non-linear aspect associated with it.

IM has recently gone though a number of stages of 'how to do this' as such it is highly version dependant. However the latest version should have the handling for this sorted out (both in -separate actions, and in image saving). So when saving, some versions of IM saved it as non-linear sRGB, others flagged it simply as linear data. The latter is correct behaviour, as a grayscale image is just data, without a true colorspace, until otherwise specified depending on what it will be used for (and that could be quite a large number of things).

-separate is meat to extract the channel values from an image, as such extracting red generates a grayscale image. The fact that this grayscale image was extracted from a non-linear colorspace is lost, or exactly what colorspace it was from (which may not be sRGB).

Grayscale data could for example be values from Luma, Luminence, Brilance, Hue, or A*, B*, U*, V*, or alpha image channel data. It could be image map data, such as a mask, lookup tables for color, distortions, displacement, or even 'which image', image segmentation, object identification, and probably may other things. It is something the user needs to track and define when he finnaly decides to use that data. There is just too many possibilities to 'track' or even determine.

So how do you want that data saved?

You can save it as a linear grayscale image (IM will assume it is linear data), or tell IM this grayscale image is really a non-linear sRGB grayscale image using -set colorspace sRGB, in which case you have defined the data is non-linear sRGB data for display.

The latter is correct for viewing purposes. For just preserving that raw data, the former is more correct, but either can be used, the data in the save file should remain the same in either case.

If you set it as being linear RGB rather than leaving it as grayscale, or setting it as sRGB, then IM will generally convert that colorspace to sRGB, as most image file formats (not MIFF) only handles sRGB. (ASIDE; JPEG actually saves as a YUV colorspace internally, and uses a profile to determine output colorspace, or sRGB is not present)

Note while color channels of a sRGB image is non-linear, the alpha channel (and CMYK images) are linear.
But you may want to convert those to non-linear sRGB for display on web browsers whcih may not understand a 'linear grayscale' save image. You can do that using -colorspace sRGB instead, though that does convert the data values.

Remember IM is designed for maximum use by as many people as possible. It is not designed to save people from doing the wrong thing. So think about what you want.

fmw42 wrote:

Code: Select all

convert image -set colorspace RGB -channel R -separate +channel result

Note this saves linear-Red values to a grayscale'. Most display programs should convert the linear image to your monitors correct gamma settings, so should come out correct.

However most programs I have seen (including IM "display", and "show:" coder, Eye-of-Gnome, "xv", ) displays the grayscale image as if it is sRGB even though it is flagged as being linear data.

Firefox however displayed the image very 'light', as did the "chrome" web browser. That is it 'colorspace corrected' the image for display and is equivalent to converting 'linear colorspace' to sRGB colorspace, like this NOTE: IM "display" should be displaying the image AS IS, regardless of 'colorspace' on purpose so you can actually see the data AS IS, for debugging purposes. That is the behaviour I am seeing, and is correct, otherwise you could not do something like the above and see a difference.