So, overall, I do fully agree that keeping information in the header if it doesn't hurt is a good thing. I'd be silly to explicitly go out of our way to strip it if there's no harm in keeping it (and occasionally it might just happen to figure out what went wrong along a pipeline or something). That's definitely a principle I took into account when questioning the presence of the gradient table in non-dwi files further down the pipeline track.
Another "principle" (let's call it a guideline, principle sounds a bit too strong maybe) I try to take into account when possible is that information (in a header) should not be "wrong" in relation to the data. I intentionally say "wrong" in the "..."-way there, because it's very much open to interpretation. I wouldn't necessarily call a gradient table in the header of an FA file wrong, because there's no way to misinterpret that situation: the gradient table will in any realistic scenario have more than 1 entry, and the FA file is just a 3D scalar map. Let's say I'd use mrtransform thereafter to rigidly rotate the FA map, I'd say it starts to approach the boundary of "wrong"-land (even poking into it, I'd personally say). It'd still be okay-ish if mrtransform adds information to the header about the rotation that took place (so there's a way of making a consistent reconstruction about how the gradient table in there actually relates to the image(space) at hand); or if mrtransform in that case would actually rotate the gradient orientations as well... but if not... I'm starting to doubt the usefulness of the gradient table in there, up to the point where I might question whether it's actually not misleading or "wrong". So yeah, information is better than no information IF the information doesn't hurt or is wrong (misinterpretable in any way). But information that has (even just) the potential to be wrong.. I wouldn't say that is to be preferred over no information, necessarily, at all times.
But I think what made me question it the most, is in the case where the gradient table comes along in 4D images. And admittedly, those are quite (if not the most) central concepts in MRtrix' processing pipelines: the models (tensors, FODs, other SH fits, ...). I wouldn't even say it's that unlikely that, e.g., someone feeds a single shell (no b0's) DWI dataset with 45 measurements (because they read in some obscure ISMRM abstract or NeuroImage paper that that is the minimum needed amount of directions for HARDI at b=3000 😉 ) into dwi2fod, obtaining a 45 SH-coefficient FOD file; and in the current state of things it would come with a 45 entry gradient table. That's definitely a scenario that's (trying to) invade "wrong"-land there, and it will lead to all sorts of quirky behaviour along the further pipeline.

Or let me even put it the other way around, as to possible advantages of making sure that a tensor/FOD/... file doesn't pack a gradient table: just as an example, mrtransform being able to rely on such a property, would empower it to see that certain 6, 15, 28, 45, ... 4th dimension sized images are not FOD files (but DWI files, because (only) they pack a gradient table), so they should not (automatically) be subjected to FOD reorientation.

Dave's example:

For example, what if you want to truncate the SH series? Currently mrconvert -coord 3 0:14 will automatically truncate the DW directions (assuming it is a DWI).

...actually shows that certain apps already make this assumption (even though it currently does not hold).

I do admit that realistic scenarios where, in the current state, things go wrong big time and this also manages to slip under the radar of a reasonable user are probably sparse (and this is a bit of a discussion about a first world problem in that sense), but still I feel that the potential inconveniences are a little bit bigger that the potential advantages to be gained by keeping the gradient table in the header. As Dave's example shows, it's not unrealistic for the gradient table to be essentially broken along a pipeline anyway. 😉 So in a better world where democracy allows for voting on scales of 1 to 10, I'd say I vote a 6.5 to not keep the gradient table in (at least) a tensor/FOD/SH file's header. :-)

mrfilter removes gradient table #375

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions