Closed carlocastoldi closed 3 months ago
i feel like since i moved the slicer to using vectors for defining the slicing plane, some default values could be better defined. If you feel like this is not the best configuration, we could talk about them here!
Attention: Patch coverage is 0%
with 2 lines
in your changes are missing coverage. Please review.
Project coverage is 0.00%. Comparing base (
a2d04d6
) to head (fb70a5e
).
Files | Patch % | Lines |
---|---|---|
brainglobe_heatmap/slicer.py | 0.00% | 2 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Thank you!
The default values I am speaking about are the u0
& v0
and u1
& v1
vectors that define the slicers:
the two vectors also define, for each of the possible positions
(horizontal
, sagittal
and coronal
) the x and y axes onto which the 3D shapes are projected into 2D. Their values are thus important in defining which is up and down, left and right. While also being making sure that the normal vector u0×v0
is facing u1×v1
normal vector.
I tried to tweak these parameters myself, but i think it greatly depends on the atlas used. For instance, Allen's Y axis is ~reversed, causing sagittal projections to be flipped. This particularity with the Y-axis, i think, is not be always true for all atlases and animals
Sorry I think I still don't understand!
All BrainGlobe atlases have the same orientation, and follow numpy convention. In some cases though, this may be different to how they are defined elsewhere (e.g. the Allen has a slightly strange coordinate system). Would you mind creating an issue to describe what the problem is?
"horizontal" orientation is rarely used, but when using displaying the zebrafish brain for an internal demonstration i think i found that the Y axis was inverted resulting in a projection that had some dis-orienteering results.
Additionally i added the possibility to create a
Slicer
by giving a position that is anumpy.number
as wellDescription
What is this PR
Why is this PR needed? Allow better interoperability with scientific code using numpy and keeping a consistent visualization of the projected cutting planes
Is this a breaking change?
no
Does this PR require an update to the documentation?
no
Checklist: