Group Abstract Group Abstract

Message Boards Message Boards

1
|
9.8K Views
|
4 Replies
|
8 Total Likes
View groups...
Share
Share this post:

Avoid inconsistent behavior of ColorSpace -> Automatic?

Alexey Popkov
Posted 8 years ago

I have a question about processing of images with ColorSpace -> Automatic by Mathematica.

First of all, ColorSpace -> Automatic is assumed by default when no colorspace is specified for a new Image object:

i1 = Image[{{{.1, .3, .5}}}, "Real"]; 
i1 // Options

{ColorSpace -> Automatic, Interleaving -> True}

Earlier versions of the Documentation didn't explain what ColorSpace -> Automatic means. The most recent version mentions this option value only on the Documentation page for ImageColorSpace where the following is written:

Returned color space can be any of the following:
??<...>
??Automatic??no color space specified

So it means exactly "no color space specified" and nothing more. Logical and expected, but is this really so?

Let us create several one-pixel images with different number of color channels and try to convert them to the "RGB" colorspace. This task is apparently ambiguous since it isn't clear how to convert an image from unknown colorspace with arbitrary number of channels to RGB, so I would expect Mathematica to return an error saying precisely this. Let us check:

i2=Image[{{{.1,.3,.5,.7}}},"Real"];
i3=Image[{{{.1,.3,.5,.6,.7}}},"Real"];
i4=Image[{{{.1,.3,.5,.6,.65,.7}}},"Real"];
Column[InputForm[ColorConvert[#,"RGB"]]&/@{i1,i2,i3,i4}]

Image[{{{0.1, 0.3, 0.5}}}, "Real", ColorSpace -> "RGB", Interleaving -> True]
Image[{{{0.1, 0.4, 0.7}}}, "Real", ColorSpace -> "RGB", Interleaving -> True]
Image[{{{0.1, 0.4, 0.6499999999999999}}}, "Real", ColorSpace -> "RGB", Interleaving -> True]
Image[{{{0.2, 0.55, 0.675}}}, "Real", ColorSpace -> "RGB", Interleaving -> True]

We have got no expected error messages and some strange images as the output. The first case (i1) is obvious: the channel values just remain the same, hence ColorSpace -> Automatic in this case is assumed to be equivalent to ColorSpace -> "RGB" (what is undocumented and unexpected of course: why not "HSB", "LUV", "LAB", etc.?). The other cases are entirely unclear: why the four-channel pixel {.1,.3,.5,.7} is converted to the three-channel one {0.1, 0.4, 0.7}? Why the five-channel pixel {.1,.3,.5,.6,.7} is converted to the three channel {0.1, 0.4, 0.65}, and so on? What happens here? Apparently this behavior is inconsistent and misleading and can cause subtle bugs which are hard to debug when developing a serious image-processing application.

So my questions are:

1) Is it a bug that ColorConvert behaves this way?

2) If not, what is the meaning of ColorSpace -> Automatic then? Apparently it doesn't currently mean "no color space specified" at least for ColorConvert.

3) How other image-processing functions handle ColorSpace -> Automatic?

(Inspired by this question; reported to the support as [CASE:3963067].)
POSTED BY: Alexey Popkov
4 Replies
Sort By:

One additional interesting evaluation is to observe the conversion of a 2 channel image to RGB

im = Image[{{{1, 0}}}, ColorSpace -> Automatic, Interleaving -> True];
im2 = ColorConvert[im, "RGB"];
ImageData[im2]

{{{0., 0.707106, 0.707106}}}

Okay, I have no idea why that formula is used. Pretty interesting.

And, finally, when an image with automatic colorspace is displayed in a notebook, the same computations that we see in ColorConvert[-image-, "RBG"] are used. Here is one way to show that (I don't want to upload an image here):

In[33]:= Rasterize[im, "Image"] === Rasterize[ColorConvert[im, "RGB"]]

Out[33]= True
POSTED BY: Chad Knutson

1) By specifying the 2nd argument to ColorConvert as "RGB", you are asking for an "RGB" color. So whatever you pass to that function will necessarily be converted to 3 channels. If you have a alternative suggestion for how to convert multi-dimensional (greater than 3), unspecified colorspaces to RGB, please share. Or you could simply define your own function and use it.

To me, an analogous problem is projecting a 5-dimensional object to 3 dimensions. How would you determine the correspondence of the 5 dimensions to 3D space? Obviously, there are many ways to do this, but I don't know how you would determine which approach is 'best'.

2) I don't understand this comment. You can certainly create a 6 channel image. You can do many calculations in Mathematica on the 6 channel image without any consideration for how to represent the pixel data visually. If you ask the front end to display the image, Mathematica will use the colorspace conversion you showed in your calculations.

For practical purposes, I'd advise using one of our defined colorspaces (and corresponding number of channels).

3) Behavior depends on the function. Binarize will take the mean of all channel data at a pixel. The *Filter functions work on each channel indepe
POSTED BY: Chad Knutson
Alexey Popkov
Alexey Popkov
Posted 8 years ago

If you have a alternative suggestion for how to convert multi-dimensional (greater than 3), unspecified colorspaces to RGB, please share.

I would certainly expect at least an error message warning the user that the operation is ambiguous and telling what choice Mathematica does in this situation. Without the warning current behavior just deceives the user because he/she almost certainly does NOT want/expect to obtain what Mathematica generates from images having 2 or 4 channels, or more. Personally I would prefer the warning and $Failed as the output (for making debugging and programming easier), but I insist only on the warning message.

Obviously, there are many ways to do this, but I don't know how you would determine which approach is 'best'.

This is the reason why the warning message in such situation is necessary, as well as clear explanation in the Documentation of the Mathematica's approach to the problem. At the moment there is neither the one nor the other.

I don't understand this comment.

Probably I wasn't sufficiently clear. I mean that if really the colorspace is unspecified, then the problem of correct conversion to RGB has no solution. Since Mathematica currently performs the conversion, it apparently assumes an artificial "colorspace" under ColorSpace -> Automatic. In the other words, ColorSpace -> Automatic does mean some undocumented and completely imaginary colorspace in the context of ColorConvert, what directly contradicts the cited statement from the Documentation.

Binarize will take the mean of all channel data at a pixel.

Thanks, didn't know this. Is it documented anywhere?
POSTED BY: Alexey Popkov

In the doc page for Binarize (under Details and Options), is this statement: Binarize works with 2D and 3D images. It converts multichannel and color images into grayscale images, then produces an image in which every pixel has value 0 or 1.

Interestingly, this statement is not completely accurate, as my function below demonstrates. But at least the behavior for Binarize makes more sense than the ColorConvert to "Grayscale" evaluation. I'd argue that the latter implementation is a bug.

In[98]:= binComp[imageData_List, thresh_] :=
 Module[{im, im2},
  im = Image[imageData, ColorSpace -> Automatic, Interleaving -> True];
  im2 = ColorConvert[im, "Grayscale"];
  ImageData /@ {Binarize[im, thresh], Binarize[im2, thresh]}
  ]

In[99]:= binComp[{{{1, 1, 1, 0, 0, 0}}}, 0.5]

Out[99]= {{{0}}, {{1}}}

In[100]:= binComp[{{{1, 1, 1.001, 0, 0, 0}}}, 0.5]

Out[100]= {{{1}}, {{1}}}

I argue that this evaluation is a bug:

In[102]:= 
ColorConvert[
  Image[{{{1, 1, 1, 0, 0, 0}}}, ColorSpace -> Automatic, 
   Interleaving -> True], "Grayscale"] // ImageData

Out[102]= {{0.5925}}

Thanks for your input. Your objections are certainly valid!
POSTED BY: Chad Knutson
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Tag limit exceeded
Note: Only the first five people you tag will receive an email notification; the other tagged names will appear as links to their profiles.
Reply Preview
Attachments
Remove
or Discard