Open soichih opened 4 years ago
Hello, sorry for the delay in our response. The segment length is the same thing as the step size in our case. The constant step parameter in mrtrix3 does not always create a real constant step between points depending on the method used for the streamlines generation. With IFOD2 for instance, it's not the case. If you generated your data with such an algorithm, it is still possible to compress it (using the -n flag) but in that case, the error might be more important because it will not correspond to the mathematical constraints we use in our algorithm. You should, in that case, check the result with the -e flag that will show you the compression error. If it's too important, you can try to improve the result using the 16 bits quantization (--16bits flag).
If you have the ability to change the way your data is generated, you could generate it with a constant step metric such as IFOD1 or SD_STREAM. In that case, our method should work properly.
We searched and it seems that there is no tool easily accessible to resample data with constant step for now. The mrtrix3 tckresample method and dipy do not seem to output constant stepsize along streamlines. In fact, that might still be an open problem, we are investigating. We will update the repository if we find such a tool or if we develop one ourselves.
I hope it will help you a bit with the issue.
Maybe this helps: https://dipy.org/documentation/1.1.1./examples_built/streamline_length/ with from dipy.tracking.metrics import downsample
see https://dipy.org/documentation/1.1.1./reference/dipy.tracking/#downsample
I have a tck data generated from mrtrix3/tckgen which should use a constant step size by default(?)
When I run qfib on the output, it will run for a while but then eventually ran into this problem.
Is segment length the same thing as step size? How can I resample our data?