Nilearn: cut_coords should not force plotting of slices in ascending order

[AlexandreAbraham]

When specifying the coordinates of slices in plotting through cut_coords, they are automatically sorted in ascending order. This is a problem for people who wants a specific order, e.g. descending.

[alexlicohen]

I find this to be an issue too. It is really throwing us off.

[Craskermasker]

interested in this issue

[Craskermasker]

As far as I can tell - cut_coords is passed upstream all the way to BaseSlicer so I'm a little worried that making tweaks could have a lot of unpredictable downstream consequences. I'm happy to play around with this to explore this further.

[jeromedockes]

As far as I can tell - cut_coords is passed upstream all the way to BaseSlicer so I'm a little worried that making tweaks could have a lot of unpredictable downstream consequences. I'm happy to play around with this to explore this further.

sounds good! any info that you can gather would be helpful

[Craskermasker]

This might be a good place to start.
An attribute _direction is initialized as 'x', 'y', or 'z' for each of XSlicer, YSlicer and ZSlicer classes, which are subclasses of nilearn.plotting.displays.BaseStackedSlicer.

_direction is passed to the classmethod find_cut_coords, and the internal logic here assumes a positive direction along each of the axes.

Options may be to:

• add a boolean parameter reverse that will reverse the direction
• try to specify the order of cuts in a more granular way

Thoughts?

[bthirion]

I think that find_cut_coords is called only when coordinates are not specified. The case that we need to address is when coordinates are specified, yet not in ascending order.
HTH

[Craskermasker]

thanks - I think I found where the cuts are sorted into ascending order - BaseStackedSlicer._locator. I am not sure if this PR may have backwards compatibility issues though if users have relied on this automatic sorting behaviour...