Since the warped anatomy lacks MNI normalization, process_simulate_dipoles produces an error if MNI coordinates are given. This is caused by cs_convert (at L186), as the warped anatomy does not have NCS.R nor NSC.T.
While this can be solved by computing MNI normalization on the warped anatomy.
Would it make more sense to get this transformation at the moment of warping? or Detect in cs_convert if sMRI from warped and use the (no warped) default anatomy to do the coordinate system conversion?
Would it make more sense to get this transformation at the moment of warping?
Indeed, the best option would be to save the forward and inverse non-linear deformation fields of the warping transformation as two 3x3D volumes y and iy.
After creating these deformation fields, I guess there would be faster options to apply them to the all the volumes in the anatomy (all the recently add volatlas make the warping take forever).
However, this is not a trivial task, and I won't be able to work on this anytime soon.
If you don't want to dive into this either, you could intercept the error in process_simulate_dipoles and ask users to compute a non-linear MNI transformation for the warped subject (you don't even have to detect that this is a warped anatomy - you could simply use the same error for all volumes lacking a MNI transformation).
This is very suboptimal, but this is also not a common use case and we probably shouldn't spend too much time on it.
Sounds good, if the process input is in mni coordinates the process and there is not MNI normalization, and error asking to MNI normalize first will be prompted.
Don't we need a similar error in cs_convert for any conversion to or frommni when there is not any type of MNI normalization info?
Yes, it's not a common use, it just came when testing the DB migration.
Note added on the warping tutorial about the lack of MNI normalization in the warped anatomy
My initial intention was to return an empty set of points and let the calling function handle the missing option to convert to/from MNI coordinates.
Returning an error and catching it in a try/catch block in the calling function is another way of dealing with it, maybe a bit heavier, but that would block any process where the missing MNI coordinates are not handled.
I think it would be less work to make sure that all the calls to cs_convert implying MNI coordinates are equipped to deal with an empty matrix in output, rather than to rewrite all the calls to cs_convert with a try/catch encapsulation.
Does it make sense?
Note added on the warping tutorial about the lack of MNI normalization in the warped anatomy
