[Insight-users] LabelObject attributes
Christian Werner
christian.werner at rwth-aachen.de
Wed Sep 29 08:37:06 EDT 2010
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").
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
More information about the Insight-users
mailing list