[Insight-developers] Re: design problem with VectorImage and ImageAdaptor ?

[Karthik Krishnan]

On Wed, 2006-03-08 at 11:24 +0100, Gaetan Lehmann wrote:
> On Wed, 08 Mar 2006 00:40:47 +0100, Karthik Krishnan  
> <Karthik.Krishnan at kitware.com> wrote:
> 
> >
> >
> > Gaetan Lehmann wrote:
> >
> >>
> >>> Is it fixed with this fix ?
> >>> http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Common/itkVectorImageToImageAda
> >>> ptor.h?root=Insight&r1=1.7&r2=1.8
> >>>
> >>>
> >>
> >> Yes, it builds, with  typedef typename TImage::InternalPixelType  
> >> InternalPixelType;
> >>
> >> in itkImageAdaptor.h, instead of  typedef typename  
> >> TAccessor::InternalType InternalPixelType;
> >>
> >>
> >>
> > That would not work. The typedefs are not equivalent. The former is type  
> > T. The latter is VariableLengthVector< T >
> 
> That's exactly why I have done this change, and at least, it builds now  
> for the adaptor, and I can't see how that change can prevent the build of  
> the ImageFileReader.

Because the Reader is being instantiated over the wrong types. Its a
good thing that there is a compiler error because the change is not
correct. The 'ConvertPixelTraits' class converts pixel buffers from
pixel representation in the file to the pixel type specified in its
template argument. For instance DefaultConvertPixelTraits< RGBPixel >
would read bytes from a file and spew out RGBPixel's.
  To a user of the VectorImage class it exhibits the behaviour of Image<
VariableLengthVector< T > >, however the internal pixel representation
is still of type T. (so in some ways the image behaves like an adaptor).
This means that the ConvertPixelTraits for this class must be
instantiated over type T. as in DefautlConvertPixelTraits< T > not 
DefaultConvertPixelTraits< VariableLengthVector< T > >.
So the compiler was right in throwing the error below.

/usr/include/InsightToolkit/IO/itkImageFileReader.txx:433:
instantiated from 
'void itk::ImageFileReader<TOutputImage, 
ConvertPixelTraits>::DoConvertBuffer(void*, long unsigned int) [with 
TOutputImage = itk::VectorImage<unsigned char, 3u>, ConvertPixelTraits
= 
itk::DefaultConvertPixelTraits<itk::VariableLengthVector<unsigned char>
>]'

/usr/include/InsightToolkit/IO/itkImageFileReader.txx:347:
instantiated from 
'void itk::ImageFileReader<TOutputImage,
ConvertPixelTraits>::GenerateData() 
[with TOutputImage = itk::VectorImage<unsigned char, 3u>,
ConvertPixelTraits 
= itk::DefaultConvertPixelTraits<itk::VariableLengthVector<unsigned
char> >]'





Actually the adaptor should not build either, but there are no "concept
checks" to prevent it from building :)

> >
> >> I'm using ITK 2.4.1. ITK cvs would solve that problem ?
> >>
> > ITK2-4-1 and CVS is probably in the same state for the wrappers for the  
> > VectorImageToImageAdaptor class.
> 
> So there is currently nothing to do to use wrap those class?
> Sadely in that case, that's not a wrapper problem, and it mean the code is  
> broken.
> 
> >
> >>> Not really. I was just an example. Since you've wrapped VectorImage and
> >>> VariableLengthVector, it should generally suffice.
> >>>
> >>>
> >>
> >> How do you extract a normal image from a vector image without it ?
> >>
> >>
> > Just an iterator. In fact, we've been forced to do this in most cases.
> >
> > Lines 291-315.  
> > http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Algorithms/itkBayesianClassifierImageFilter.txx?annotate=1.4&root=Insight
> >   itrPosteriorImage is an iterator on a VectorImage.
> >   extractedComponentImage is an extracted component.
> >
> > Here the intent was to smooth each component and Anisotropic diffusion  
> > filters will not work on non-scalar images. Adaptors might help save  
> > memory, but IMHO once you put them in a pipeline for a filter that works  
> > on image regions, the price you pay for non-contiguous memory access  
> > would outweigh it, (I think).
> >
> 
> iterator or still not usable with wrappers, and it does fit well with the  
> usage of VectorImage to read an image with several channels - it's just  
> not usable in a pipeline.
> I don't like too much adaptor, but it seem that the only class able to  
> extract a scalar image from a VectorImage for now.
> I guess I have to write a filter to extract the channel I'm interested in.  
> It would also avoid the efficiency problem your talking about.
> 
> A more reasonable way seem to consider that VectorImage is not ready yet,  
> and to split the channels in several files before processing images in ITK.
> I hope it will be usable soon
> 
> Gaetan
>