Comments on: R2007b http://blogs.mathworks.com/steve/2007/09/06/r2007b/ Steve Eddins manages the Image & Geospatial development team at <a href="http://www.mathworks.com/">The MathWorks</a> and coauthored <a href="http://www.mathworks.com/support/books/book5291.html?category=-1&language=-1">Digital Image Processing Using MATLAB</a>. He writes here about image processing concepts, algorithm implementations, and MATLAB.<br><br><img> Sun, 08 Nov 2009 03:43:07 +0000 http://wordpress.org/?v=2.3.1 By: Steve http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-9565 Steve Sun, 16 Sep 2007 17:14:08 +0000 http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-9565 Vincent—See my <a href="http://blogs.mathworks.com/steve/2007/09/16/multipage-tiffs/" rel="nofollow">blog post today</a>, or my response to your comp.soft-sys.matlab newsgroup post. Vincent—See my blog post today, or my response to your comp.soft-sys.matlab newsgroup post.

]]> By: Vincent http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-9140 Vincent Thu, 13 Sep 2007 00:27:44 +0000 http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-9140 Actually, what would have been needed is a complete rewrite of imread and imwrite. These have excessive overhead which prevents their use for large images stacks or sequences. For TIFF files, I have been using the low-level functions rtifc and wtifc instead but these also have much overhead. For example, when writing a TIFF stack, wtifc open and closes the TIFF file for every frame added to the stack. The consequence is that the time required to write a stack grows linearly with the size of the stack. This is a major hurdle when dealing with large data sets (tens to hundreds of thousands of images). Anyone aware of a faster library for handling TIFF images? Actually, what would have been needed is a complete rewrite of imread and imwrite. These have excessive overhead which prevents their use for large images stacks or sequences. For TIFF files, I have been using the low-level functions rtifc and wtifc instead but these also have much overhead. For example, when writing a TIFF stack, wtifc open and closes the TIFF file for every frame added to the stack. The consequence is that the time required to write a stack grows linearly with the size of the stack. This is a major hurdle when dealing with large data sets (tens to hundreds of thousands of images). Anyone aware of a faster library for handling TIFF images?

]]> By: Steve http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-8384 Steve Fri, 07 Sep 2007 15:02:35 +0000 http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-8384 Evan—<tt>imread</tt> has been able to read 12-bit TIFFs for several years already. Evan—imread has been able to read 12-bit TIFFs for several years already.

]]> By: Evan http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-8374 Evan Fri, 07 Sep 2007 13:25:16 +0000 http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-8374 So, I can finally read in 12-bit TIFF files? That's been on my wishlist for years, because we use 12-bit CCD cameras. I'm looking forward to trying this out. So, I can finally read in 12-bit TIFF files? That’s been on my wishlist for years, because we use 12-bit CCD cameras. I’m looking forward to trying this out.

]]> By: Steve http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-8359 Steve Fri, 07 Sep 2007 10:45:41 +0000 http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-8359 Noel—The previous limit was 2<sup>31</sup> - 2. I am not aware of any use of the Intel Threading Building Blocks library in MATLAB. Noel—The previous limit was 231 - 2.

I am not aware of any use of the Intel Threading Building Blocks library in MATLAB.

]]> By: noel http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-8248 noel Fri, 07 Sep 2007 00:31:21 +0000 http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-8248 ah cool thanks. so i guess that suggests some change in implementation, since the 2007a limit was 2^32 (maximum size of a 4 byte integer), not 2^31 (maximum offset from a signed 4 byte pointer). a somewhat unrelated question: does/will matlab use the intel TBB anywhere for its multithreaded functions? if that magically is the case, then it would help out a bunch if those headers/binaries/environment variables were distributed in the 2007b matlab installation. we have a bunch of mex files that use the intel TBB, so it would save some effort on installing those libraries if it came for free with the matlab install. ah cool thanks. so i guess that suggests some change in implementation, since the 2007a limit was 2^32 (maximum size of a 4 byte integer), not 2^31 (maximum offset from a signed 4 byte pointer).

a somewhat unrelated question: does/will matlab use the intel TBB anywhere for its multithreaded functions? if that magically is the case, then it would help out a bunch if those headers/binaries/environment variables were distributed in the 2007b matlab installation. we have a bunch of mex files that use the intel TBB, so it would save some effort on installing those libraries if it came for free with the matlab install.

]]> By: Steve http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-8219 Steve Thu, 06 Sep 2007 22:06:10 +0000 http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-8219 Noel—Good questions. It is occasionally necessary in some computations and algorithms to do signed arithmetic on array offsets. That requires a sign bit, so now we're down to 2^63. But really, the current limitation is imposed by processor architectures. My secret source on the core architecture team (thanks, GW) tells me that none of the current 64-bit processor architectures supports 64-bit pointer arithmetic, and some support only 48 bits. So 2^48 is a hardware limitation. The software limitation inside MATLAB code is now 2^63. Here's what the documentation says about multithreaded computation in MATLAB: "multithreaded computation in MATLAB speeds up elementwise computations such as those done by the sin and log functions, and computations that use the Basic Linear Algebra Subroutines (BLAS) library, such as matrix multiply." I expect additional computations to be revised to exploit multithreaded operation in future releases. That is, every 6 months! Noel—Good questions. It is occasionally necessary in some computations and algorithms to do signed arithmetic on array offsets. That requires a sign bit, so now we’re down to 2^63. But really, the current limitation is imposed by processor architectures. My secret source on the core architecture team (thanks, GW) tells me that none of the current 64-bit processor architectures supports 64-bit pointer arithmetic, and some support only 48 bits. So 2^48 is a hardware limitation. The software limitation inside MATLAB code is now 2^63.

Here’s what the documentation says about multithreaded computation in MATLAB: “multithreaded computation in MATLAB speeds up elementwise computations such as those done by the sin and log functions, and computations that use the Basic Linear Algebra Subroutines (BLAS) library, such as matrix multiply.” I expect additional computations to be revised to exploit multithreaded operation in future releases. That is, every 6 months!

]]> By: noel http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-8191 noel Thu, 06 Sep 2007 18:55:59 +0000 http://blogs.mathworks.com/steve/2007/09/06/r2007b/#comment-8191 just curious, why is the limit on number of elements 2^48 - 1? 2^64 - 1 would seem more natural. what functions does maxNumComputationalThreads affect? just BLAS and LAPACK calls, or will other matlab functions utilize more than 1 thread? just curious, why is the limit on number of elements 2^48 - 1? 2^64 - 1 would seem more natural.

what functions does maxNumComputationalThreads affect? just BLAS and LAPACK calls, or will other matlab functions utilize more than 1 thread?

]]>