I enjoy a lot the flexibility of mif format when it comes to store the b-value encoding in the header. It keeps my projects folders cleaner and easier to work since it saves me from having three different files as in FSL gradient files. SO this ability made me think about another that may be useful.
I never checked in deep how mif header works, but I was wondering if it would be interesting for parcellation images to have the ROI names associated to each intensity level embedded in the header. When generating or viewing connectome this info could be taken directly from the header instead of providing a txt file with the names. Of course at 8 bits per character having all ROI names could be a big overhead for the file, but I’m throwing the suggestion to the air for developers and other users to try to make mif format a little bit more amazing.
I know it’s not a super crucial feature and doesn’t make any quality difference in our pipelines, but I think code and file structure would be cleaner this way. It’s just a matter of user comfort.
I suppose part of the logic of tracking the diffusion gradient table per subject is that it may vary between subjects (even if only due to motion correction). For a parcellation scheme, it is expected that the ROI indices are going to be consistent across some number of subjects; therefore keeping track of the label information separately for each subject would be redundant, even if those data are relatively small compared to the image information (and data storage is cheap).
The main issue I would have with the concept is not the storage aspect, but trying to maintain consistency of that data with the image, in the presence of user manipulations. To explain: Consider using dwiextract or mrconvert to extract a subset of image volumes. If the subject’s gradient table is stored externally in separate files, there’s an implicit understanding that those files will no longer be consistent with the image, and must be modified (either by importing & exporting as part of the command call, or by making the modifications manually); whereas if there’s a diffusion gradient table present in the image header, it is automatically modified correspondingly by the command in order to stay consistent with the image data. This takes work on our part to identify such cases and ensure the header data are modified accordingly.
For integer labels, this would be even harder. For instance, let’s say you reset all voxels with a particular integer value to zero, and all values greater than that index are decremented by 1 (this corresponds to removing a specific node from the parcellation). In order to keep a lookup table embedded within the image header consistent with the image data, all of the image manipulation steps used to make this modification would need to be aware of the presence of the lookup table, and update that table automatically as the manipulations are made.
In the upcoming 0.3.16 tag update, mrconvert will get new command-line options for altering header entries, that if used correctly could pull a text file into the header. I suppose mrview could look for a particular header field in the parcellation image (put there either manually, or automatically by labelconvert), and load it as a lookup table if present… My concern is that as soon as a particular header field is “supported” in MRtrix3, there’s an implicit assumption of guaranteed consistency with the image data, and there’s so many ways in which that consistency could be broken in this case.
Thanks a lot and nice reflexion I learned a lot from it.
Now I understand why gradient table is embedded in the header (I don’t have access to multi-shell data so I never though about extracting different shell’s series while keeping gradient consistency). Also I see that, since parcellation is shared along all subjects, it makes more sense to keep it outside as a configuration of the pipeline for this specific project. I think will play with the new version of mrconvert when released I see great potential in mif files.
