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

[Karthik Krishnan]

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.
> - 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.

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