[Insight-users] Problems about ImageBoundaryFacesCalculator
Miller, James V (Research)
millerjv at crd.ge.com
Fri, 16 Apr 2004 09:35:06 -0400
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C423B7.A139E624
Content-Type: text/plain
The boundary faces calculator attempts to decompose an image to
NON-overlapping regions.
However, there is currently a bug in the implementation where under certain
radii and image size combinations, a few pixels can appear in multiple
regions. (In extreme cases where one image dimension is less than the radii,
a large percentage of the pixels can appear in multiple images). This is
not only a problem for performance reasons, it also creates the potential
for errors the a filter is run on multiple processors (i.e. several threads
could attempt to set the same output pixel at the same time).
In most circumstances, however, the overlap is zero or simply a few pixels.
I attempted to fix this prior to the 1.4 release but had a problem with my
implementation on linux. I will re-visit this issue. The behavior should
be that each pixel should only appear in one region. The set of regions
outputted with always be ordered as the first region wil lhave no boundary
conditions (but the region may be empty) and the remainder of the regions
will all have boundary conditions.
Jim
-----Original Message-----
From: Yan Shang [mailto:yan.shang at ibt.uni-karlsruhe.de]
Sent: Friday, April 16, 2004 6:52 AM
To: insight-users at itk.org
Subject: [Insight-users] Problems about ImageBoundaryFacesCalculator
dear Luis,
I have the following question:
Using NeighborhoodAlgorithm::ImageBoundaryFacesCalculator will decomposed
the input image into overlapped regions, that means some pixels can belong
to several boundary regions ( i.e., for 3D, radius=3, the pixels ( in the
upper left 3*3*3 region) will belong at the same time to the boundary
regions in x, y, z direction.)
If we use the above mentioned decomposed regions of the input image in a
filter, the pixels belonging to several regions will be calculated
repeatedly, this will cause a great computational burden if the image and
radius are both large.
Am I right in this point?
yan
------_=_NextPart_001_01C423B7.A139E624
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE></TITLE>
<META content="MSHTML 6.00.2800.1276" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=053012813-16042004><FONT color=#0000ff size=2>The boundary
faces calculator attempts to decompose an image to NON-overlapping
regions.</FONT></SPAN></DIV>
<DIV><SPAN class=053012813-16042004><FONT color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=053012813-16042004><FONT color=#0000ff size=2>However, there is
currently a bug in the implementation where under certain radii and image size
combinations, a few pixels can appear in multiple regions. (In extreme cases
where one image dimension is less than the radii, a large percentage of the
pixels can appear in multiple images). This is not only a problem for
performance reasons, it also creates the potential for errors the a filter is
run on multiple processors (i.e. several threads could attempt to set the same
output pixel at the same time).</FONT></SPAN></DIV>
<DIV><SPAN class=053012813-16042004><FONT color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=053012813-16042004><FONT color=#0000ff size=2>In most
circumstances, however, the overlap is zero or simply a few
pixels.</FONT></SPAN></DIV>
<DIV><SPAN class=053012813-16042004><FONT color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=053012813-16042004><FONT color=#0000ff size=2>I attempted to
fix this prior to the 1.4 release but had a problem with my implementation on
linux. I will re-visit this issue. The behavior should be that each
pixel should only appear in one region. The set of regions outputted with
always be ordered as the first region wil lhave no boundary conditions (but the
region may be empty) and the remainder of the regions will all have boundary
conditions.</FONT></SPAN></DIV>
<DIV><SPAN class=053012813-16042004><FONT color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=053012813-16042004><FONT color=#0000ff
size=2>Jim</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Yan Shang
[mailto:yan.shang at ibt.uni-karlsruhe.de]<BR><B>Sent:</B> Friday, April 16, 2004
6:52 AM<BR><B>To:</B> insight-users at itk.org<BR><B>Subject:</B> [Insight-users]
Problems about ImageBoundaryFacesCalculator<BR><BR></FONT></DIV>
<P>dear Luis, </P><BR>
<P>I have the following question: </P><BR>
<P>Using <FONT
face="Courier New">NeighborhoodAlgorithm::</FONT>ImageBoundaryFacesCalculator
will decomposed the input image into overlapped regions, that means some
pixels can belong to several boundary regions ( i.e., for 3D, radius=3, the
pixels ( in the upper left 3*3*3 region) will belong at the same time to the
boundary regions in x, y, z direction.) </P><BR>
<P>If we use the above mentioned decomposed regions of the input image in a
filter, the pixels belonging to several regions will be calculated repeatedly,
this will cause a great computational burden if the image and radius are both
large. </P><BR>
<P>Am I right in this point? </P><BR>
<P>yan </P></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C423B7.A139E624--