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

[Emmanuel Christophe]

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