Steve on Image Processing
March 9th, 2007
What happened to isgray, isind, isbw, and isrgb?
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.
7:00 am |
Posted in Uncategorized |
Permalink |
You can follow any responses to this entry through the RSS 2.0 feed.
You can skip to the end and leave a response. Pinging is currently not allowed.
Leave a Reply
|
Steve,
Thanks for the explanation of how the is* functions evolved, and the lessons you learned from them. That is exactly what I had in mind when requesting to know “what they were thinking” when decisions like these are often made. Makes sense, and I’ll be using imfinfo now instead of testing whole matrices. I was aware of the false positives you could get from them, but honestly had not considered the speed impact.
Regards,
Rob
Dear Mr.Eddins
I am a self_learning about matlab (image toolbox),
i am working on roots of the olive to constract the sub_branchs and main_branchs (length_width)after doing a perfect thresholding to work on binary images
i will really aprciate if you let me in contact while i’m preparing my algorithms for the roots
Best Regards
Hi steve I have a request
when I have several 3D cordinate
How I can recive equation of that coordinate
Thanks
James - I’m sorry, but I don’t understand your question. It it about image processing, and can you be much more specific?
i mant to perform the ambiguity function on thr evoked potential of EEG signals and use fisher contrast for classification how i find ambiguity function and fisher contrast and perform them on matlab
Hanaa - I don’t have information on those terms and operations. May I suggest that you use libraries, journals, books, and Internet searches?