Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
8975fa8
commit 7faeb67
Showing
2 changed files
with
85 additions
and
48 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
7faeb67
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is in the process of modification: Thoughts on #17? Independently of any GUI-related possibilities, it makes sense given the unweighted signal is part of the fit that it should be included in the output data rather than separate.
7faeb67
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well it's certainly feasible, as you say it's part of the fit. But I'm not convinced it follows that it should therefore be part of the same output image. It is different in kind to the DT coefficients (for one, you need to take its exponential before storing), and is very unlikely to be used as part of the same processing chain. I'd expect people might want to use the b=0 output as input one thing, and the DT for another. Having them be part of the same image forces an additional file split for these cases. So I personally think it would add more confusion than anything...
The other point (although a bit speculative at this stage) is that we were talking with Ben about whether the WLLS fit should be used in the tracking also. We thought the best thing to do would actually be to allow using the DT images directly, and implement proper geodesic interpolation, which would actually be pretty simple (and faster than the current approach). That would then allow any DT image to be used, regardless of how it was produced. It would be convenient to keep the exact same command-line usage as currently, which means we'd need to be able to differentiate between DT and DWI images. Currently this wouldn't be a problem since a 6 volume image can only be a DT image (you'd need at least 7 DWIs to estimate the tensor). Obviously this assumption would no longer be guaranteed if we add an extra volume to the DT image.
On the other hand, I'm not sure the argument above is necessarily going to hold forever: we might eventually remove the ability to track on the DWI directly from
tckgen
, since it currently only implements the most brain-dead approach - and it's not even the same algorithm as what's used by default indwi2tensor
...But regardless, I think my main argument against this is that in practice, people will want to use them separately.
7faeb67
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious to know others' thoughts, or how it's handled in other packages. If other software requires both, outputting the fit with both makes more sense than outputting separate images and having to concatenate; whereas wanting just S0 from the tensor fit is a volume split not entirely dissimilar to pulling b=0 images out of a DWI series, which many users will be accustomed to. But if other applications expect 6 volumes, it's best left as-is.
Having the S0 encompassed in the image would also be of assistance if a tensor overlay were implemented in
mrview
, allowing more options for glyph scaling. But again, speculative.Agreed.
Well that assumes you want to be able to support tensor tracking on both pre-calculated tensor estimates and on the raw DWIs, which to me would seem unusual. And even then, you could just check for a valid DW gradient scheme. My earlier thinking was the other way around: If an application is loading 'orientation data' and gets an image with 6 volumes, it doesn't know whether it's a tensor volume or lmax=2.
... Oh. You said that already. :-/