-
Notifications
You must be signed in to change notification settings - Fork 29
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
ImageData.zoom_image() size orders #812
Comments
duplicate or similar to #791. we do need to sort this out of course. |
@KrisThielemans yes indeed, I already linked it in the issue. Did not realize it was a similar thing until after I posted it. |
@AnderBiguri could you have a look at this to see if this is required for v3.0? I can't remember... |
I think this is closed with #791, let me quick test. |
So this is the current stage of this:
returns
I still think this is confusing because of the printing order, but at least the indices correspond to the correct ones, thanks to #791 |
thanks. So is the remaining problem then that |
@KrisThielemans correct. |
I'm very confused after looking at SIRF/src/common/GeometricalInfo.cpp Lines 43 to 49 in b36c1b2
as this seems alright (noting that offset etc are in LPS). @evgueni-ovtchinnikov @ashgillman do you understand what's going on? |
The word 'zoom' implies 'a closer look' so I am not sure what
So, if the array dimensions are swapped around:
|
Strange - can you quickly do:
|
I'm looking at Lines 683 to 699 in 2cd7275
I'm not sure originally why these weren't returning LPS, but I think this is just obfuscating it. We want GeometricalInfo to be always defined and stored in LPS and it should be defined that way when creating the ImageData from a STIR object. Actually, I thought we did do that, and looking at the code, we certainly tried: SIRF/src/xSTIR/cSTIR/stir_data_containers.cpp Lines 589 to 624 in 720ed3d
|
I'm a bit confused by #791 actually, I am currently using SIRF v2.2.0, which is older than that issue, and my geometrical info orders are all correct /except/ for the zoom_images as outlined in this issue. There is no MWE in that issue - I think that the issue here is caused by bb7690e which be reverted. template_PET_raw_path = os.path.join(
examples_data_path('PET'), 'mMR/mMR_template_span11.hs')
template_PET_raw = pet.AcquisitionData(template_PET_raw_path)
template_PET_im = pet.ImageData(template_PET_raw)
print('Template:')
print(' shape:', template_PET_im.get_geometrical_info().get_size())
print(' spacing:', template_PET_im.get_geometrical_info().get_spacing())
print(' origin:', template_PET_im.get_geometrical_info().get_offset())
|
!INTERFILE := |
For #791 testing, can you try this (on your prior version):
Now, it outputs:
I believe that the problem was that
Which is confusing, as you need to pass index [0] to change the first dim, as the third dim to The problem may be that we solved #791 wrong. Instead of changing what |
I am trying to change the geometric info of an
sirf.STIR.ImageData
object.While doing some tests, I tried:
Which prints:
What threw me off is that offset is printed as
(-350, -350, 21.52)
, the variableoff
has valuesoff=(-350, -350, 21.52)
, yet, when I use the last value ofoff
intooffsets_in_mm
, its the first value of the offset that gets changed.This seems just a mismatch of python vs other (C++?) dimension storage issue (
ImageData
is indexed(z,x,y)
). But it creates a strong undocumented inconsistency. I would expect that if I get the offset from an object, then set it to its negative, to return zero, without the need of rearranging the offset variable order.Note this happens with all variables, not only
offsets_in_mm
.I guess this is either the same, or a effect of #791
The text was updated successfully, but these errors were encountered: