[Insight-developers] [Insight-users] Interpolation and resampling templates
Bradley Lowekamp
blowekamp at mail.nih.gov
Thu Sep 3 17:37:09 EDT 2009
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
>>
>>
More information about the Insight-developers
mailing list