-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support non-square shaped tiles #15
base: master
Are you sure you want to change the base?
Conversation
paprica/loader.py
Outdated
@@ -46,7 +46,8 @@ def tile_from_apr(apr, parts): | |||
neighbors=None, | |||
neighbors_tot=None, | |||
neighbors_path=None, | |||
frame_size=2048, | |||
frame_size_h=apr.shape(1), | |||
frame_size_v=apr.shape(2), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
given our weird convention of (z, x, y) corresponding to D, H, W, should these be swapped?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or are the frames arrays of shape (frame_size_h, frame_size_v)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So python is (z, y, x) and that corresponds to (z, v, h) so I think v is indexed by 2 and h by 1, am I wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
frames are (z, frame_size_v, frame_size_h), I used v for vertical and h for horizontal to avoid the ambiguity of (x, y, z)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So python is (z, y, x) and that corresponds to (z, v, h) so I think v is indexed by 2 and h by 1, am I wrong?
then they should be swapped -- apr.shape()
should correspond to the stack shape in python. It's just that internally libapr swaps the name of x and y, it doesn't change the data. Super annoying, I know
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I did not remember that pyapr internally remapped the axis, thanks for spotting it!
from the CI tests it seems like there may be an issue with python 3.7 and some dependency? |
Seems like there is an issue with simpleITK, to be checked but I bet it's again allensdk that is poorly maintained. |
Well, python 3.7 is end of life, so many packages are dropping it. We may want to do the same (and include at least 3.10, but preferably 11 and 12 as well) |
For now, I dropped python 3.7, ultimately I think it would be good to drop 3.9 and use the "switch case" feature of python 3.10 and support 3.11 and 3.12. I can't really put time on it right, but might in the future... |
I added the support of non-squarred sensors. I ran the tests locally and they passed. I also try on squarred and non suarred data sets and it worked.