[Insight-users] ImageIO & GUI Support : TCON 2.0 : Topic for Tomorrow : Request for Feedback

[Luis Ibanez]

Hi Niels,

Thanks for your feedback.

About your comments:


1) Yes, we were brainstorming with returning data in the form of
    an STL container of std::strings.

    It could be a std::vector< struct >  where struct could have
    multiple fields of type std::string.

    This is open for discussion.
    It will help to have some use cases describing how GUI applications
    are using (or would like to use) this information, so that we can
    provide the data in a format that is easy to use.


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.

    E.g. for ImageIO classes that support multiple extensions,
    we would like a short text indicating the nature of each
    extension. For example:

      * "Uncompressed pixel data in binary"  .img
      * "Compressed pixel data in binary"    .img.gz

    There fore there could be an extra call

     std::vector< std::string > GetFileExtensionDescriptions() const;


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.

    Therefore we have to reflect this lack of symmetry in the API as
    well.


4) We missed to consider unicode and localization.

    We will appreciate any suggestions on how to manage this correctly.



-----

We have added a proposal in the Wiki, at:
http://www.itk.org/Wiki/Proposals:ImageIO_API_for_GUI_Support


and will be discussing this again today at the tcon:
http://www.itk.org/Wiki/Agenda%26Status_091208

For instructions on how to join the Tcon 2.0 in Second Life,
please look at:
http://www.itk.org/Wiki/ITK_in_Second_Life



     Regards,


        Luis



-------------------
Niels Dekker wrote:
> At our research group (LKEB), we're also developing an Image IO 
> framework.  Although this framework is more specific to our inhouse 
> software development (as it supports LKEB-specific file formats and data 
> structures), we've encountered similar design issues.  Both ITK's and 
> VTK's IO frameworks are a source of inspiration to our Image IO 
> framework.  :-)  It would be very helpful to us at LKEB to be able to 
> query the file extensions and the file format description from ITK IO. 
> VTK already has this, which made it much easier for us to write a 
> wrapper for VTK readers, for our (LKEB) framework.
> 
> I think it's a good idea to have the extensions and description of a 
> file format aggregated together.  Do you mean to have them as an 
> std::pair<string,vector<string>>?  At LKEB, we chose to have them 
> together in an AbstractFileFormat class, offering two member functions:
> 
>  std::string GetDescriptiveName() const;
>  std::vector<FileName> GetFileExtensions() const;
> 
> Each file format we support has its own class, derived from 
> AbstractFileFormat.
> 
> Why do you have separate functions for supported read and write formats? 
> Doesn't an IO class typically supports the same file format for reading 
> and writing?  Or could one specific IO class possibly support reading 
> only JPEG and writing only TIFF files?
> 
> I'm also very interested in the Unicode and localisation issues raised 
> by Sean McBride at the Insight Developers mailing list.
> 
> Kind regards, Niels
> 
> Luis Ibanez wrote:
> 
>> We would like to get feedback from users
>> regarding the following topic:
>>
>> When using ITK in GUI applications, it is desirable
>> to have a mechanism for figuring out what file formats
>> are supported for reading and writing, so that they
>> can be offered explicitly to the user in the titles
>> of the Open and Save file dialogs.
>>
>> For this purpose, we recently added to the ImageIO
>> classes the following three methods:
>>
>>  * ArrayOfExtensionsType GetSupportedWriteExtensions() const
>>  * ArrayOfExtensionsType GetSupportedReadExtensions() const
>>  * void AddSupportedWriteExtension( const char * extension )
>>  * void AddSupportedReadExtension( const char * extension )
>>
>> Unfortunately this API is not sufficient, because it doesn't
>> provides a textual description of the supported file formats
>> and a generic name for the family of file formats.
>>
>> Additionally, these new API has not been fully implemented
>> in all the instances of the ImageIO classes.
>>
>>
>> We are therefore proposing to do one the following:
>>
>> *  Proposal 1
>>   o Change the GetSupportedWriteExtensions()
>>     and GetSupportedReadExtensions() to return
>>     an array of pairs (extension, description)
>>   o Add a method to return a generic description of
>>     the ImageIO (e.g. NIFTI, Analyze, MetaImage)
>>
>>
>> * Proposal 2
>>   o Change the GetSupportedWriteExtensions()
>>     and GetSupportedReadExtensions() to return
>>     an array of triplets (extension, description,
>>     generic description)
>>
>> We plan to discuss these two options during tomorrow's
>> TCon, as described in the Agenda:
>> http://www.itk.org/Wiki/Agenda%26Status_090508
>>
>> For instructions on how to join the ITK Tcon 2.0,
>> please look at:
>> http://www.itk.org/Wiki/ITK_in_Second_Life
> 
> 
> -- 
> Niels Dekker
> http://www.xs4all.nl/~nd/dekkerware
> Scientific programmer at LKEB, Leiden University Medical Center
>