This suggestion looks perfect to me, as it does not cause any breaking change, it safely prevents dealing with ill-defined file formats, and the old behavior is still available for anyone who still needs it.
IMHO the default behavior should be whatever the original Mayo Analyze software did, regardless of the manner in which some later software abused the format (e.g., see the original Analyze 7.5 header description, a copy of which is at http://eeg.sourceforge.net/ANALYZE75.pdf).
@ David Clunie, I agree with you! That was exactly what I attempted to do a decade ago, and that is the position that I have always advocated for. I, however, have failed to provided convincing enough arguments all the times, and the community has disagreed with that position from time-to-time.
I have had a hard prohibition on using Analyze75/FSL/SPM/AFNI ambiguous files in all research I am associated with for about 15 years now.
So, little implementation issue: ITK NIFTI reader tests are using mostly files in Analyze format, so making it disabled by default breaks lots of tests , see https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/NIFTI/test/CMakeLists.txt#L30
So to be clear… Nobody is actually having problems with NIfTI files, right? Only Analyze files?
Andras, our motivation for the change was also backwards compatibility. ITK removed the AnalyzeImageIO reader and stated that NiftiImageIO should be used instead. But it didn’t give the same results. This has kept us stuck on ITK 4 for a long time now.
So you need backwards compatibility with how ITK 4.x/5.0 NiftiImageIO read Analyze files, and we need backwards compatibility with ITK 4.x’s AnalyzeImageIO. (We never used NiftiImageIO for Analyze.)
Hans’ suggestion of providing an option to NiftiImageIO seems correct. But it should default to behaving the same way ITK 4.x/5.0 did. In our app, we can use the new option to behave the AnalyzeImageIO way.
Vlad is working on such a patch.
Cheers,
Sean
Thanks for the clarification.
I’m just curious, why do people still use Analyze file format today?
Andras, I’ve never polled our users, but I hope they rarely use Analyze files. If you use one in our app it shows a warning that the format is obsolete and fragile, but we still try to support it as best we can.
Sean
https://github.com/InsightSoftwareConsortium/ITK/pull/1557 - proposed change
How about simply drop the support for Analyze in ITK5.x and do us all a favor. If researchers (I truly hope no medical professional will ever use Analyze for good reasons) one can always convert to nii.
If we made our 3D Slicer reject Analyze 7.5 files completely then I’m afraid users would start complaining that X and Y and Z software can load an image file without problems (they would not notice the incorrect image orientation), and Slicer cannot.
However, if we all agree that we disable Analyze 7.5 loading in our upcoming software releases then it would send a clear message to the few affected users that the problem is in their data management practices and not in our software.
Maybe we’ll do it anyway, but it would be reassuring to know that we all make the move together.