Comments on: bwlabeln – design decision http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/ 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. Sat, 11 Feb 2012 18:27:50 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Steve http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-20738 Steve Tue, 27 May 2008 13:15:31 +0000 http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-20738 Jiang—Thanks for your comments. Jiang—Thanks for your comments.

]]> By: jiang http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-20726 jiang Wed, 21 May 2008 14:46:58 +0000 http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-20726 bwlabeln would output something smaller than a double. another choice is if the bwlabeln could be implemented by using the index of connected components , or the spare matrix . by this way , the matrix could be rather large . maybe bwlabeln have a improved performance. bwlabeln would output something smaller than a double.

another choice is if the bwlabeln could be implemented by
using the index of connected components , or the spare
matrix . by this way , the matrix could be rather large .
maybe bwlabeln have a improved performance.

]]> By: jiang http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-20725 jiang Wed, 21 May 2008 14:41:24 +0000 http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-20725 i have change the bwlabl c function output data type to uint16, and the output support uint16 . so the matrix can be large. i have change the bwlabl c function output data type to uint16, and the output support uint16 .

so the matrix can be large.

]]> By: Steve http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-18540 Steve Fri, 11 Jan 2008 19:24:16 +0000 http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-18540 Jeremy—Thanks for your comments. It's on my list of things to think about. Jeremy—Thanks for your comments. It’s on my list of things to think about.

]]> By: Jeremy http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-18405 Jeremy Wed, 09 Jan 2008 23:00:55 +0000 http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-18405 Steve, I just want to say that I agree with Pete, it would be nice if bwlabeln would output something smaller than a double. I too am working with rather large images and I would like to process them in parallel, but if each of the labs call bwlabeln at the same time I quickly run out of memory. I know in my image that I should have less than 2000 objects. I also know that if the number of object approaches 2^16, something went seriously wrong. Thus, as you can see, having more control of the output class from bwlabeln would be benefical Thanks Steve,
I just want to say that I agree with Pete, it would be nice if bwlabeln would output something smaller than a double. I too am working with rather large images and I would like to process them in parallel, but if each of the labs call bwlabeln at the same time I quickly run out of memory.

I know in my image that I should have less than 2000 objects. I also know that if the number of object approaches 2^16, something went seriously wrong. Thus, as you can see, having more control of the output class from bwlabeln would be benefical

Thanks

]]> By: Steve http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-18239 Steve Mon, 07 Jan 2008 14:41:34 +0000 http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-18239 Beverley—If your image is already labeled, there's nothing else you need to do before calling <tt>regionprops</tt>. Also, you might consider calling <tt>bwlabel</tt>, which is usually faster than <tt>bwlabeln</tt> for two-dimensional images. I don't understand the second part of your question. Beverley—If your image is already labeled, there’s nothing else you need to do before calling regionprops. Also, you might consider calling bwlabel, which is usually faster than bwlabeln for two-dimensional images. I don’t understand the second part of your question.

]]> By: beverley http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-18174 beverley Sun, 06 Jan 2008 15:50:59 +0000 http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-18174 Hi steve, i have a question to ask regarding the bwlabeln, i have already implemented it to the image selected by using bwlabeln(L,4) and have come up with an image labelled with {17 20 21 23 25 26} since six patches are determined from the image, i dont know how to separate the clusters so that i can use the regionprops to determine the area. plus my algorithm will be applied to different images so the label for the patches varies, what should i do to pull these clusters to start feature extraction already thanks steve -beverley Hi steve,

i have a question to ask regarding the bwlabeln, i have already implemented it to the image selected by using bwlabeln(L,4) and have come up with an image labelled with {17 20 21 23 25 26} since six patches are determined from the image, i dont know how to separate the clusters so that i can use the regionprops to determine the area. plus my algorithm will be applied to different images so the label for the patches varies, what should i do to pull these clusters to start feature extraction already
thanks steve
-beverley

]]> By: Steve http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-13167 Steve Wed, 31 Oct 2007 12:11:34 +0000 http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-13167 Pete—Thanks. Pete—Thanks.

]]> By: Pete http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-13047 Pete Mon, 29 Oct 2007 17:02:16 +0000 http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-13047 Yes, I think that would be better. I actually find myself drawn to the idea that the default class remains double, but the user can specify another class if they consider it necessary - that way one always knows in advance what class to expect. But that may be symptomatic of a personal need-for-control issue which I ought to overcome, since I am struggling to think of an occasion when using anything other than the smallest required class would actually be useful. Unless it simplifies implementation or backwards compatibility. Sorry, I'm not good at deciding even my own wishes. But yes, the option of using something smaller than double, either automatically or otherwise, is something I would find useful. Yes, I think that would be better.

I actually find myself drawn to the idea that the default class remains double, but the user can specify another class if they consider it necessary – that way one always knows in advance what class to expect. But that may be symptomatic of a personal need-for-control issue which I ought to overcome, since I am struggling to think of an occasion when using anything other than the smallest required class would actually be useful. Unless it simplifies implementation or backwards compatibility.

Sorry, I’m not good at deciding even my own wishes. But yes, the option of using something smaller than double, either automatically or otherwise, is something I would find useful.

]]> By: Steve http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-13045 Steve Mon, 29 Oct 2007 16:22:37 +0000 http://blogs.mathworks.com/steve/2007/07/17/bwlabeln-design-decision/#comment-13045 Pete—So would you like to see the output class dependent on how many objects there are? Pete—So would you like to see the output class dependent on how many objects there are?

]]>