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

[Niels Dekker]

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?


The Second life TCON starts within 40 minutes, right?  I'm standing
there already, but I have to get some food beforehand  :-)


Kind regards, Niels