[Insight-developers] [Insight-users] Interpolation and resampling templates

[Bradley Lowekamp]

Hello Emmanuel,

	I am pondering about this.... I have not finished yet.

If I recall correctly, your initial solution viewed this as a problem  
which needed clamping methods. I am not sure that this the only way to  
look at this.

Consider the purpose for clamping in this case. It is to safely  
convert from one pixel type to another with out overflow. I am  
pondering what an Image adaptor to accomplish this would look like.  
The advantage to this is that certain conversion don't need to verify  
the range... but I am not sure how many would be useful in this case.  
But with out partial template specialization this could be a lot of  
work.

I am really surprised there is not an exiting solution to convert with  
out overflow.

Brad

On Sep 1, 2009, at 2:07 AM, Emmanuel Christophe wrote:

> Hi all,
> I'm coming back on this issue. Since that time, I opened a bug on ITK
> mantis to be able to follow:
> http://www.vtk.org/Bug/view.php?id=9243
>
> We've been using the patch I submitted in the ITK version we include
> in OTB (www.orfeo-toolbox.org) for a while, but it would make more
> sense to integrate it in ITK (this would enable the OTB users to use
> their own external version of ITK, that would greatly easy the process
> of updating the internal ITK, etc).
>
> I'm ready to rework the patch to avoid modifying the NumericTraits. I
> agree with Brad statement that the function is misplaced. However, I
> don't know what would be the best way to replace the operation
> sequence
>
>        if( value < minOutputValue )
>          {
>          pixval = minValue;
>          }
>        else if( value > maxOutputValue )
>          {
>          pixval = maxValue;
>          }
>        else
>          {
>          pixval = static_cast<PixelType>( value );
>          }
> (see l346-359 of Code/Review/itkOptResampleImageFilter.txx but also in
> 4 other places at lines 410, 474, 689 and 730 and in file
> Code/BasicFilters/itkResampleImageFilter.txx at line 284 and 463).
>
> The idea would be to make this sequence valid for std::complex as
> well. Once the template are sorted out between the type of the value
> and the type of the coordinates (the first part of the patch), these
> operations are the only thing that prevent a correct usage of the
> registration framework on complex data.
>
> Let me know what you think,
> Emmanuel
>
>
>
> 2009/3/6 Bradley Lowekamp <blowekamp at mail.nih.gov>:
>>
>> On Mar 6, 2009, at 8:29 AM, Karthik Krishnan wrote:
>>
>> On Fri, Mar 6, 2009 at 2:13 AM, Emmanuel Christophe
>> <emmanuel.christophe at gmail.com> wrote:
>>>
>>> Hi Karthik, Brad,
>>>
>>>
>>> - Not sure if NumericTraits is the best place for the Clamp  
>>> function.
>>> I put it there as it is closely related to the type and in the  
>>> case of
>>> the itk::ResampleImageFilter is used as a precaution before a
>>> static_cast. I haven't defined it for Vectors, RGB etc.
>>
>> Thanks for the patch.
>>
>> I think its  good to define it for all pixel types for which it  
>> makes sense.
>>
>> I am not disagreeing with the usefulness of the clamp function. I  
>> just
>> disagreeing with the adhoc adding of a function to the  
>> NumericTraits class.
>> Clamp is not a trait is a function which is rather different then  
>> how this
>> class is currently designed.
>> If we did want to add a set of functions it would be great and useful
>> (where?). I would think that Min, Max and LERP should be  
>> considered. I just
>> think some consideration should be made to what it means to all  
>> pixel types.
>> And they need to be made consistent across all traits where  
>> appropriate. The
>> NumericTraits class is a little bit of a pet peeve of mine. I think  
>> is needs
>> a more design and documentation to flush things out between  
>> everything, and
>> some careful review. :)
>>
>>
>>
>>> - I don't think the itk::ResampleImageFilter was able to resample  
>>> RGB
>>> images. At one point it would have tried to compare two RGBPixel  
>>> using <.
>>
>> Right. One would have to use the VectorResampleImageFilter.
>>
>> Yes, this is how I have done it. Sorry for my confusion. RGBPixel  
>> type does
>> in fact have a operator<, but the meaning and usefulness is  
>> debatable.
>> Sorry for being difficult on this subject :)
>> Brad
>>
>>

========================================================
Bradley Lowekamp
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine
blowekamp at mail.nih.gov


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090902/65808059/attachment.htm>