[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