If we defined nrrd metadata fields properly then we would end up with something very similar to the DICOM standard. So, it would make a lot of sense to avoid duplication of work and make DICOM standard usable instead.
The only fundamental problem I see is that DICOM only makes sense in the medical domain. We cannot collaborate on file IO libraries, plugins, or tools with the scientific computing community if we use DICOM. A hybrid approach like storing DICOM metadata in a generic file format could allow using DICOM while leveraging work of a much larger community. The generic file format could be nrrd or anything else that the majority of the scientific computing community widely uses and flexible enough to store DICOM metadata.
Can you elaborate on this point? What makes DICOM fundamentally not suitable for scientific computing community? I agree there are many issues with DICOM, but I donāt understand what makes it conceptually unfit.
Time representations (Age String, Date, Date Time, Time): both range and resolution makes them inadequate for general usage.
String value representations (Long Text, Short Text, Unlimited Characters, Unlimited Text, Person Name): they are very similar, with some minor difference in limitations (length, allowed characters, etc). This complicates implementation, while not providing much in return. Having Person Name defined at this abstraction level is very arbitrary.
Numerical value representations: seemingly random selection of representations.
HDF5 data representation model is similarly rich/complicated but it is consistently low-level and provides extremely high performance. NRRD does not provide much, but it is very simple, so it is very easy to implement.
Speaking for myself, I find it impossible to grasp all the capabilities (especially, intended, but not adopted) of the standard and implications of various decisions made in the process of developing the DICOM standard. It is so broad, that very few have a complete picture, and probably no one has the context for why all the various, and often seemingly strange (if not wrong!) decisions were made.
I am afraid that any effort similar in scope started today (if successful in attracting attention from a diverse community of stakeholders with conflicting motivations and agendas and establishing as broad deployment base as DICOM) stands a pretty high chance of being judged in a similar fashion as above 30 years from now.
I agree that DICOM has not been designed as a general-purpose data storage format for the scientific community, and that it looks arbitrary and unnecessarily complex. But I hope and believe it can be more useful to the scientific community than it is now.
Sorry for the distraction from the topic of this conversation.
I agree that it would be harder to get anything much better than DICOM for clinical use and relevant parts could be even useful for generic scientific computing.
The main problem is with DICOMās file format. The file format is not designed to be optimal for anything, it just started as dumping DICOM network data stream to file - and remained just that. See comment in David Clunieās recent paper: āThere was no āfile formatā defined perse, although it had already become common practice to persist network data sets on disk.ā.
Thatās why I think a hybrid approach - storing DICOM metadata in powerful general-purpose containers - could work well. It would make DICOM more widely accessible. We would only need to choose a suitable container (NRRD, HDF5, ā¦?) and standardize the way how DICOM information is embedded.
David Clunie had similar conclusion in his paper, too, by proposing usage of ādualāpersonality DICOM-TIFF filesā. The only aspect Iām not convinced is that it is necessary to create files that are binary compatible with both DICOM and TIFF standards at the same time.