Join GitHub today
Fix utils docs and affine #352
Because I had to move most if
@jchoude could you take a look at the functions that use the
referenced this pull request
Apr 30, 2014
Overall, all seems good. A few small points:
An affine of eye(4) means the streamlines are in voxel coordinates, not real world coordinates. I've done my best to describe this at the beginning of the module, but I'm always a happy to get help writing documentation :).
It's in general hard to create an affine from limited information. The affine is not arbitrary and using the wrong affine will result in streamlines being outside the image for example. If the streamlines are loaded from a known file type with good header information, we can build the affine from that. For example
Yes sorry for the delay.
Regarding your comment about the affine of eye(4) meaning the streamlines are in voxel coordinates, this is true. However, let's say my original data was in a 1x1x1 resolution, and some preprocessing put everything right up to the origin... In that case, an affine of eye(4) would also fit with the world coordinates, except if I really misunderstood something, which can happen :)
My case was that it could be written in the doc that, if streamlines correspond to the scenario I just described, an affine of eye(4) could be used. Of course, that's just one use-case.
As for the helper function create an affine only from voxel sizes, I agree that's it maybe too much, and could cause havoc for users not knowing what they are doing.
I also agree with your point about the deprecation cycle. Should this be written in a doc somewhere, saying what will be deprecated and when? Just so we remember...
On Wed, Jun 11, 2014 at 6:09 AM, Jean-Christophe Houde <
I also agree with your point about the deprecation cycle. Should this be
We could consider this the doc :). There is a deprecation warning raised