[Insight-developers] Fwd: LabelObject attributes
Gaëtan Lehmann
gaetan.lehmann at jouy.inra.fr
Wed Sep 29 05:39:53 EDT 2010
There were too much recipients for the mailing lists, so I'm resending
this message (sorry for the duplicates).
Gaëtan
Début du message réexpédié :
> De : Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>
> Date : 27 septembre 2010 13:26:06 GMT+02:00
>
> 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
>
--
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/72d15e55/attachment.pgp>
More information about the Insight-developers
mailing list