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

[Sean McBride]

On 9/4/08 12:40 PM, Luis Ibanez said:

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

A few things come to mind:
 - the textual description you speak of, is this a human-readable
description?  How to deal with localisation?  What language would the
description be in?
 - 2 other file formats to consider:
   - MINC (single file, extension: .mnc)
   - PAR/REC (file pairs, like Analyze, ext: .par & .rec)
 - note that the correct spelling is "NIfTI" 
 - case sensitivity: are .nii, .NII, .nII, etc. the same?  Some OSes/
filesytems support case sensitivity, others do not.
 - string encoding. If these API use char* then we should document which
encoding is expected.  ASCII? UTF8? UTF16? Platform dependent?  I
suggest platform dependent, meaning that the string should be encoded
with the encoding expected by the OS APIs (like open()). (This is
somewhat academic since few common file formats have not-ASCII extensions.)

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada