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

Wed, 12 Mar 2003 21:53:39 -0600 (CST)

Luis,

Thanks for the comments.  I agree with the only use what you need 
philosphy.  I also believe that the RegisterOne mechanism should work for 
adding those less used file filters to the default file checking.  The 
method that Kent outlined requires that you know what the file type is 
before processing it, whereas RegisterOne method would allow multiple file 
IO filters to be registered, and the file type be determined automatically 
at runtime.

Another question about the CanRead functionality that I was concerned 
with.  What should the itk::PNGImageIO::CanRead() function return if the 
filename is "test.png", but the file does not even exist?  or if it exists 
but the user does not have read permission?

Thanks,
Hans

On Wed, 12 Mar 2003, Luis Ibanez wrote:

> 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
> > 
> 
> 
> 
> 