fixel2voxel: Fix dimensionality of output image

[Lestropie]

When the operator chosen to map fixel data to a voxel grid results in a single scalar value per voxel, the output image should logically be a 3D image. However, due to use of the fixel format index image as the template, many such images come out as 4D. This change explicitly sets the output image dimensionality for each choice of operator.

The test data need to be updated also; but I'm posting here first to see people's opinions on base branch for the merge before I do so. I personally consider this a "bug", since when writing a script wrapping this functionality I had to explicitly pipe the result to mrconvert -coord 3 - -axes 0,1,2 in order to get what would intuitively seem the "correct" result. But conversely, the command is not fundamentally "broken" in terms of crashing or producing outright erroneous results, and this change does "alter behaviour", which would justify instead going to dev... Thoughts?

[jdtournier]

I'm not sure I fully appreciate all the subtleties and side-effects of these changes, but it reminds of similar discussions we had on stripping out singleton dimensions in commands that generally produce 4D output, but can sometimes produce 3D output in the form of a 4D image with a singleton trailing dimension - issues #55, #343, #344 & #552 in particular. Do the concerns I'd raised about these kinds of changes also apply in this context? Things like this specific example spring to mind...

[Lestropie]

I get the concern, but I don't think they're relevant here. In the dwiextract example, the issue was that the output image could be either 3D or 4D depending on the input image. In other examples, the issue was that this outcome could vary depending on a user input to a command-line option (e.g. single value v.s. list). Here, the fixel-to-voxel operator is compulsory, the expected output is unambiguous for all cases (despite the fact that it is different for different operators), and the case where a user could potentially provide either a single value or a list of values as input to an option / argument doesn't apply. Conversely, having an image of "fixel count" that contains 2 volumes, and the second volume is zero-filled, is clearly not intuitive. I don't see a sensible use case where a user would be free to provide either "count" or "split_dir" to voxel2fixel, and a script would be constrained to expect the outputs of both of those images to be 4D, which is what would be required for similar issues to those previous examples to arise.

[jdtournier]

OK, that's good to hear. 👍

[thijsdhollander]

Ok, (have to admit) I haven't had the time to look into the details, but I've seen problems in scripts (both my own as well as other peoples') being introduced due to this dimensionality aspect. One important script that at least uses fixel2voxel that comes to mind, is the dwi2response tournier algorithm, which is quite important (so should definitely not be risked to be broken). It may be worthwhile to at least test that one, since there's no CI tests for that one. However, due to (I think? Correct me if totally wrong.) at least a potential for this to break anyone's existing script(s), I think it might at least be safer to rebase this to dev for now...?

[Lestropie]

dwi2response tournier is unaffected since it only uses split_data and split_dir.

Anyone wrapping this functionality within a script would need to explicitly rely on the fact that the output of the command is currently inappropriate (i.e. try to access the second zero-filled volume for an operator that one would expect to produce a single volume) in order for the change proposed here to trigger an issue in their script.

But it's behaviour modification nevertheless; so let's go to dev. (Just getting that out of the way in order to clear my list)