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

[Luis Ibanez]

Hi Sean,


Thanks for your feedback.

1) Yes, the intention of the description was to
    make it "human readable".

2) Nope, we completely failed to consider that there
    are more people and cultures in the world, and
    it a great display of nearsightedness we assumed
    that a description in English was a solution.

    Our apologies...

    Could you suggest a mechanism that could facilitate
    internationalization ?


3) Case sensitivity of extension is an open issue.
    We assume that every file format has its own rules,
    so will have to figure this out in a case-by-case
    basis.

    For example, the JPEG ImageIO supports both jpg and JPG.
    while other ImageIO classes are only accepting the lower
    case version of their extensions.

    ... and as you pointed out, given that certain OSes
    are not case-sensitive we probably will have to accept
    case variations at reading time, but enforce a single
    case  at writing time.

4) I can't say much about the encoding. I remember that this
    issue was brought before.  The way we are implementing it now
    is by simply adding messages const char *, by writing the
    text in between " "s.


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


------------
Sean McBride wrote:
> 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.)
>