scaling the stack for different resolutions[BUG]

[Timbrer]

techical_issue_about_anatamical_space.pdf

[alessandrofelder]

Moving the text out of the pdf:

I guess many of us are using the module from bg_space import AnatomicalSpace for scaling the anatomy and cords
for morphing, however, there are some issues and please pay attention to it.
Firstly, interpolation of a stack.
Let’s image we have a stack the shape is (3,3,3), the resolution is (2,2,2) um. We want to scale it to the stack with
resolution of (1,1,1) um. The result shape should be (5,5,5), because there are 2 gaps of 2 um.
However, in the anatomical space:

There is because in map_stack_to function, scipy. ndimage.zoom is used to scale, the scale factor is set as the
resolution, so the final shape is directly the shape of stack times resolution (3,3,3) * (2,2,2) in this case. So the
solution of the result stack is not (1,1,1) any more

[adamltyson]

And the second page:

I guess many of us are using the module from bg_space import AnatomicalSpace for scaling the anatomy and cords
for morphing, however, there are some issues and please pay attention to it.
Secondly, transform of the coords of rois, I show an example of my data, the resolution is (8.75,0.6,0.6) um,
orientation is ipr , now I want to transform them into a space with (1,1,1) um, orientation is sal.

In the output [15], it’s raw rois coords, of 21 planes.
So ideally, after scaling the new stack shape should be
176, 611, 392.

In the output [16], it’s remapped roi coords, of 21 planes. The
orientation is transformed correctly. That’s why the number is
reverted in all axes. However, the coords should start from 0 to 175
for the z axis, which means all rois are shifted by 1 unit of
resolution.

Attention: to morphing your data correctly, both issues should be fixed! Fix the stack issue by set the correct scaling
factor rather than transfer resolution directly, Fix the coords issue by minus 1 unit of resolution!

[adamltyson]

Thanks for raising this @Timbrer. In future please just post the text into the issue itself and ideally also post code as text (not a screenshot). This makes it much easier and quicker for us to look into the issue and reproduce.

[adamltyson]

I don't really fully understand these issues though, could you explain further?

The first issue doesn't seem to be a problem (as far as I understand it). In BrainGlobe, what we mean by resolution would be better termed "voxel spacing". If an array has a shape of (3,3,3) and resolution of (2,2,2) then it has physical size of (6,6,6). There aren't only two gaps of 2um, each point represents a voxel (2,2,2) in size. As far as I understand it, brainglobe-space is doing the correct thing here. I may be misunderstanding either what's going on in the software, or your specific point though.

I'm afraid I don't understand the second issue.

Reading between the lines, I think there may be a problem applying (otherwise valid) assumptions for manipulating volumetric arrays to manipulating coordinates in the same space. From this description though, I find it hard to pinpoint exactly what we need to do.

Lastly, I would like to ask you to refrain from instructing us to fix things. This is an open source project with limited resources, and any support offered is on a best-effort basis (nobody is employed to maintain this repository). We will try to fix bugs, but we cannot address every issue.

[Timbrer]

Thank you so much for your reply and thanks for writing this package. I am glad that I have this tool in my research rather than writing everything from the beginning :)

I list 2 issues that only related to the practical usage of imaging data.

In the first case, the scaling assumes the brain stack contains averaged value for each voxel. However, in the imaing experiments (2-photon etc), a brain stack usually starts from the shallowest image plane to deepest image plane. Therefore, if the plane gap is n um, the whole imaging depth of (m+1) planes should be n*m. The boundary situations should be considered especially when the gap of imaging planes are large. I think I misunderstand the original designing purpose for this pacakge, it designs for voxelized data, each value in the brain stack should be the average of a voxel. However, it would be nice to let people notice this if thery want to use it for imaging data.

The second issue is the coordination systems in this pacakge starts from 1 rather than 0, which is normal in matlab. But in python, the coordination system may start from 0 in many packages.

In summary, I think there is nothing to be modified. But it would be nice to notice it if someone would like to use this wonderful package to analyze imging data. I apologize for the original poor format of this issue reporting.