Comments on: R2008b http://blogs.mathworks.com/steve/2008/11/03/r2008b/ Steve Eddins manages the Image & Geospatial development team at The MathWorks and coauthored Digital Image Processing Using MATLAB. He writes here about image processing concepts, algorithm implementations, and MATLAB. Wed, 01 Feb 2012 13:58:45 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Steve http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21277 Steve Mon, 24 Nov 2008 16:38:49 +0000 http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21277 A. Ghaffar—You'll have to upgrade to R2008b. A. Ghaffar—You’ll have to upgrade to R2008b.

]]> By: A. Ghaffar http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21276 A. Ghaffar Mon, 24 Nov 2008 16:30:21 +0000 http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21276 Hi Steve Is the code for cornermetric function available freely or the new release has to be purchased? I have R2007a currently. Hi Steve
Is the code for cornermetric function available freely or the new release has to be purchased? I have R2007a currently.

]]> By: Steve http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21263 Steve Tue, 18 Nov 2008 14:05:56 +0000 http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21263 Okinawa—Thanks for the additional information. Here's what I get on my computer (an IBM Thinkpad T60 laptop). For binary dilation of a 480-by-640 image with a disk structuring element with radius 10: 18ms. For grayscale bottom-hat of 576-by-768 image with 32-by-32 structuring element: 103ms. Okinawa—Thanks for the additional information. Here’s what I get on my computer (an IBM Thinkpad T60 laptop). For binary dilation of a 480-by-640 image with a disk structuring element with radius 10: 18ms. For grayscale bottom-hat of 576-by-768 image with 32-by-32 structuring element: 103ms.

]]> By: OkinawaDolphin http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21261 OkinawaDolphin Mon, 17 Nov 2008 13:03:15 +0000 http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21261 My most recent application works with images that have 640 * 480 pixels. The structuring element for binary closing is a disk with a radius of 10 pixels. I tested this application with the profiler several times and the average processing time per image is 300 ms. These 300 ms are related to the whole processing, not only to morphologic operations and regionprops. However, regionprops and morphologic filtering are definitely the bottle neck. Another application is steel surface inspection. The current image size is 768 * 426 pixels. It can be set to 768 * 576 pixels because this is the video resolution. The structuring element for grayscale bottom hat is a square with 32 * 32 pixels. The functions imbothat and regionprops are called at least twice per image if any objects are found. The processing time varies with the number of objects found on the surface and it can be from 400 ms (no objects indicating damages) to 900 ms on a computer with a dual core processor. The processing time for this application has never been as short as 300 ms on a computer I profiled it with. The speed of steel is 1 m/s - 2 m/s and the length of the imaged area is around 1.1 m - 1.6 m. This means that the processing time for one image should not exceed 800 ms to ensure that the whole surface is examined. If both sides are inspected simultaneously, the limit for processing time is as low as 400 ms. This applied for a very early stage of steel production. The steel moves much faster than this at later stages. My most recent application works with images that have 640 * 480 pixels. The structuring element for binary closing is a disk with a radius of 10 pixels. I tested this application with the profiler several times and the average processing time per image is 300 ms. These 300 ms are related to the whole processing, not only to morphologic operations and regionprops. However, regionprops and morphologic filtering are definitely the bottle neck.

Another application is steel surface inspection. The current image size is 768 * 426 pixels. It can be set to 768 * 576 pixels because this is the video resolution. The structuring element for grayscale bottom hat is a square with 32 * 32 pixels. The functions imbothat and regionprops are called at least twice per image if any objects are found.

The processing time varies with the number of objects found on the surface and it can be from 400 ms (no objects indicating damages) to 900 ms on a computer with a dual core processor. The processing time for this application has never been as short as 300 ms on a computer I profiled it with.

The speed of steel is 1 m/s – 2 m/s and the length of the imaged area is around 1.1 m – 1.6 m. This means that the processing time for one image should not exceed 800 ms to ensure that the whole surface is examined. If both sides are inspected simultaneously, the limit for processing time is as low as 400 ms. This applied for a very early stage of steel production. The steel moves much faster than this at later stages.

]]> By: Steve http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21250 Steve Fri, 14 Nov 2008 17:14:32 +0000 http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21250 Okinawa—Thanks for your input. We are looking at possible performance improvements for many toolbox features, including grayscale morphology. Where does your 300ms number come from? For what size image and what size structuring element? What is your expectation for what the time should be, and what is the basis for your expectation? Okinawa—Thanks for your input. We are looking at possible performance improvements for many toolbox features, including grayscale morphology. Where does your 300ms number come from? For what size image and what size structuring element? What is your expectation for what the time should be, and what is the basis for your expectation?

]]> By: Steve http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21249 Steve Fri, 14 Nov 2008 17:11:07 +0000 http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21249 Michael—Yes, we do plan to support BigTIFF. Our preference is to wait until there is an official LibTIFF library release supporting BigTIFF. The library version currently being distributed with BigTIFF support is still in beta, if I understand correctly. Michael—Yes, we do plan to support BigTIFF. Our preference is to wait until there is an official LibTIFF library release supporting BigTIFF. The library version currently being distributed with BigTIFF support is still in beta, if I understand correctly.

]]> By: OkinawaDolphin http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21243 OkinawaDolphin Thu, 13 Nov 2008 09:31:28 +0000 http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21243 It is nice to hear that binary dilation has been made faster. However, morphological operations on grayscale images should be made faster, too. Matlab is very handy for designing algorithms for surface inspection and other image processing applications. However, deployed Matlab programs are slow when compared to programs written in C++. It is true that it is cumbersome to do image processing with C and Assembler or with C++. This is much easier with Matlab and Simulink. However, 300 ms per image are just too long a processing time in many image processing applications. It is nice to hear that binary dilation has been made faster. However, morphological operations on grayscale images should be made faster, too.

Matlab is very handy for designing algorithms for surface inspection and other image processing applications. However, deployed Matlab programs are slow when compared to programs written in C++. It is true that it is cumbersome to do image processing with C and Assembler or with C++. This is much easier with Matlab and Simulink. However, 300 ms per image are just too long a processing time in many image processing applications.

]]> By: Michael http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21236 Michael Mon, 10 Nov 2008 23:13:15 +0000 http://blogs.mathworks.com/steve/2008/11/03/r2008b/#comment-21236 Are there any plans to include support for BigTIFF in imread? If not, do you know of any ways of getting around this? Are there any plans to include support for BigTIFF in imread? If not, do you know of any ways of getting around this?

]]>