[Insight-developers] [Insight-users] LabelObject attributes

Gaëtan Lehmann gaetan.lehmann at jouy.inra.fr
Wed Sep 29 06:34:03 EDT 2010


Le 28 sept. 10 à 12:45, Christian Werner a écrit :

>  Hi there!
>

Hi Christian,

> I agree about the Volume issue. Why don't just keep "Physical Size".  
> It's a more general term, but still very intuitive. If you have a 3d  
> object, the first plausible interpretation of "Size" would be  
> "Volume", and for a 2d object "Area".

Do you think there would be a consistency problem if Size is renamed  
NumberOfPixels and PhysicalSize stays PhysicalSize?

>
> Furthermore, I am a big fan of the Weighted prefix. It is quite  
> short and very intuitive in my opinion. It shows up when you are  
> working with a Feature Image, which, in addition to the objects'  
> shape, holds information about the "brightness" or "weight" of each  
> element. The concerned elements' values are one-dimensional, so  
> there isn't much room for interpreting the term "weight".

Great

>
> I didn't instantly understand the difference between Centroid and  
> Center Of Gravity either. But a short glimpse at wikipedia reminded  
> me. I think it is not asked too much for a user to make himself  
> familiar with the correct terminology when doing geometrical  
> analysis on some data. Making up new terms won't help here in my  
> opinion.

I've used Centroid and CenterOfGravity because the definition seems to  
fit, but I'm not sure CenterOfGravity is the right name - one  
shouldn't have to look at the definition to have a good idea of what  
is this attribute IMO.
What do you think of WeightedCentroid?

>
> Considering the roundness we could start collecting all different  
> interpretations and then think about how we call them. I start with  
> the current one (is it?)
>
> Roundness = Perimeter of Hypersphere with same Size / Perimeter of  
> Object
>
> which is a value between 0 and 1. I find that very useful, as long  
> as the perimeter is calculated correctly. ;)

Yes, still that problem. Hopefully, it will eventually be fixed :-)

Gaëtan

>
> Best regards,
> Christian
>
>
>
> Am 28.09.2010 10:46, schrieb David Pastor:
>> Hello,
>>
>> - 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).
>>
>> - 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 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. Anyway I find very interesting the  
>> CenterOfGravitiy and I imagine that "sum" stands for the intensity  
>> accumuled in the object region?
>>
>> A more general suggestion is to be able to specify the structuring  
>> element used to find the connectivity of the label objects or being  
>> able to perform a wider range of attribute openings/closings  
>> (generalization of area opening contribution and object tree  
>> contribution).
>>
>> thanks for the useful contributions
>>
>> 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
>>>
>>
>
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users

-- 
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/e22fcb0a/attachment.pgp>


More information about the Insight-developers mailing list