Author: Cinly OOI (---.medschl.cam.ac.uk)
Date: 04-23-09 08:49
Dear Rick,
> You seem to make both claims, that there is a systemic
> possibility and that there is not.
Sorry for the confusion.
There is a systematic possibility. Currently, it is only a possibility. If NifTI becomes popular and starts to appear in yet-unknown medical devices, usually an embedded one with limitted memory, then it is likely to become a reality.
Currently, I am proposing do nothing. It is going to be difficult to deal with it. As you said, Mac will automatically deal with case, but on Linux and Unixes, case is important. What we seriously do not want to do, is to upset the Linux and Unixes.
Moreover, if any devices file system cannot handle the case correctly as Mathieu said, the solution is very likely to be device specific and will have to be dealt with in a case-by-case basis. Therefore, I will say that the person who first encounter it should submit a patch that will solve the problem for his/her device, possibly using #ifdef statements for conditional compilation as to not change the nifticlib for others. The advantages in this approach are:
(1) The nifti library will work for the device the person encounter. We do not need to bother with updating python/matlab library if that person do not need it, or if the device does not support python/matlab. In my opinion it is OK for one nifti library to be capable of handling more device-specific problems than another library.
(2) It is difficult to work on the problem without the device to test and the compiler to compile the program for. Any device-specific problem usually means we need to know the device type, firmware, compiler version to resolve it. Until we get our hand on the device, it is difficult to know what these information are. It will be unfair to ask you to fork out for the device, so the person who has it should do the work.
HOWEVER, should anyone ever plan to revisit the read/write routine, may be one should try to make the read/write routine independent of file extensions and test the file themselves to determine the content. For example, try to ungzip first, if fail, non-gzip file detected, then try to read magic number, if fail, try analyze. If all fail, try to search the directory for hdr/nii etc.
> What micro-controller systems handle NIfTI data where
> the case could be a problem? If there are such systems,
> that would qualify as a systemic reason to me.
It is, luckily, still something I haven't encountered (for nifti data). I am just sharing information about past experience with computers.
As I mentioned, a custom solution is usually required. Only the person who bought the system has all the information necessary to patch the NifTI library. With NifTI licensing, he will then have to decide whether to contribute back the patch
> I mentioned macs because they have case issues. Try
> "touch a.nii" and "touch A.NII" on a mac. They refer
> to the same file.
Well-written file system will do that if case-insensitive is what the file system provider will offer.
With embedded device/microcontroller sometimes you find people using their own file system (e.g., no sub-directory allowed) which will require their own solution.
> Mathieu,
>
> Let me be more clear about my opinion...
>
> If there is a system that uses NIfTI that cannot handle
> lower-case extensions, I would be inclined to add it.
>
> If it is just for protection against human error, I'd
> be inclined not to do it (but could be convinced, it
> isn't a big deal after all). Humans learn easily, and
> it is good to be consistent.
I think Mathieu is looking is something like this
ls | xargs -I{} -t nifti_tool -disp_hdr -infile {}
where 'ls' will always return filenames in upper case, like DOS do. Then, the current nifticlib will complain that it cannot find ".nii", even though ".NII" is acceptable.
If this is what he want to resolve _and_ you think that we should resolve, then I suggest we add ignore_case flag to the nifti i/o routines. We still have to maintain that ".nii" and ".NII" can be different in another operating system.
I do not think we can protect human error by forcing everything to lower case. A.NII, a.Nii and A.niI are different files from the view point of a non-trivial number of file systems. We have to preserve it.
I recommend against doing it simply to protect against human error.
Mathieu,
If you really want to do it then I will suggest that you put in a compiler option to enable what you want with #define function, like what HAVE_ZLIB do. All you have to do then is to set the compiler option when compiling it.
I recommend against blanket conversion to lower case, because it will cause havoc in a lot of file systems in use.
Thanks
Cinly
|
|
