[Insight-users] Connected component statistics
Miller, James V (Research)
millerjv at crd.ge.com
Wed Jul 20 07:47:18 EDT 2005
A map should be used for the internal implementation. Like you suggested,
however, it is important to provide access methods (or queries) into the map.
One reason this is particularly important is in MSVC++ you cannot pass a reference
or iterators to map across DLL boundaries.
Jim
-----Original Message-----
From: Gaetan Lehmann [mailto:gaetan.lehmann at jouy.inra.fr]
Sent: Wednesday, July 20, 2005 3:01 AM
To: Richard.Beare at ieee.org; Sayan Pathak
Cc: insight-users at itk.org; Miller, James V (Research);
Karthik.Krishnan at kitware.com
Subject: Re: [Insight-users] Connected component statistics
Hi,
even if a map is a good thing for c++ developers, I'm not sure it's really
usable for python (and java, and tcl) ones.
Or the filter must provide methods to access content of the map without
using the map directly. Something like methods in
LabelStatisticsImageFilter :
RealType GetMinimum (LabelPixelType label) const
RealType GetMaximum (LabelPixelType label) const
RealType GetMean (LabelPixelType label) const
RealType GetMedian (LabelPixelType label) const
RealType GetSigma (LabelPixelType label) const
RealType GetVariance (LabelPixelType label) const
RealType GetSum (LabelPixelType label) const
unsigned long GetCount (LabelPixelType label) const
it would be great also to choose consistent name : in other filters, we
have the word "component" and the word "object" for the same thing.
Component seems better to me.
Richard, are you working on this filter ?
I don't think we need to do the work twice :-)
Gaetan
On Wed, 20 Jul 2005 01:14:40 +0200, Richard Beare
<richard.beare at gmail.com> wrote:
> Hi,
> I guess that the ordering can be made somewhat arbitary.
>
> Here's a summary of how the equivalent functions I used in my previous
> job:
>
> step 1 was labelling. This produced an integer image with each
> connected component having a separate label. Labels were consecutive
> and assigned in raster order.
>
> step 2 was computing binary statistics, given this label image. This
> was a single pass process that produced a table of results. Each row
> in the table corresponded to a connected component and included the
> label. The label was somewhat redundant until you started to
> manipulate the table.
>
> Subsequent steps were somewhat arbitary - they may include filtering
> objects based on combinations of these attributes to produce another
> label image, or colouring the regions according to some parameter
> (like area) or any number of other things.
>
> If the aim is to minimize the number of passes through the image then
> relabelling according to ordering of connected component pixels should
> be left as an option to applications that need it - perhaps some sort
> of substitution filter could be developed for that purpose.
>
> Starting on this might be a good introduction to filter writing for me.
>
> On 7/20/05, Sayan Pathak <SayanP at alleninstitute.org> wrote:
>>
>>
>> Hi Jim/Richard,
>> I like the idea of using
>> std::map<itk::CommponentStatistics> type storage. The first
>> entry of the map (the Key) could be the component label index. It would
>> probably be desirable to assign label for each of the connected
>> components
>> in descending order of their size (as it is done in the current filter).
>>
>> Sayan
>>
>> > Date: Tue, 19 Jul 2005 09:18:11 -0400
>> > From: "Miller, James V (Research)" <millerjv at crd.ge.com>
>> > Subject: RE: [Insight-users] Connected component statistics
>> > To: <Richard.Beare at ieee.org>
>> > Cc: insight-users at itk.org, Karthik Krishnan
>> > <Karthik.Krishnan at kitware.com>
>> > Message-ID:
>> >
>> <FA26BEF1EA775E4584FB34B91E14A1C403F34F82 at SCHMLVEM01.e2k.ad.ge.com>
>> > Content-Type: text/plain; charset="iso-8859-1"
>>
>> >
>> > Richard,
>> >
>> > A one pass algorithm is what I would want ITK to have to compute these
>> > statististics for all components. Glad to hear you were already
>> thinking
>> > along those lines.
>> >
>> > As for a representation, I would start with an approach like the
>> RelabelComponentImageFilter
>> > and LabelStatisticsImageFilter. After these filters run, you can
>> query
>> the filter for
>> > the statistics of interest for a given component.
>> >
>> > If this information needs to flow through the pipeline, then a
>> separate
>> data structure,
>> > say a std::map<itk::ComponentStatistics> could be used
>> and wrapped with a DataObjectDecorator
>> > to add a DataObject API to the std::map. We would still have to
>> create an
>> itk::ComponentStatistics
>> > class (or some other named class) to store the statistics for a given
>> component.
>>
>>
>>
>> > Jim
>>
>> > > -----Original Message-----
>> > > From: Richard Beare [mailto:richard.beare at gmail.com]
>> > > Sent: Monday, July 18, 2005 7:37 PM
>> > > To: Miller, James V (Research)
>> > > Cc: Gaetan Lehmann; Karthik Krishnan; insight-users at itk.org
>> > > Subject: Re: [Insight-users] Connected component statistics
>> > >
>> > >
>> > > Hi everyone,
>> > >
>> > > It seems that there are a few starting points around already. The
>> > > measures we computed in my previous job could all be done in a
>> single
>> > > pass and consolidated at the end. I think that most of them have
>> > > already been covered in the discussion.
>> > >
>> > > The only thing I'm not sure about now is an ITK specific question -
>> > > how should the statistics be represented. The previous function of
>> > > this type that I used produced a table of statistics as output, with
>> > > one row for each connected component. This table was easily
>> > > represented as an image. I suspect that this approach wouldn't be
>> > > appropriate in ITK, but I'm not sure what the right mechanism is,
>> > > since I'm still learning my way around.
>>
>> On 7/18/05, Miller, James V (Research) <millerjv at crd.ge.com> wrote:
>> > Gaeton,
>> >
>> > Center of gravity and bounding box could be added to the
>> RelabelStatisticsImageFilter
>> > since they are simple calculations. However, it is a bit of a
>> side-effect. The
>> > volume is calculated in the RelabelStatisticsImageFilter because it is
>> used by the
>> > filter to order the labels. Since it was already calculated, it made
>> sense to allow
>> > the user to access it.
>> >
>> > The best place for these measures and the more complicated measures
>> would
>> be a class
>> > similar to the LabelStatisticsImageFilter. The filter should be called
>> something like
>> > LabelMomentsImageFilter (and calculate ImageMoments as well as
>> geometric
>> moments. Or maybe
>> > something like LabelShapeImageFilter.
>> >
>> > I do not see any reason to use the ImageSpatialMaskObject for this
>> task.
>> Usually, you
>> > would want to calculate these features for EVERY component. So it
>> best to
>> run through a
>> > filter that does it.
>> >
>> > Jim
>> >
>> > -----Original Message-----
>> > From: Gaetan Lehmann [mailto:gaetan.lehmann at jouy.inra.fr]
>> > Sent: Monday, July 18, 2005 4:57 AM
>> > To: Miller, James V (Research); Karthik Krishnan;
>> Richard.Beare at ieee.org
>> > Cc: insight-users at itk.org
>> > Subject: Re: [Insight-users] Connected component statistics
>> >
>> >
>> >
>> > Hi,
>> >
>> > I'm also interested in basic measures such as volume, center of
>> gravity
>> > and bounding box.
>> > I think to work on it this week, so it should be great to define
>> where to
>> > implement methods to get those informations.
>> >
>> > RelabelComponentImageFilter is already able to give volume, so it
>> should
>> > be a good place to add other very simple informations like center of
>> > gravity and bounding box.
>> > It don't seem to be the good place for more complex info such as
>> > perimeter/surface... perhap's ImageMaskSpatialObject is a better
>> place ?
>> >
>> > WDYT ?
>> >
>> > Gaetan
>> >
>> > On Fri, 15 Jul 2005 20:39:46 +0200, Miller, James V (Research)
>> > <millerjv at crd.ge.com> wrote:
>> >
>> > > The LabelStatisticsImageFilter will calculate statistics for each
>> > > component.
>> > > Currently, the LabelStatisticsImageFilter calculate mean, variance,
>> sum,
>> > > count,
>> > > and histograms.
>> > >
>> > > We plan to add another filter that calculated the moments (either
>> image
>> > > moments or
>> > > geometric moments) of each component. I have been waiting for it to
>> be
>> > > completed and
>> > > may have to just write it myself.
>> > >
>> > > Also, the RelabelComponentImageFilter allows you to query the
>> volume of
>> > > a component.
>> > >
>> > > Jim
>> > >
>> > > -----Original Message-----
>> > > From: insight-users-bounces+millerjv=crd.ge.com at itk.org
>> > >
>> [mailto:insight-users-bounces+millerjv=crd.ge.com at itk.org]On
>> Behalf Of
>> > > Karthik Krishnan
>> > > Sent: Friday, July 15, 2005 10:10 AM
>> > > To: Richard.Beare at ieee.org
>> > > Cc: insight-users at itk.org
>> > > Subject: Re: [Insight-users] Connected component statistics
>> > >
>> > >
>> > >
>> > >
>> > > Richard Beare wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> I've found ConnectedComponentImageFilter and
>> > >> RelabelConnectedImageFilter, but I haven't been able to find
>> anything
>> > >> that returns measures of the connected components -- e.g.
>> area/volume,
>> > >> perimeter/surface area, centre of gravity, ellipse moments and
>> minimum
>> > >> enclosing rectangles.
>> > >>
>> > >>
>> > > You could threshold the labelled image to get each connected
>> component
>> > > and...
>> > >
>> > > If you are using CVS ITK, I had put a method recently :
>> > >
>> ImageMaskSpatialObject::GetAxisAlignedBoundingBoxRegion()
>> > > that computes the minimum axis aligned bounding box of a 3D binary
>> image.
>> > >
>> > > ImageMomentsCalculator can help you with moments, CG etc.
>> > >
>> > > An appropriate class to add methods to compute volume, perimeter,
>> > > surface area etc may be theImageMaskSpatialObject class . You could
>> > > write them and put them back into ITK :)
>> > >
>> > > I don't think ITK has many CAD measurement methods.
>> > >
>> > >> Also, what is the recommended approach for making greyscale
>> measures
>> > >> of regions defined by a connected component image?
>> > >>
>> > >> Thanks
>> > >>
>> > >> Richard
>> > >> _______________________________________________
>> > >> Insight-users mailing list
>> > >> Insight-users at itk.org
>> > >> http://www.itk.org/mailman/listinfo/insight-users
>> > >>
>> > >>
>> > >>
>> > > _______________________________________________
>> > > Insight-users mailing list
>> > > Insight-users at itk.org
>> > > http://www.itk.org/mailman/listinfo/insight-users
>> > > _______________________________________________
>> > > Insight-users mailing list
>> > > Insight-users at itk.org
>> > > http://www.itk.org/mailman/listinfo/insight-users
>> >
>> >
>> >
>> > --
>> > Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr>
>> > Tel: +33 1 34 65 29 66
>> > Biologie du Développement et de la Reproduction
>> > INRA de Jouy-en-Josas (France)
>> > Web: http://voxel.jouy.inra.fr
>> >
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
--
Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr>
Tel: +33 1 34 65 29 66
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
Web: http://voxel.jouy.inra.fr
More information about the Insight-users
mailing list