[Insight-users] LabelObject attributes

[Gaëtan Lehmann]

Le 29 sept. 10 à 09:26, Lassi Paavolainen a écrit :

> Hi,
>

Hi Lassi,

> Here are my opinions with short explanations:
>
> Size: NumberOfPixels sounds better to me as it is about number of  
> pixels not so much about size.
>
> PhysicalSize: This sounds good to me as it can be calculated for xD  
> objects.
>
> Is it confusing if other is changed to NumberOfPixels and other  
> still has size on it? To me its not, but maybe for someone it is.
>
> I also vote removing Binary from the names where its used and  
> changing Region to BoundingBox sounds good to me.
>
> I also vote for adding Weighted to attributes of  
> StatisticsLabelObject where those conflict with ShapeLabelObject.
>

ok, thanks for the previous comments!

> About possible new attributes. How would you define neighbors list?  
> Would that be all objects that are touching current object

I was thinking at this one. Neighbors are label objects touching the  
label object of interest.

> or that are in some distance from the object?

While certainly useful, it wouldn't have the same computation  
efficiency!

> I think there can be problems for defining this in a way its usable  
> to many, so I am with you Gaëtan that it is not needed for this  
> rework.

sure, this one is not for now

>
> Then some other things. Some cases I get roundness value higher than  
> 1 which shouldn't be possible. Reason seems to be wrongly calculated  
> perimeter. I think someone else also reported this.

Yes, still this Perimeter computation problem.
It will be fixed, eventually :-)

>
> Other problem I've had is with background label object. If I  
> remember correctly, statistics of background label object aren't  
> available. Shape attributes aren't most likely needed, but  
> statistics attributes like mean of background label object is  
> something that could be useful.

Computing that value would be quite difficult because there is no  
information about where is the background stored in LabelMap and  
LabelObject. All what we know is where it is not, so to find the  
background, we have to look at all the label object in the label map  
and exclude all their pixel from the background. Certainly not  
something we want to do at every attribute computation!

Gaëtan

>
> Best regards,
> Lassi
>
> On Mon, 27 Sep 2010, Gaëtan Lehmann 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

-------------- 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/f64adef3/attachment.pgp>