In a blog comment recently, Rob asked about what happened to isrgb. When you run this function, it issues a warning about being obsolete. Rob asked "What were the toolbox developers thinking?"

The function isrgb is closely related to isgray, isind, and isbw, which are also obsolete. I thought I'd try to explain the original purpose of these functions, as well as why they are now obsolete.

When the Image Processing Toolbox was first being created, in 1992-93, the only MATLAB data type was a two-dimensional, double-precision matrix. There were no integer arrays, no logical arrays, etc. Many toolbox functions were intended to operate on more than one type of image: grayscale, indexed, binary, RGB. Some functions used different algorithms or different defaults, depending upon the input image type. Such a function might have used isgray, etc., like this:

function B = imfoobar(A)

if isbw(A)
  B = do_the_binary_thing(A);  

elseif isind(A)
  B = do_the_indexed_thing(A);

elseif isgray(A)
  B = do_the_grayscale_thing(A);

else
  error('Try, try again'); 
end

There were three problems with this coding pattern:

• Performance
• Ambiguity
• Undesirable limits on input data

The performance problem was that the is* functions read and performed tests on every matrix value. isbw(A) tested to see if every element of A was either 0 or 1. isind(A) tested to see if every value was an integer no smaller than 1. (There were no 0-based uint8 indexed images back then.) isgray(A) tested to see if every value was in the range [0.0, 1.0]. As we worked to speed up toolbox functions in the mid-90s, it became apparent that these function calls limited how fast we could get.

The ambiguity problem was simply this: All of these functions would return true for an all-ones matrix. Also, isgray(A) and isbw(A) would both return true for a matrix containing only zeros and ones. There was simply no way to reliably distinguish the image types from one another based only on the matrix values. By this time in the history of MATLAB development, we were beginning to learn hard lessons about ambiguous syntax designs. Even seemingly benign ambiguities, such as logical indexing, or all those functions that worked down the columns (except when they didn't), were coming back to haunt us.

There's another type of ambiguity associated with these functions. Consider a 100-by-200-by-3 array, for instance. Is it an RGB image? Or a YCbCr image? Maybe it's 3 slices of an MRI, or three frames from a video sequence. The function isrgb can't really tell.

Finally, there was this important principle of Image Processing Toolbox function design: Except for functions that MUST associate a value with a particular color, toolbox functions should make no particular assumptions about the valid range of input values. Display functions and colorspace conversions obviously have to assign colors to matrix values. But most toolbox functions are purely mathematical operations that don't necessarily have anything to do with color, and which can operate on any values. Convolution (imfilter) is an example. Our engineering and scientific customers aren't typically doing picture processing; they are looking at and operating on data using image processing operators. And their data could be in any range, and often had meaningful physical units. Because of this principle, most toolbox functions should not impose any kind of data range restriction, and therefore it generally isn't that useful to be calling isgray(A) to see if the input was in the range [0.0, 1.0].

So eventually we deprecated these functions, stopped using them within the toolbox, and modified toolbox syntaxes to remove ambiguities associated with testing for image type.

In most cases, the person writing the code knows the context of how the matrix or multidimensional array was created or obtained, and so knows whether the code should treat the input as RGB or YCbCr or whatever. The most common case where it makes sense to detect the image type is when you are processing image files. For example, you have a directory full of TIFF files, and some are indexed, some are RGB, etc. In this case, I recommend that you determine the image type directly from the output of imfinfo.

The bottom line is that these functions promise something they can't really deliver. If the functions weren't deprecated, people would be forever confused about how exactly they are supposed to behave, as well as when they should be used.