[Insight-users] VTKImageIO : ASCII vs Binary data.

[Luis Ibanez]

Hi Mathieu,

Thanks for pointing this out.


The example ImageReadWrite is probably not reading
your VTK binary image correctly.

There seems to be a problem in the itkVTKImageIO
reader that prevents it from recognizing binary
data. This should be easy to fix. It looks like
the reader is not taking into account the tag for
Binary/ASCII data in the VTK image file.

---

On the other hand, for writing, there is a method
in the ImageIOBase class that allows to define if
you want to write in binary or ascii.

Since we are relying on the factory mechanism
for finding the apropriate ImageIO object based
only on the file extension (in this case,
itkVTKImageIO is pull out of the hat when you
provide a file with .vtk extension).  This
prevent us from having access to the ImageIO
options.

The solution is simply  to instantiate explicitly
the ImageIO object, set its options and then pass
it to the ImageFileWriter.


This could look like


itk::VTKImageIO::Pointer vtkIO =
                    itk::VTKImageIO::New();

itk::ImageFileWriter< ImageType > WriterType;

WriterType::Pointer writer = WriterType::New();

vtkIO->SetFileTypeToBinary(); // <<==== Here !!

writer->SetImageIO( vtkIO );

writer->SetInput( filter->GetOutput() );
writer->SetFileName( filename );
writer->Update();



We are looking for a fix in the reading side.

Please let us know if you find any other problem,



  Thanks


    Luis



---------------------------------

Mathieu Malaterre wrote:

> Luis,
>    As you told me I have done some change in ImageReadWrite so that it 
> can handle 3 dim data. Now as I told you I have to file ascii.vtk and 
> bin.vtk which are exactly the same if you use python+vtk. One is 
> structured points binary and the other ascii.
>   I used ImageReadWrite to generate some mha file:
> 
> ImageReadWrite ascii.vtk ascii.mha
> ImageReadWrite bin.vtk bin.mha
> 
> If I diff bin.mha and ascii.mha they are the same (except 
> ElementDataFile of course)
> I have download hexdiff on the internet to diff the raw file. And I find 
> somthing very weird. There is something like a shift (Little /big endian 
> related stuff ?) in the file (have a look at line 80 and following):
>