[Insight-users] LabelObject attributes

[Gaëtan Lehmann]

Le 28 sept. 10 à 01:25, Richard Beare a écrit :

> Hi,

Hi Richard,

> This is always tricky.
>

sure!

> I'd argue against changing PhysicalSize to Volume, because (as you
> say) it implies a purely 3D measure. On the other hand PhysicalSize
> isn't a name you see elsewhere. It might be best to keep PhysicalSize,
> but make sure that Area and Volume are mentioned in the method
> documentation.

The justification for that are:
* peoples working on geometry seems to simply call a N-dimensional  
volume a volume
* LabelStatisticsImageFilter already use that name

I don't like "Volume" much, but I don't like much PhysicalSize either.
I guess there is just no good name.

>
> Perhaps you could use HyperSphere for the names that currently include
> Sphere, if you are worried about dimensional independence. It gets
> long winded though.
>

I was also trying to keep names relatively short, so if the Hyper part  
is not needed, I'd prefer keeping it away

>
> Perhaps GreyWeighted instead of Weighted, although that raises issues
> of spelling Grey/Gray. (Could just have both, I guess)

I've thought about IntensityWeighted also, but again I think it makes  
the name a lot longer without giving much more clue about it's  
definition.

Does it sound right for an english speaker simply with the Weighted  
prefix?

>
> The last question is whether the difference between centroid and
> centre of gravity is too subtle. Perhaps centroid and
> (Gray)WeightedCentroid?

That subject was discussed with a statistician - for him, the  
difference was quite clear and WeightedCentroid sound strange. But I  
guess our main target is not the statistician community.
Personally, I also prefer WeightedCentroid.

I may have to set up a poll to choose the right name :-)

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