{"id":284,"date":"2009-08-31T13:30:18","date_gmt":"2009-08-31T17:30:18","guid":{"rendered":"https:\/\/blogs.mathworks.com\/steve\/2009\/08\/31\/functional-design-clunkers\/"},"modified":"2019-10-28T16:57:22","modified_gmt":"2019-10-28T20:57:22","slug":"functional-design-clunkers","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/steve\/2009\/08\/31\/functional-design-clunkers\/","title":{"rendered":"Functional design clunkers"},"content":{"rendered":"
\r\n

Sometimes I'd really like to be able to go back in time and fix a few of the functional designs in the Image Processing Toolbox.\r\n In a few cases the original design flaw is that we bundled up a little too much functionality in a single function. I'll\r\n give you two examples: graythresh<\/tt><\/a> and edge<\/tt><\/a>.\r\n <\/p>\r\n

The function graythresh<\/tt> uses Otsu's method<\/a> to automatically determine a \"good\" threshold for a gray-scale image. You use it like this:\r\n <\/p>

I = imread('coins.png'<\/span>);\r\nimshow(I)<\/pre> 
T = graythresh(I); % T is a normalized threshold value between 0 and 1<\/span>\r\nbw = im2bw(I, T);\r\nimshow(bw)<\/pre> 
The functional design flaw here is that Otsu's method doesn't really need the original image at all. It is defined solely\r\n      in terms of the histogram<\/i> of the image.  The first thing graythresh<\/tt> does is compute the histogram.\r\n   <\/p>\r\n   
But what if you had already computed the histogram for some other purpose? There's no way to use graythresh<\/tt> without computing it again.\r\n   <\/p>\r\n   
My own functional design sensibility has evolved toward writing more functions that do smaller, simpler steps. So today I\r\n      would design a function like graythresh<\/tt> so that it took a histogram as the input argument.\r\n   <\/p>\r\n   
But isn't that less convenient? Yes. But I would move the \"convenience\" syntax elsewhere, probably to im2bw<\/tt><\/a> by giving it an \"automatic threshold\" syntax. If I could redesign im2bw<\/tt> together with graythresh<\/tt>, I would probably make the single-input syntax im2bw(I)<\/tt> use graythresh<\/tt> behind the scenes to compute the threshold automatically.\r\n   <\/p>\r\n   
That design would be more<\/i> convenient than it is today, because you could type im2bw(I)<\/tt> instead of im2bw(I, graythresh(I))<\/tt>, and it would also be more flexible<\/i> because you would have access to smaller computational pieces.\r\n   <\/p>\r\n   
The function edge<\/tt> has a similar problem. Several of the supported edge detection methods, such as Sobel and Roberts, use the gradient magnitude.\r\n       The gradient magnitude is computed within edge<\/tt>, but there's no separate toolbox function for computing it.  The toolbox and MATLAB have the low-level functions and operators\r\n      that can be used to compute the gradient magnitude (fspecial<\/tt><\/a>, imfilter<\/tt><\/a>, ^2<\/tt>, sqrt<\/tt>), and the high-level function edge<\/tt> uses the gradient magnitude, but there's no function in the middle that conveniently computes the gradient magnitude for\r\n      you.\r\n   <\/p>\r\n   
I mention these examples to encourage you to think about your own approach to breaking down your computations into functions.<\/p>\r\n   
I would also be interested to hear your opinions about what other functional designs in MATLAB and the Image Processing Toolbox\r\n      could be better. Please add your comments to this post.\r\n   <\/p>