[Insight-users] LabelObject attributes
Gaëtan Lehmann
gaetan.lehmann at jouy.inra.fr
Wed Sep 29 11:33:42 EDT 2010
Le 29 sept. 10 à 14:37, Christian Werner a écrit :
> 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").
Pixel is used everywhere in ITK independently of the image dimension,
so I guess it's ok to use it there :-)
>
> 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
>
--
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/pipermail/insight-users/attachments/20100929/b4f2c238/attachment-0001.pgp>
More information about the Insight-users
mailing list