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

[Luis Ibanez]

Hi Gaetan,

Please keep in mind that the current classes in the

    Insight/Code/Numerics/Statistics

will be deprecated and the suggested replacement are
the classes currently in

http://svn.na-mic.org/NAMICSandBox/trunk/ITKStatisticsPipelineRefactoring/

The main changes involve converting the majority of
the processing classes into actual ITK filters.

Details on the refactoring are described in
http://www.itk.org/Wiki/Proposals:Refactoring_Statistics_Framework_2007

If changes need to be made in this classes, this could
be a goo time for doing so.


   Please let us know,


       Thanks


           Luis



---------------------
Gaëtan Lehmann wrote:
> 
> 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
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers