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

[Emmanuel Christophe]

Hi,
If you use something like:
local::IsSafelyCastable<InternalType, ExternalType>::Result
instead of
local::IsSameType<InternalType, ExternalType>::Result

wouldn't you need to specialize only this part?

Emmanuel


2009/9/4 Bradley Lowekamp <blowekamp at mail.nih.gov>:
> Hello,
>
> I am working on something along the following:
>
> template <class TInternalType, class TExternalType >
> class BoundedCastPixelAccessor
> {
> public:
>  /** External typedef. It defines the external aspect
>   * that this class will exhibit. */
>  typedef TExternalType ExternalType;
>
>  /** Internal typedef. It defines the internal true
>   * representation of data. */
>  typedef TInternalType InternalType;
>
>  static inline void Set(InternalType & output, const ExternalType & input)
>  {
>    if ( local::IsSameType<InternalType, ExternalType>::Result )
>      {
>      output = static_cast< ExternalType > ( input );
>      }
>    else
>      {
>      const InternalType minInternalValue =  itk::NumericTraits<InternalType
>>::NonpositiveMin();
>      const InternalType maxInternalValue =  itk::NumericTraits<InternalType
>>::max();
>
>      const ExternalType minExternalValue =
> static_cast<ExternalType>(minInternalValue);
>      const ExternalType maxExternalValue =
> static_cast<ExternalType>(maxInternalValue);
>
>      output = input < minExternalValue ? minInternalValue :
>        ( input > maxExternalValue ? maxInternalValue :
> static_cast<InternalType>(input) );
>
>      }
>  }
>
> // Get methods todo
> };
>
> The filter in question could internally use and adaptor for it's output to
> perform this operation. Something with the following type:
>
> ImageAdaptor<TImage, Accessor::BoundedCastPixelAccessor< typename
> TImage::PixelType, TOutputPixelType>   >;
>
> I still need to figure out a good way to specialize it though...
>
> Brad
>
>
> On Sep 3, 2009, at 3:53 AM, Emmanuel Christophe wrote:
>
>> Hi Brad,
>>
>> To make sure that I understand what you suggest, you propose a method
>> where the general form would be something like that:
>>
>> template<class InType, class OutType> OutType castSafely(InType value)
>> {
>>  const OutType minValue =  itk::NumericTraits<OutType >::NonpositiveMin();
>>  const OutType maxValue =  itk::NumericTraits<OutType >::max();
>>
>>  const InType minOutputValue = static_cast<InType>(minValue);
>>  const InType maxOutputValue = static_cast<InType>(maxValue);
>>
>>  return value<minValue?minValue:(value>maxValue?maxValue:value);
>> }
>>
>> To be called as:
>>  double  valueDouble = -256.1;
>>  unsigned char valueUChar = (unsigned char) valueDouble;
>>  std::cout << "Double: " << valueDouble << std::endl;
>>  std::cout << "UChar: " << (int)valueUChar << std::endl;
>>  std::cout << "castSafely: " << (int)castSafely<double, unsigned
>> char>(valueDouble) << std::endl;
>>
>> Is that correct ?
>>
>> Then the method would be specialized for some other type (std::complex
>> for example) where the operator < is not available. And/or for cases
>> where the conversion is not required.
>>
>> Correct me if I'm wrong, but to facilitate the partial specialization,
>> would it be easier to have a method signature such as
>> castSafely(InType value, OutType dummy) ?
>>
>>
>> Emmanuel
>>
>>
>> 2009/9/2 Bradley Lowekamp <blowekamp at mail.nih.gov>:
>>>
>>> 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
>>>
>>>
>
>