Lestropie
commented
2 years ago I agree that the issue you're describing is somewhat agnostic to the TRX format. But given there's potential consequences for TRX, it's probably a reasonable place to have the discussion.
There's a few discrete concepts in here, so I'm going to try to tease them apart and enumerate so that we don't all immediately start talking cross-purposes. I don't think that "degree of lossiness" is the right dimension of classification to be using.
-
Alternative compression-based representations For something like QFib, where it is not an ordered list of 3-vectors per streamline that is stored but an ordered list of step directions, a discrete algorithm exists that can convert those data back to an ordered 3-vector list. So it can be treated somewhat independently of the other issues under discussion here. If a compression technique such as this is used, then it may be guaranteed that the vertices are equi-distant, and so the other issues below may or may not be relevant in that scenario; but it's important to keep the two potential sources of error separate.
-
Streamlines are continuous, vertices are discrete This technically applies both to detecting whether or not a streamline intersects a binary mask image, and to "tractometry" (i.e. sampling values from an image along the streamline trajectory). The latter is more conventionally done based on interpolation at streamline vertices; but the theoretical solution given the continuous nature of streamlines would be to construct for each streamline an ordered list of voxels traversed, with the length of each voxel intersection and its relative position along the streamline length. This is where naively taking the ordered list of 3-vectors and assigning each to a position on an image voxel grid may lead to issues. This is however not specific to TRX: we have this problem already elsewhere, it's fundamental to the fact that a streamline is assumed to be continuous but we are using a discrete representation. In MRtrix3, we by default do a basic upsampling so that each streamline has an "adequate" density of vertices relative to the voxel size to mitigate the problem. We also have an implementation based on a genuinely continuous streamline representation, originally linked in #8, described here; this is currently only utilised if requested explicitly by the user for the purpose of TDI / TWI, I've considered the prospect of utilising this algorithm more widely at MRtrix3/mrtrix3#1450. For softwares without a robust solution to this, I would advise at least checking the inter-vertex distance relative to the image voxel size, and issue a warning if that ratio is such that there could potentially be issues in performing a basic vertex-to-image mapping. I would also note here that there'd be nothing stopping you from manually running an explicit upsampling step beforehand in order to mitigate the limitation of the downstream software.
-
Vertices may or may not be equi-distant
This is one aspect where there may be merit in influencing TRX. In the points above, I'm essentially making the argument that the empirical behaviour of downstream software should be relatively agnostic to the discretised representation of a streamline, at least over and above the errors that arise specifically from that discretisation. But it's possible that knowing whether or not the vertices are equidistant may be useful for some softwares if they've not exhaustively dealt with this issue. This could potentially be represented in metadata somewhere. MRtrix3 already does this to some extent, in that an operation like concatenating two tractograms that were generated using different step sizes will result in invalidating the step size header information. There's a bunch of traps to be aware of in this context:
- For some algorithms (and indeed for the default algorithm in MRtrix3), it's possible that while the vertices in the middle of the streamline may all be equidistant, the lengths of the first and last steps may be shorter.
- If upsampling or downsampling the vertex sampling density by a fixed ratio, this does not correspond to a fixed inter-vertex distance modulated by the same factor. It will be approximately such, but not exactly.
- If a streamline with equi-distant vertices undergoes a non-linear spatial transformation operation, its vertices will no longer be equi-distant.
- There can be a difference between the step size that was used during streamline propagation, and the inter-vertex distance of the streamlines as stored on file; the former relates moreso to provenance, whereas the latter is more relevant for utilisation of the data.
- All of these factors are additionally relevant for the calculation of streamline length (I learned that the hard way: MRtrix3/mrtrix3#1507)
So my personal conclusion would be:
- Potential weaknesses in streamline-to-voxel mapping are the responsibility of the software doing the mapping, not the format providing the input data;
- It may be beneficial for TRX to provide metadata information regarding inter-vertex distance and the consistency / inconsistency of such, but I wouldn't consider it essential.
- Consider how best to communicate this confound to the community; there are technical solutions implemented, and it's been presented as a minor detail in a couple of publications, but perhaps it needs its own dedicated documentation somewhere.
DanNBullock
Hi all,
My apologies for getting to this conversation late, but I had some questions about the implications of the compression/linearization capabilities afforded by this new implementation. There is an existing discussion here, but to my reading it largely deals with the proximal details as they relate to implementation and immediate consequences. My considerations relate to implications that are a bit further downstream.
This may be an arbitrary delineation, but to me, it seems like the discussed streamline-focused, lossy compression methods can be divided into two tiers of “lossyness”:
To me, these two categories are distinct in that the first corresponds to a slight loss in precision (and thus the introduction of a slight bit of noise), while the latter actually modifies the data representation itself through the removal of nodes/vertices.
The implications of these latter strategies are partially determined by how “decompression” is implemented (if at all). For example:
I understand that there are significant efficiencies to be gained through some of these methods, and that for some of us (e.g. those doing connectomics) the quantifications are unaltered. Moreover, I understand that some of us have gone so far as to quantify the impact of such approaches to varying degrees (e.g here and here). That being said, I have some concerns about the implications of such compression methods for contemporary tractogram segmentation methods themselves (explored to some extent in the later of the aforementioned papers), as opposed to tractometry or derived measurements.
Specifically, there seem to be a plentiful number of cases wherein these methods would impact the outcome of a segmentation non-trivially (as discussed in the caveats at the bottom of this page). Namely:
To some extent, I recognize that these concerns aren’t actually arising from the compression methods being proposed here, but rather downstream consequences of their application. As such, it may be beyond the scope of concerns we are intending to address with this format implementation. That being said, if the goal is to implement a tractography standard that can be used across the community, then it stands to reason that we are designing for a range of potential users, some non-trivial proportion of which won’t be familiar with the nuanced implications discussed above. As such it is quite possible that such users could unintentionally run afoul of these issues and/or encounter difficulty replicating results using “the same data set”.
Are we at all concerned about these possibilities, or are we adopting a more laissez-faire approach to use of this format and its features? If we are concerned about these possibilities, how do we make them salient, or how do we attempt to shape users’ default dispositions?