[Insight-users] 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/pipermail/insight-users/attachments/20100929/72d15e55/attachment.pgp>


More information about the Insight-users mailing list