Closed taijizhao closed 10 months ago
Hi, @taijizhao I don't know if it's appropriate for me to answer, but I think that is the spec. It stems from the difference of the memory layout and how to specify the address between Matlab and Python. You can refer to the following comment: https://github.com/CERN/TIGRE/issues/191#issuecomment-750699972
Hi, @taijizhao I don't know if it's appropriate for me to answer, but I think that is the spec. It stems from the difference of the memory layout and how to specify the address between Matlab and Python. You can refer to the following comment: #191 (comment)
Thank you very much for the explaination! It is actually not an issue. I am just trying to understand the difference to avoid my mistakes when modifying the code.
Thanks @tsadakane for the link :) @taijizhao let me know if you have more questions :)
First thank you so much for sharing the excellent toolbox! I used the matlab version years ago and now moving to the python version. However, I found that the u and v parameters in geometry are inverted between matlab and python. It seems that for matlab,
256 and 512 represent pixel numbers in width(u) and high(v) respectively, and for python, they are the opposite.
geo.offDetector
has the same behavior. I caused some confusion when I tried to implement Wang's weighting for displaced detector using python. Is there some reason for this design? Thank you very much!Expected Behavior
geo.nDetector[0] and geo.nDetector[1] represent pixel numbers in u and v direction respectively in both matlab and python.
Actual Behavior
set
In Matlab, I got
In Python, I got
Code to reproduce the problem (If applicable)
Specifications