[Insight-developers] [Insight-users] LabelObject attributes
Gaëtan Lehmann
gaetan.lehmann at jouy.inra.fr
Wed Sep 29 06:34:03 EDT 2010
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
--
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/mailman/private/insight-developers/attachments/20100929/e22fcb0a/attachment.pgp>
More information about the Insight-developers
mailing list