[Insight-users] LabelObject attributes

Christian Werner christian.werner at rwth-aachen.de
Tue Sep 28 06:45:07 EDT 2010


   Hi there!

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".

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".

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.

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. ;)

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
>>
>



More information about the Insight-users mailing list