[Insight-users] LabelObject attributes

Gaëtan Lehmann gaetan.lehmann at jouy.inra.fr
Wed Sep 29 11:33:42 EDT 2010


Le 29 sept. 10 à 14:37, Christian Werner a écrit :

> Sorry for my multiposting. NumberOfPixels is great for 2D, but  
> doesn't fit in 3D anymore... :) So maybe you could call it  
> NumberOfElements. At least the word "Element" is part of both terms  
> (Pixel="Picture Element", Voxel="Volume Element").

Pixel is used everywhere in ITK independently of the image dimension,  
so I guess it's ok to use it there :-)

>
> Best regards,
> Christian
>
>
> Am 29.09.2010 14:29, schrieb Christian Werner:
>> NumberOfPixels and PhysicalSize are a very good choice in my opinion!
>>
>> Best regards,
>> Christian
>>
>>
>> Am 29.09.2010 12:34, schrieb Gaëtan Lehmann:
>>>
>>> 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
>>>
>>
>> _____________________________________
>> 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/pipermail/insight-users/attachments/20100929/b4f2c238/attachment-0001.pgp>


More information about the Insight-users mailing list