[Insight-developers] New file types added to Code/IO

[Luis Ibanez]

Hi Hans,

You are right,

The ImageIO classes doesn't actually have to use the file
extension. What they exactly have to do is to make sure
that they are qualified for reading this file.

The goal of the "CanReadFile()" method is to return true
when the ImageIO is absolutely sure that this is a file
it can process.

The risk to avoid, is to say that it can read the file,
but later during the actual read process, discover that
the file was not of the correct type.

So, you are right when you say that these new readers
just have to be more sofisticated.  Note however that
every try of a reader take some time in the processing.

As we add more and more readers this means that if your
file format happens to be the one associated with the last
register reader, maybe 10 or more other (non-qualified)
readers will give it a try to your file. Rejecting files
based on their extension is a very efficient (fast)
way of passing the token to the next ImageIO.

You certainly don't want to go through the whole file
in order to determine if it can be read...

--

Registering ImageIOfactories by default serves the
purpose of convenience for very commonly used file
formats.

If you find that the sophistication of the reader
cames at the price of lengtly processing time, it may
not be a good idea to add it to the list of default
readers.

You can alwasy register the factory in the code of
your particular applications. It only requires one
line of code. So, when you design an application
that will be run in a hospital where you actually
have these GE scanners, it is worth to register
these factories by default.

It very likely that the list of file formats will
continue growing... and we may want to keep the
C-Language philosophy of:

    "You only pay for what you use"



Luis


-----------------------------------------
Hans Johnson wrote:
> Luis and Kent,
> 
> The old problem with the analyze image was that the CanRead function was 
> always returning true.  It is my understanding that the the file does not 
> have to have an extension, it is just that most file readers use the 
> extension to determine if it can read a file.  The CanRead function of the 
> GE IO filters will just have to be more sophisticated.
> 
> Luis:  Am a missing something in that expanation?
> 
> Regards,
> Hans
> 
> 
> On Wed, 12 Mar 2003, Luis Ibanez wrote:
> 
> 
>>Hi Kent,
>>
>>If the files do not have any specific extension
>>we will not be able to pre-register their ImageIO
>>factories.
>>
>>However the mechanism that you described is perfectly
>>valid. Just setting explicitly the ImageIO object
>>when the user is certain of the image type.
>>
>>Without extension selectivity they cannot be in
>>the factory since they may end up accepting files
>>intended for other readers. Like it was happening
>>some time ago with Analyze.
>>
>>-
>>
>>It's great to see the family of ImageIO
>>objects growing !
>>
>>
>>Luis
>>
>>
>>---------------------------
>>Kent Williams wrote:
>>
>>>I've checked in some new Image File formats, each of which reads (but does not 
>>>write) files generated by GE brand MR scanners:  GE4ImageIO, GE5ImageIO and 
>>>GEAdwImageIO.
>>>
>>>None of these file types have any associated file name extension, which means
>>>it would be problematic to automatically register the file types. Each of them 
>>>has a header-probing heuristic test, but unless someone thinks its a good 
>>>idea to add them to the automatically registered file types, I'll hold off.
>>>
>>>The following magic incantation works to open them.
>>>
>>>typedef itk::Image<signed short, 3> ImageType ;
>>>typedef ImageType::Pointer ImagePointer ;
>>>typedef itk::ImageFileReader< ImageType > ImageReaderType ;
>>>itk::GEAdwImageIO::Pointer io = itk::GEAdwImageIO::New();
>>>ImageReaderType::Pointer imageReader = ImageReaderType::New() ;
>>>imageReader->SetImageIO(io);
>>>imageReader->SetFileName(inputFileName) ;
>>>
>>>I haven't checked in any automated tests; I'm going to have to create 
>>>synthetic test data files, since up until now the ONLY way these files were 
>>>created was by their respective scanners, and those files are way too big.
>>>In the mean time if you have any files from those scanners, please tell me if 
>>>you have problems loading them.
>>>
>>>I have a very simple test program that will read in one of these scanner files 
>>>and write it out to the ITK-supported file format of your choice if this 
>>>would aid in your testing. Drop me a line if you'd like a copy.
>>>
>>>
>>>_______________________________________________
>>>Insight-developers mailing list
>>>Insight-developers@public.kitware.com
>>>http://public.kitware.com/mailman/listinfo/insight-developers
>>>
>>
>>
>>
>>
>>_______________________________________________
>>Insight-developers mailing list
>>Insight-developers@public.kitware.com
>>http://public.kitware.com/mailman/listinfo/insight-developers
>>
> 
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>