-
-
Notifications
You must be signed in to change notification settings - Fork 54
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
Fix bounding box "rounding" #84
Conversation
@larrybradley - Thanks! You put this:
Is this the same?
If yes, I think I would slightly prefer it. Another question: should we really have a test for |
For non-negative
Negative values in the bounding boxes can occur if the region is only partially on the image. The |
I'm not actually sure. |
+1 to remove that test and then merge. |
c31236a
to
c0bfc86
Compare
@cdeil Done! |
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'm merging this now.
@larrybradley - Should we leave the 0.5 rounding example in the docstring or also remove that?
We can always take it out in master
@cdeil I removed the 0.5 rounding example in |
This PR is a followup to #81, which used the
round
function. We don't want to useround
to compute the bounding-box edges because of its behavior at half-pixel values. For such casesround
(in Python 3) rounds to the nearest even number, e.g.round(0.5) = 0.0
butround(1.5) = 2.0
. That behavior may make sense in a statistical sense, but it's incorrect here for computing bounding box edges.In this PR, I use what I implemented in my refactor of
photutils.aperture
:which "rounds" consistently for the bounding box edges.
Also note that the above behavior changed for Python 3. In Python 2,
round
would always round away from zero, e.g.round(0.5) = 1.0
andround(1.5) = 2.0
. This is yet another inconsistency that we want to avoid (and another reason whyround
should not be used).