-
Notifications
You must be signed in to change notification settings - Fork 105
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
Geometry for circular detectors #1449
Conversation
Checking updated PR... No PEP8 issues. Comment last updated at 2019-03-06 14:04:07 UTC |
Could you have a look at the PEP8 failures? See https://www.python.org/dev/peps/pep-0008/ for an overview of the official python style. Most editors have a built in pep8 check, if yours doesnt you can use pytest-pep8 by running (in the odl folder):
I'll review after that's been cleaned up (so the review doesn't get removed by style fixes). |
There are still some issues remaining, @pep8speaks updates its post accordingly. |
Thanks, I did not notice. These problem are not in my code though (except for the last one). Its about splitting the line before or after an operator, it appears that the standards have change, for instance see PyCQA/pycodestyle#513. Should I fix it so that it agrees with the new standards? |
PyCQA/pycodestyle#498 seems to be the latest one, I guess we should update according to this, could you help out with that @JevgenijaAksjonova ? |
Sure |
now it complains about the line break before =( |
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.
Finally I found the time to review this. Sorry for the delay.
The PR looks really good, and I've only got a bunch of minor comments.
Thanks for the review! I have fixed most of the issues, however I have some questions/comments, which I will write next to each issue |
BTW @JevgenijaAksjonova you might want to have a look at e.g. https://docs.scipy.org/doc/numpy-1.15.0/dev/gitwash/development_workflow.html#writing-the-commit-message to get inspiration on how to write commit messages. It's not really a major worry but it helps keep the code organised. |
odl/tomo/geometry/conebeam.py
Outdated
True | ||
>>> np.allclose(geom.det_axis_init, e_y) | ||
True | ||
""" |
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.
@adler-j What do you think? Should we just drop this class and use FanBeamGeometry
only? I'd be okay with that, given that this class doesn't really do anything.
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.
Looking at this again, I think this class isn't needed any more. It shouldn't be lying around just as a name alias.
Can you remove it @JevgenijaAksjonova? That would mean to replace FanFlatGeometry
with FanBeamGeometry
everywhere, and removing the duplicate unit tests.
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.
I am afraid that not all functionality that works for FanFlatGeometry works in general case, for instance FBP. In this case, I think we should live at as is for now.
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.
That's true, but for FBP we could replace the isinstance(geometry, FanFlatGeometry)
checks with isinstance(geometry, FanBeamGeometry) and geometry.det_radius is None
.
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 see
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.
Regarding the tests: I am not sure what to do with test_fanflat_props(shift) and test_fancurved_props(shift). There are some lines which are duplicates, but in general these are two different scenarios.
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.
Well I guess can leave just the test_fancurved_props(), but call it test_fanbeam_props() instead
Less of a worry now after #1471 |
c033887
to
e658e3a
Compare
So, are there any other changes necessary? |
I've created a pull request into your branch that parametrizes the fan beam test to cover both cases of flat and curved detectors. See JevgenijaAksjonova#1 |
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.
Nice work! Now to resolve the conflict with master
you need to rebase. That will also get rid of those PEP8 concerns.
After that I think we can go ahead and merge.
odl/tomo/backends/astra_cuda.py
Outdated
@@ -372,7 +372,8 @@ def astra_cuda_bp_scaling_factor(proj_space, reco_space, geometry): | |||
if isinstance(geometry, Parallel2dGeometry): | |||
# Scales with 1 / cell_volume | |||
scaling_factor *= float(reco_space.cell_volume) | |||
elif isinstance(geometry, FanFlatGeometry): | |||
elif isinstance(geometry, FanBeamGeometry)\ | |||
and geometry.det_curve_radius is None: |
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.
Last little thing: Please use parentheses instead of backslash to continue the line.
odl/tomo/backends/astra_cuda.py
Outdated
@@ -398,7 +399,8 @@ def astra_cuda_bp_scaling_factor(proj_space, reco_space, geometry): | |||
if isinstance(geometry, Parallel2dGeometry): | |||
# Scales with 1 / cell_volume | |||
scaling_factor *= float(reco_space.cell_volume) | |||
elif isinstance(geometry, FanFlatGeometry): | |||
elif isinstance(geometry, FanBeamGeometry)\ | |||
and geometry.det_curve_radius is None: |
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.
Same here
6cbbcfb
to
9e82df6
Compare
So, is everything OK? Can the code be merged? |
odl/tomo/geometry/conebeam.py
Outdated
@@ -307,6 +334,11 @@ def det_radius(self): | |||
"""Detector circle radius of this geometry.""" | |||
return self.__det_radius | |||
|
|||
@property | |||
def det_curve_radius(self): |
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.
Last-minute comment, but part of API, thus important. I think it's better to use "curvature" instead of "curve" since the description of det_radius
is described as "Detector circle radius", and this one as "Detector curve radius". That can be very confusing since a circle is a curve.
So please change det_curve_radius
everywhere to det_curvature_radius
. It is a bit long but much clearer, and also valid for 2D detectors.
After that I'll merge, I promise 🤞
Perfect, thanks a lot @JevgenijaAksjonova! |
Great! Thank you for the code review! |
FanFlatGeometry was renamed to FanGeometry and modified. An additional parameter det_curve_radius was added to allow the usage of curved detectors. A new class CircularDetector was implemented. It can be viewed as re-implementation of existing class CircleSectionDetector with different input arguments and more readable formulas. Next, it is planned to implement new classes CylindricalDetector and SphericalDetector and modify the class ConeFlatGeometry to allow for the usage of curved detectors.