[Insight-users] ImageFileWriter and ImageAdaptor

[Luis Ibanez]

Hi Hauke,

This is a known problem.... without known solution.

The issue is that ImageFileWriters access the buffer pointer of
the input images directly.

While the ImageAdaptors act through a trick in the PixelAccessor
of ImageIterators. The trick is useless for classes that do not
use image iterators in order to access the image data, such as
the case of the ImageFileWriter.


One option is to use the CastImageFilter but
it will cost you an extra copy of the image... that's the drawback.

In your case, that amount of memory seems to be excesive...



---

 From the description of your problem, it seem that you are
just reading a DICOM series into a volume, casting the pixel
type and then writing the volume down.

If that's the case then you can simply skip the casting and
instead instantiate the ImageSeriesReader using the *output*
type that you need.

ITK readers perform casting automatically from the pixel type
of the image file to the pixel type of your reader.

For example, if right now you are doing

    ImageSeriesReader< Image< char, 3 > >
    cast from char to float
    ImageFileWRiter< Image< float, 3 > >

Then you can simply replace it with:

    ImageSeriesReader< Image< float, 3 > >
    ImageFileWRiter<   Image< float, 3 > >


If you still find problems, please let us know more
details about your image size and the pixel types
that you are converting from and to.



   Regards,


        Luis


-------------------
Hauke Heibel wrote:
> Hello there,
> 
>  
> 
> I just tried to use the ImageFileWriter in combination with an 
> ImageAdaptor that does nothing else but to cast data. Unfortunately it 
> is not working, since the ImageFileWriter is working on the raw buffer 
> by calling (ll. 278-279 itkImageFileWriter.cxx)
> 
>  
> 
> const void* dataPtr = (const void*) input->GetBufferPointer();
> 
> m_ImageIO->Write(dataPtr);
> 
>  
> 
> On the first glance it may seem to be weird to do such a thing (I mean 
> using the adaptor), since one might argue that I could simply tell my 
> ImageFileWriter that I am going to write images of an appropriate type 
> making casting not required.
> 
>  
> 
> Actually my setup is a little bit problematic. My general task lies in 
> converting DICOM files. I switched to the ImageAdaptor, since my source 
> image consumes already 1.1 GB in memory (I just read a DICOM file, 
> unsigned short) and if I wanted to convert it to another image type, I 
> would be required to allocate another 1.1 GB (e.g. for signed short). As 
> many of you may know Windows does not give us (without some nasty hacks) 
> more than 2 GB of memory – and here is the reason why I switched to 
> ImageAdaptors. The one I used (a similar one to that presented in the 
> Software Guide) just casts the data.
> 
>  
> 
> Actually GDCM already fails, if used in combination with the 
> itkImageSeriesFileReader in cases where the DICOM has a different format 
> than the image request within ITK and when on top of all things the 
> DICOM is bigger than 1GB.
> 
>  
> 
> The only solution I can think about for now is to do  some in-place 
> casting and then using the in-place converted buffer via the 
> itkImportImageFilter. This sounds really nasty and will only work if my 
> source and destination data types have the same sizes.
> 
>  
> 
> I am now wondering if anybody can be of help with this issue? It would 
> be much appreciated.
> 
>  
> 
> Regards,
> 
> Hauke
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users