[Insight-developers] LabelObject attributes

[Gaëtan Lehmann]

Le 29 sept. 10 à 13:19, <david.pastor at acacia.die.upm.es> <david.pastor at acacia.die.upm.es 
 > a écrit :

>
> Hi!
>
> I'm not sure what you mean that a label object might not be a  
> connected
> component, in which cases that does happen? I thought you use
> ConnectedComponent algorithm to cluster objects...

That's one of the available options.

You can also create it by hand by using itk::LabelMap::SetPixel() or  
convert a label image in a label map. In those case, the objects are  
not necessarily connected - they may even overlap!

>
> I think it can be the case when you have 2 different component objects
> with the same label... but what happens with a binary image then?

a binary image is necessarily converted with a connected component  
algorithm

>
> About the openings... I'd like to perform sum-based openings and
> shapeAttributes openings, but from label object map we are not able to
> come back to the original grayscale image... so it is not an actual
> "filtering".
> I think it could be done by performing binary openings on the label  
> map
> and then use it as a mask image to segment the grayscale. That could  
> be
> a workaround.
>
> I haven't looked at treeComponent stuff in a while, I don't know if it
> undergoes some work now...

not much - I only make sure that it still build, so I can use it,  
that's all.
That would certainly be one way to go for your example above.

> Beare's AttributeOpening contribution worked
> fine for me but I think it has some tricky implementation and only
> limited to areaOpening

yes, I also think so.

Gaëtan

>
> Best
> David
>
>
> On 29/9/2010, "Gaëtan Lehmann" <gaetan.lehmann at jouy.inra.fr> wrote:
>
>>
>> Le 28 sept. 10 à 10:46, David Pastor a écrit :
>>
>>> Hello,
>>
>> Hi David,
>>
>>>
>>> - About the Size / PhysicalSize I think current names are ok, a bit
>>> vague, but as you say which suits for 2D does not suit for 3D (or
>>> even 4D).
>>
>> Not much people seems to like Volume as a name for that attribute!
>> Do you think there would be a consistency problem if we have
>> NumberOfPixels and PhysicalSize ?
>>
>>>
>>> - For me, it would be helpful to have the centroid coordinates in
>>> pixels as output (just a friendly programming issue). Said that, I
>>> don't know if it is too redundant to have all measures in Pixel vs
>>> Phyisical returned values being Physical the adjective to specifiy
>>> they are physical and not pixel-based.
>>
>> I'd say this is too much redundant, given that the continuous index
>> can very easily be computed with dedicated methods in itk::ImageBase.
>>
>>> I have not used StatisticsLabelObject, but I am a bit confussed now
>>> as I thought that when you work with label objects you lose the
>>> intensity information.
>>
>> StatisticsLabelObject can store some values about the intensity in  
>> the
>> region covered by the label object. There is no way to recreate the
>> image of the intensities in that region from this values.
>>
>>> Anyway I find very interesting the CenterOfGravitiy and I imagine
>>> that "sum" stands for the intensity accumuled in the object region?
>>
>> that's it
>>
>>>
>>> A more general suggestion is to be able to specify the structuring
>>> element used to find the connectivity of the label objects
>>
>> I fully agree, but that may be quite difficult to implement in an
>> efficient way.
>> LabelMap and LabelObject are not defining the connectivity though -
>> LabelObject are not even necessarily connected, so if someone wants  
>> to
>> develop a new filter for this task, that would make a very nice
>> contribution for the insight journal :-)
>>
>>> or being able to perform a wider range of attribute openings/
>>> closings (generalization of area opening contribution and object
>>> tree contribution).
>>>
>>
>> Are you thinking to some specific examples?
>> Have you looked at AttributeLabelObject?
>>
>>> thanks for the useful contributions
>>
>> Thanks for your comments!
>>
>> Gaëtan
>>
>>>
>>> Best
>>> David
>>>
>>> ----- Original Message ----- From: "Jim Miller" <millerjv at gmail.com>
>>> To: "Gaëtan Lehmann" <gaetan.lehmann at jouy.inra.fr>
>>> Cc: "Richard Beare" <Richard.Beare at ieee.org>; "Christian Werner" <christian.werner at rwth-aachen.de
>>>> ; "Neal R. Harvey" <harve at lanl.gov>; "LassiPaavolainen" <lassi.paavolainen at jyu.fi
>>>> ; "Julien Michel" <julien.michel at c-s.fr>; "David Pastor" <david.pastor at die.upm.es
>>>> ; "Blezek, Daniel J., Ph.D." <Blezek.Daniel at mayo.edu>; "kien  
>>>> kieu" <kkieu at jouy.inra.fr
>>>> ; "Pierre Adenot" <pierre.adenot at jouy.inra.fr>; "Mario Ceresa" <mrceresa at gmail.com
>>>> ; "Luis Ibanez" <luis.ibanez at kitware.com>; "ITK Users" <insight-users at itk.org
>>>> ; "ITK Developers" <insight-developers at itk.org>
>>> Sent: Tuesday, September 28, 2010 1:01 AM
>>> Subject: Re: LabelObject attributes
>>>
>>>
>>> Gaetan,
>>>
>>> In general, I think the original names are good.
>>>
>>> I was trying to use Roundness but had robustness issues which I
>>> traced to issues in the perimeter calculation. I wrote my own filter
>>> which overwrite the Roundness parameter with the something like the
>>> ellipsoid maximum radius divided by the feret diameter (or something
>>> like that, I don't have the code in front of me).
>>>
>>> This brings up two points.
>>>
>>> 1. There could be lots of ways to define roundness so we may want to
>>> add a few others.
>>>
>>> 2. It would great if users could define their own parameters. Maybe
>>> a general key/value pair mechanism or a set of User1, User2,
>>> User3, ... for each of scalars, vectors, matrices, etc.
>>>
>>>
>>>
>>> On Sep 27, 2010, at 7:26 AM, Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr
>>>> wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> I think you are active users of the contribution "Label object
>>>> representation and manipulation", so I'd like to get your opinion
>>>> on the attribute and on the attribute names used in that code. I
>>>> know that some of us may not be pleased to change the attribute or
>>>> their name, but I believe this is a important to make the usage of
>>>> this contribution more intuitive. This contribution should soon be
>>>> moved out of the Review directory and its API would then be much
>>>> more difficult to change.
>>>>
>>>> So at this time we have two set of attributes splited in two main
>>>> classes:
>>>> * ShapeLabelObject, which stores the attributes computable only
>>>> with the mask of the object;
>>>> * StatisticsLabelObject, which stores the attributes computable
>>>> with the intensities from another image in addition to the mask of
>>>> the object.
>>>> StatisticsLabelObject is a subclass of ShapeLabelObject, mostly for
>>>> practical reason: it is easier to use that way, and the
>>>> informations needed to compute the attributes of ShapeLabelObject
>>>> are required (but not suffisant) to compute the attributes of
>>>> StatisticsLabelObject, so I don't think there is any problem in
>>>> doing that.
>>>>
>>>> Here is the list of attributes available in ShapeLabelObject, with
>>>> some comments:
>>>>
>>>> * Size
>>>>
>>>> While "Size" is short, it is also quite ambiguous, as the term
>>>> "size" can represent many measurements. Also, in ITK, GetSize()
>>>> tends to return an object of type itk::Size<X>, while here it is an
>>>> integer. What would you think of NumberOfPixels, as it is in
>>>> itk::ImageRegion?
>>>>
>>>> * PhysicalSize
>>>>
>>>> this one is a bit redundant with the previous one, because it is
>>>> simply Size * voxelSize, but it is quite useful anyway so I think
>>>> it's worth to keep it.
>>>> As above, size is quite ambiguous. Volume may be a better name,
>>>> but is less meaningful in the 2D case. Any opinion?
>>>>
>>>> * RegionElongation
>>>>
>>>> this one may not be really useful. It is there mostly for
>>>> historical reason: it was better than nothing at the time when the
>>>> equivalent ellipsoid wasn't computed. I propose to remove it.
>>>>
>>>> * SizeRegionRatio
>>>>
>>>> I never use this one either - again, it is there more for
>>>> historical reason than for a real interest. I also propose to
>>>> remove it.
>>>>
>>>> * Centroid
>>>>
>>>> seems ok to me
>>>>
>>>> * Region
>>>>
>>>> This name is especially badly chosen: Region is the type of the
>>>> attribute and its name should be BoundingBox in my opinion.
>>>>
>>>> * SizeOnBorder
>>>>
>>>> still this Size problem - may be NumberOfPixelsOnBorder
>>>>
>>>> * PhysicalSizeOnBorder
>>>>
>>>> This one is not exactly the previous one, because it gives (for a
>>>> 3D image) the surface on the border while the other gives the
>>>> number of pixels on the border - there is a difference in the
>>>> corner of the image!
>>>> It's name is not consistent with the name used for the surface. I
>>>> think it should rather be PerimeterOnBorder, or SurfaceOnBorder
>>>> (see discussion about the Perimeter attribute).
>>>>
>>>> * FeretDiameter
>>>>
>>>> seems ok to me
>>>>
>>>> * BinaryPrincipalMoments
>>>>
>>>> The Binary prefix doesn't make much sense here. I think it should
>>>> be removed.
>>>>
>>>> * BinaryPrincipalAxes
>>>>
>>>> The Binary prefix doesn't make much sense here. I think it should
>>>> be removed.
>>>>
>>>> * BinaryElongation
>>>>
>>>> The Binary prefix doesn't make much sense here. I think it should
>>>> be removed.
>>>>
>>>> * Perimeter
>>>>
>>>> seems ok to me, but correspond better for a 2D object. Surface
>>>> would be better in 3D and more, but would be quite confusing in the
>>>> 2D case. Any opinion?
>>>>
>>>> * Roundness
>>>>
>>>> seems ok to me
>>>>
>>>> * EquivalentRadius
>>>> * EquivalentPerimeter
>>>>
>>>> These should be EquivalentSphericalRadius and
>>>> EquivalentSphericalRadius in 3D, but those names doesn't fit well
>>>> in 2d. Any better idea?
>>>>
>>>> * EquivalentEllipsoidSize
>>>>
>>>> EquivalentEllipsoidalDiameter seems better
>>>>
>>>> * BinaryFlatness
>>>>
>>>> The Binary prefix doesn't make much sense here. I think it should
>>>> be removed.
>>>>
>>>> Also I think that a few attributes are missing there - some can be
>>>> easily implemented, others may be more difficult and shouldn't be
>>>> part of the attribute rework:
>>>>
>>>> * PerimeterOnBorderRatio, which is the perimeter touching the
>>>> border of the image divided by the perimeter of the object - very
>>>> useful to fine tune how a partially observed object is to be
>>>> removed of an image.
>>>> * Neighbors, which is the list of neighbors of an object. This one
>>>> is much harder to implement and shouldn't be part of this attribute
>>>> rework.
>>>>
>>>> So to summarize the proposed changes in ShapeLabelObject  
>>>> attributes:
>>>>
>>>> * Size                   -> NumberOfPixels
>>>> * PhysicalSize           -> Volume
>>>> * RegionElongation       -> removed
>>>> * SizeRegionRatio        -> removed
>>>> * Centroid                    (no change)
>>>> * Region                 -> BoundingBox
>>>> * SizeOnBorder           -> NumberOfPixelsOnBorder
>>>> * PhysicalSizeOnBorder   -> PerimeterOnBorder
>>>> * FeretDiameter               (no change)
>>>> * BinaryPrincipalMoments -> PrincipalMoments
>>>> * BinaryPrincipalAxes    -> PrincipalAxes
>>>> * BinaryElongation       -> Elongation
>>>> * Perimeter                   (no change)
>>>> * Roundness                   (no change)
>>>> * EquivalentRadius       -> EquivalentSphericalRadius
>>>> * EquivalentPerimeter    -> EquivalentSphericalPerimeter
>>>> * EquivalentEllipsoidSize-> EquivalentEllipsoidDiameter
>>>> * BinaryFlatness         -> Flatness
>>>> *                        -> creation of PerimeterOnBorderRatio
>>>>
>>>>
>>>> Now for StatisticsLabelObject:
>>>>
>>>> There are some overlaps with the ShapeLabelObject attributes -
>>>> especially all the attributes which can be computed as for
>>>> ShapeLabelObject, but with a weighting by the pixel in the feature
>>>> image. I propose to use the same names as in ShapeLabelObject, but
>>>> with the prefix Weighted.
>>>>
>>>> * CenterOfGravity
>>>>
>>>> ok
>>>>
>>>> * Elongation
>>>>
>>>> it conflicts with ShapeLabelObject's Elongation. I propose
>>>> WeightedElongation.
>>>>
>>>> * Flatness
>>>>
>>>> it conflicts with ShapeLabelObject's Flatness. I propose
>>>> WeightedFlatness.
>>>>
>>>> * Histogram
>>>>
>>>> seems ok to me
>>>>
>>>> * Kurtosis
>>>>
>>>> seems ok to me
>>>>
>>>> * Maximum
>>>>
>>>> seems ok to me
>>>>
>>>> * MaximumIndex
>>>>
>>>> seems ok to me
>>>>
>>>> * Mean
>>>>
>>>> seems ok to me
>>>>
>>>> * Median
>>>>
>>>> seems ok to me
>>>>
>>>> * Minimum
>>>>
>>>> seems ok to me
>>>>
>>>> * MinimumIndex
>>>>
>>>> seems ok to me
>>>>
>>>> * PrincipalAxes
>>>>
>>>> it conflicts with ShapeLabelObject's PrincipalAxes. I propose
>>>> WeightedPrincipalAxes.
>>>>
>>>> * PrincipalMoments
>>>>
>>>> it conflicts with ShapeLabelObject's PrincipalMoments. I propose
>>>> WeightedPrincipalMoments.
>>>>
>>>> * Sigma
>>>>
>>>> Should be StandardDeviation
>>>>
>>>> * Skewness
>>>>
>>>> seems ok to me
>>>>
>>>> * Sum
>>>>
>>>> seems ok to me
>>>>
>>>> * Variance
>>>>
>>>> Quite redundant with StandardDeviation - maybe it should be  
>>>> removed?
>>>>
>>>>
>>>> So to summarize the proposed changes in ShapeLabelObject  
>>>> attributes:
>>>>
>>>> * CenterOfGravity        (no change)
>>>> * Elongation        -> WeightedElongation
>>>> * Flatness          -> WeightedFlatness
>>>> * Histogram              (no change)
>>>> * Kurtosis               (no change)
>>>> * Maximum                (no change)
>>>> * MaximumIndex           (no change)
>>>> * Mean                   (no change)
>>>> * Median                 (no change)
>>>> * Minimum                (no change)
>>>> * MinimumIndex           (no change)
>>>> * PrincipalAxes     -> WeightedPrincipalAxes
>>>> * PrincipalMoments  -> WeightedPrincipalMoments
>>>> * Sigma             -> StandardDeviation
>>>> * Skewness               (no change)
>>>> * Sum                    (no change)
>>>> * Variance               (no change)
>>>>
>>>>
>>>> Finally, about the returned values.
>>>>
>>>> For the positions, a physical position is returned, as an
>>>> itk::Point, when the position can be between pixels, excepted when
>>>> position in between pixels doesn't make sense - namely in
>>>> GetMinimumIndex() and GetMaximumIndex. Index explicitly appears in
>>>> the attribute names in this last case.
>>>> Does that seem relevant?
>>>>
>>>> That's all for me - please share any concern you have about those
>>>> classes API - it may be too late later!
>>>>
>>>> Regards,
>>>>
>>>> Gaëtan
>>>>
>>>> -- 
>>>> Gaëtan Lehmann
>>>> Biologie du Développement et de la Reproduction
>>>> INRA de Jouy-en-Josas (France)
>>>> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
>>>> http://voxel.jouy.inra.fr  http://www.itk.org
>>>> http://www.mandriva.org  http://www.bepo.fr
>>>>
>>>
>>> -- 
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>>
>>>
>>
>> -- 
>> Gaëtan Lehmann
>> Biologie du Développement et de la Reproduction
>> INRA de Jouy-en-Josas (France)
>> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
>> http://voxel.jouy.inra.fr  http://www.itk.org
>> http://www.mandriva.org  http://www.bepo.fr
>>

-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.itk.org
http://www.mandriva.org  http://www.bepo.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20100929/9d4dd050/attachment-0001.pgp>