Closed daducci closed 6 years ago
I agree. Furthermore, I suggest also a ".txt" file with the coefficient x estimated by COMMIT. Hence, no need to pass through pickle to get the coefficients. This will make the main results of COMMIT more accessible to people.
I also suggest to give an option to output a ".trk" file with the streamlines coloured with the coefficients x recovered by COMMIT.
What do you think? I can take care of the implementation of the code.
I'd say to offer an option to save this .txt file that is directly compatible with e.g. MrTrix. As for the .trk, I'd say probably not at this stage, as it can be "dangerous" to directly visualize the colored fibers as the singles weight do not make much sense, but they have to be considered fascicle by fascicle.
The idea of complementing the .trk file with some information about the weight will be very useful also for the future extensions that we are planning. Instead of giving some "colour" value to each streamline, we could assign a numpy array that for the moment has dimension ns-by-1 and contains only the weight. We are planning modifications that will output more than one value for each streamline and only a colour label would be limiting.
I agree with the suggestion of @matteofrigo. Also, if the objective is to save the optimization results in clear text, I would suggest .json instead of pure text. This way people will be able to look at the results with any text editor and will still be able to automate things without writing a parser. The json
package in python is basically a drop-in replacement for pickle
so this solution also minimizes changes to the code.
This issue is partially addressed in the PR #36. Indeed it could be interesting to export more than one value associated to each streamline, but in that case we cannot use the txt
format. Nonetheless, the txt
format is very useful to subsequently analyze the results with MrTrix.
Closed by PR #36
It would be nice to save to the
results.pickle
file also the information concerning the optimization run, e.g. cost function, relative error etc at each iteration. This could help analyzing the performance of the optimizer offline. At the moment, these values are reported to screen only.