Path: news.mathworks.com!not-for-mail
From: Steve Eddins <Steve.Eddins@mathworks.com>
Newsgroups: comp.soft-sys.matlab
Subject: Re: How does bwlabel work?
Date: Thu, 31 Jan 2008 10:57:13 -0500
Organization: The MathWorks, Inc.
Lines: 45
Message-ID: <fnsr4n$57s$1@fred.mathworks.com>
References: <fnrl3h$i3i$1@fred.mathworks.com> <14977013.1201760451936.JavaMail.jakarta@nitrogen.mathforum.org> <fnsdfi$it7$1@fred.mathworks.com> <fnsk56$1oh$1@fred.mathworks.com> <fnsnmc$gar$1@canopus.cc.umanitoba.ca>
NNTP-Posting-Host: eddinss-lt.dhcp.mathworks.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: fred.mathworks.com 1201795031 5372 172.31.57.98 (31 Jan 2008 15:57:11 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Thu, 31 Jan 2008 15:57:11 +0000 (UTC)
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
In-Reply-To: <fnsnmc$gar$1@canopus.cc.umanitoba.ca>
Xref: news.mathworks.com comp.soft-sys.matlab:448575


Walter Roberson wrote:
> In article <fnsk56$1oh$1@fred.mathworks.com>,
> Steve Eddins  <Steve.Eddins@mathworks.com> wrote:
> 
>> There's no way to tell bwlabel to search in a different order.  If it 
>> did search in a different order, it would run significantly slower 
>> because of memory cache effects.
> 
> You (the programmer desiring the "different order") could transpose
> or fliplr or flipud the matrix first ;-)
> 
> 
> I have never tried bwlabel(), so I do not have any feel for its
> performance on different image sizes, and I have not looked at
> the algorithm used. But as a user, I would think that if I have
> good reasons to want a different search order, that I would accept
> the performance implications that went along with chosing that
> option. I would suggest, then, that you consider allowing an
> optional parameter which is a permutation vector of the
> (1-D) pixel indices, with the pixels to be visited in the order
> of that vector.

It's a good suggestion, but I would not be inclined to make that change 
for these reasons:

a. User can preprocess image, as you suggested
b. User can postprocess output labels, as I will probably demonstrate 
soon on my blog
c. Lack of well-defined sorting order for two-dimensional space
d. Substantial increase in complexity of code and testing, with a 
corresponding increase in the likelihood of programming errors
e. "Opportunity cost" - implementing this change means we would not have 
time for implementing other requested features, including other 
user-suggested changes to bwlabel that would have broader benefit

In my opinion, user post-processing, assisted by the output of 
regionprops, is probably the best way to go because of reason c.  Even 
if we permute the search order, the output labels may still not be 
ordered exactly the way the user desired, whatever that might be.

Thanks,

Steve