As far as I understand, the discussion @lassoan sparks is not strictly about @crossmanith 's issue. The issue reported by @crossmanith , as @dzenanz points, looks more a loss of precision issue due to:
- Multiple processing steps applied to the image, and
- Most probably, due to internal issues within such steps.
I ignore whether @crossmanith is using
NIfTI for neuroimaging data. If she is, then she is using
NIfTI for the “appropriate” modality, and the issue is still about the loss of precision, internal issues, or misuse of the relevant information in the pipeline. So, sorry @crossmanith if this is another message that adds on your thread diverting from your question (maybe the relevant part can be moved to a dedicated topic).
And then, if she is dealing with neuroimaing data, we’d actually be facing those very same limitations in the neuroimaging community, or the ITK community at least (potentially derived from third-party libraries ITK uses to deal with
I am by no means an expert in the
NIfTI format. I have witnessed your frustration with it, @lassoan, as well as @hjmjohnson 's or @zivy’s. But I’d also say that the neuroimaging community faces also some great challenges when using file formats and standards other than or besides
NIfTI. @pieper knows these better than me.
If people use
NIfTI to deal with medical imaging data, I guess it is because:
- It allows users to avoid dragging
N DICOM files (i.e. tens or hundreds of them) and have a series in a single file.
- Other formats are less known to them.
- The inconsistencies, problems, shortcomings, etc. of a given format are not well documented, or are very sparsely documented, or are not sufficiently demonstrated with code and examples.
My feeling is that an additional problem in all this are the different implementations or interpretations of a given standard or file format.
When I had to deal with non-neuroimaging medical imaging data, I used to convert the
DICOM files to
MetaImages. Not sure if that was fair or appropriate either, but the choice was probably influenced by what was customary where I was, because we (or I) did not know enough about its potential problems or shortcomings, or did not know
NRRD or other formats enough.
I do not know
Zarr so I cannot say in which ways it is better.
As for the specific questions:
- Promote NRRD instead? It is a simple, already well-established file format that could be used instead of nifti for general-purpose applications.
Promoting a given format involves great resources and effort (e.g. a practical workshop in every major medical imaging meeting/conference to demonstrate the pitfalls of a given format and benefits of another one (?), online resources, etc.). I have seen you @lassoan and also others persevering not to use
NIfTI for non-neuroimaging medical data throughout the years, but it looks like those efforts are not hitting the target unfortunately.
- Fix nifti? Simplify, remove/clarify inconsistencies and redundancies should be possible, it would require very small modifications in the implementations, the main challenge would be making current nifti users agree that change is needed.
Not sure about the meaning of fixing NIfTI. Whether it is the standard/file format the one having a problem or its implementations/(mis-)interpretations the ones having one or more problems, then I guess they have to be fixed since I assume those problems have an impact even on neuroimaging data. I’d say that the Python neuroimaging community heavily relies on
nibabel to deal with
NIfTI (after converting the
DICOM files to
NIfTI with some tool like possibly
dcm2niix). So I’d dare to say that
nibabel maintainers would be happy to be part of such discussions and fixes.
- Start promoting a more modern, more powerful file format, which will serve future needs of the medical image computing community? The file format should be simple enough and/or have small, high-quality implementation in all major programming languages and environments (complicated beasts, such as HDF5; or Python-only implementation would not be ideal).
I would not be for promoting and implementing a new format; I am hesitant about the power to involve a critical audience and developer mass necessary to implement it.
Currently, my personal time to deal with these issues is limited. Also because my understanding of them is limited.
In summary, I believe that any known shortcoming of a given format, or any misintended use of it, has to be documented, be made available/demonstrated through code and examples, across several modalities and at a single place so that whenever this or similar discussions arise, or it is argued that a format has such limitations, a link to it would suffice and be enlightening enough/self-explanatory.
PS: Very sorry for the lengthy message.