[Insight-developers] [Insight-users] ITK TCon 2.0 : Agenda : ImageIO GUI Support

[Niels Dekker]

Hi Luis,

Now I see, one specific ImageIO object might support multiple file 
formats.  E.g, AnalyzeImageIO and NiftiImageIO:
http://www.itk.org/Wiki/Proposals:ImageIO_API_for_GUI_Support#Enumeration_of_Extensions

Still I think it would be preferable to distinguish between a "file 
format" and a "file extension".  For example, JPEGImageIO supports only 
one file format, although there are multiple file-extensions associated 
to that format.

So I'm still in favor of having a FileFormat class. Having two member 
functions, FileFormat::GetDescriptiveName() and 
FileFormat::GetFileExtensions().

ImageIOBase could then have a member, returning a container of supported 
file formats:
  Array<FileFormat> GetSupportedFileFormats()

It might also be useful to be able to get a list of ImageIO objects that 
support a specific file format, e.g., as a static function of 
ImageIOFactory:
  Array<ImageIOBasePointer> CreateImageIOArray(const FileFormat&);

Usually that function would return exactly one ImageIO, but some file 
formats might be supported by multiple ImageIO classes (e.g., DICOM!).

It would certainly be helpful to be able to retrieve a list of all 
supported file formats, from the ImageIOFactory:
  Array<FileFormat> GetSupportedFileFormatsForReading();
  Array<FileFormat> GetSupportedFileFormatsForWriting();

What do you think?

Anyway, it's getting late, here in Holland...

Kind regards, Niels

I wrote earlier today:

----- Original Message ----- 
From: "Niels Dekker"
To: "Luis Ibanez"
Cc: "Insight Users"; "Insight Developers"
Sent: Friday, September 12, 2008 18:18
Subject: Re: [Insight-users] ITK TCon 2.0 : Agenda : ImageIO GUI Support


Luis Ibanez wrote:
> In general the methods that we are proposing will be declared
> "virtual" at the level of the ImageIOBase class, and they will
> be overloaded in the derived ImageIO specific classes.
>
> In the case of the proposed API:
>
>     * unsigned int GetNumberOfExtensions() const;
>     * std::string GetNthExtension(unsigned int) const
>
> we were thinking only on the Write side of the GUI, since
> it is at this point that GUI users need more guidance on
> what options are available to them.
>
> But,... you have a point in that the same would be useful
> in the context of reading files.  We just added this comment
> to the proposal page.

Thanks, Luis.

www.itk.org/Wiki/Proposals:ImageIO_API_for_GUI_Support says:

  unsigned int GetNumberOfExtensionsForReading() const;
  unsigned int GetNumberOfExtensionsForWriting() const;
  std::string GetNthExtensionForReading(unsigned int) const
  std::string GetNthExtensionForWriting(unsigned int) const

Is your idea to have all four of them "virtual", and implemented in
derived ImageIO specific classes?  If so, I would prefer the current set
of two Get-functions:

  ArrayOfExtensionsType GetSupportedWriteExtensions() const
  ArrayOfExtensionsType GetSupportedReadExtensions() const

I think it's preferable to keep the amount of virtual functions limited,
for the sake of simplicity.  You could of course make the four proposed
functions non-virtual, and implement them by calling the other two.  If
so, you might still declare GetSupportedWriteExtensions() and
GetSupportedReadExtensions() virtual.

BTW, the two functions are declared slightly different in
http://www.itk.org/cgi-bin/viewcvs.cgi/Code/IO/itkImageIOBase.h?revision=1.49&root=Insight&view=markup

  const ArrayOfExtensionsType & GetSupportedReadExtensions() const;
  const ArrayOfExtensionsType & GetSupportedWriteExtensions() const;

So they return "by reference".  Maybe it should instead return "by
value", as Proposals:ImageIO_API_for_GUI_Support says.

> 2) The API that you have is very close to what we had in mind.
>
>      std::string GetDescriptiveName() const;
>      std::vector<FileName> GetFileExtensions() const;
>
>    The only different, perhaps, is that we wanted to have also
>    a short description of every specific filename extension.

I don't think every specific extension should have a description.  IMO,
the description belongs to the file format.  For example, .TIF and .TIFF
are two different extensions of one and the same file format.


> 3) About the separation between Reading and Writing,...
>
>    Yeap. some ImageIO objects have different support for reading and
>    Writing.
>
>    For example:  GE4, GE5, GEAw fileformats can be read but we can't
>                  write them.

But every derived ImageIO class supports one specific file format
(either by reading, or writing, or both), right?