[Insight-developers] output image type in HistogramTo???ImageFilter

[Gaëtan Lehmann]

Le 11 janv. 09 à 16:26, Karthik Krishnan a écrit :

> Gaëtan Lehmann wrote:
>>
>> Dear developers,
>>
>> The filters HistogramTo???ImageFilter produce an image with a  
>> predefined pixel type:
> Gaetan:
>
> I wrote these filters to be able to examine the changes in the joint  
> distribution of the Mutual information metrics during registration.  
> Its a natural way to observe the suitability of the optimizer by  
> observing the joint probabilities or the entropy or the histogram  
> itself as a stack of images (one per iteration).
>> - HistogramToProbabilityImageFilter    -> double (even if the  
>> documentation says its float)
> Really ? I don't see how. Are you referring to  
> HistogramToProbabilityImageFilter (or HistogramToEntropyImageFilter,  
> which is missing from this list). I thought it might have to do with  
> the change in precision in the densefrequencycontainer from float to  
> double a few years ago, but it casts the result anyway.

My mistake: I made a wron copy/paste, and thus a mistake while reading  
the doc :-/
This one should be HistogramToEntropyImageFilter and produce an image  
with a double pixel type, as documented

>
>> - HistogramToIntensityImageFilter      -> unsigned long
>> - HistogramToLogProbabilityImageFilter -> double
>> - HistogramToProbabilityImageFilter    -> float
>>
>> The predefined types doesn't fit well in wrapitk, because those  
>> types may not be available, so I'd like to add a template parameter  
>> for the output pixel type to those filters.
> We'd like to minimze the number of options needlessly exposed to the  
> user. Its hard for a naive user to divine the right template  
> parameters.
>
> For a probability distribution (HistrogramTo Probability/ 
> LogProbability/Entropy), it makes no sense to wrap any type other  
> than double or float. The probability image is guaranteed to be an  
> image between 0 and 1 and for the mattes metric, it will be an image  
> with several pixels very close to 0..
>
> Similarly for the HistrogramToIntensityImageFilter, it writes the  
> actual value in each bin, which is guaranteed to be an integer (the  
> actual precision is represented as unsigned long in the dense  
> frequency container) and hence unsigned long.
>> Any comment/objection?
> So maybe we should not have them wrapped in every possible datatype,  
> since clearly they would yield bogus results in most datatypes other  
> than those provided.

HistogramToIntensityImageFilter is not a problem, because itk::Image<  
unsigned long, dim > is always available.

The problem comes from the three other ones, because itk::Image<  
float, dim > or itk::Image< double, dim > may not be available,  
depending on the options selected by the user at build time. The  
template parameter I want to add would let us choose which pixel type  
we want to use for the output image: float or double. I never wanted  
to wrap all the possible pixel types - sorry if my previous mail let  
you think that.

Also, the pixel type would have a default type - double for  
HistogramToEntropyImageFilter and  
HistogramToLogProbabilityImageFilter, and float for  
HistogramToProbabilityImageFilter - so the user doesn't have to think  
to the right type to use - if he's not sure, he just use the default  
one.
That default pixel type would also preserve backward compatibility.

Regards,

Gaëtan


>
>
> Thanks
> --
> karthik
>>
>> Regards,
>>
>> Gaëtan
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>
> -- 
> Karthik Krishnan
> R & D Engineer,
> Kitware Inc,
> Ph:  518 371 3971 x119
> Fax: 518 371 3971
>

-- 
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.mandriva.org
http://www.itk.org  http://www.clavier-dvorak.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090111/ce060a69/attachment.pgp>