[Insight-users] LabelObject attributes

Christian Werner christian.werner at rwth-aachen.de
Wed Sep 29 08:29:36 EDT 2010


  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
>



More information about the Insight-users mailing list