[Insight-users] ITK TCon 2.0 : Agenda : ImageIO GUI Support
niels-xtk at xs4all.nl
Fri Sep 12 17:38:17 EDT 2008
Now I see, one specific ImageIO object might support multiple file
formats. E.g, AnalyzeImageIO and NiftiImageIO:
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
ImageIOBase could then have a member, returning a container of supported
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
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:
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.
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
BTW, the two functions are declared slightly different in
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
> 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?
More information about the Insight-users