-
Notifications
You must be signed in to change notification settings - Fork 14
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
Initial transliteration of RawImage to an Eigen backend. #364
Conversation
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.
Added some more comments.
ded6844
to
abd9986
Compare
5c3c1ab
to
8c19e4b
Compare
Ok, I've redone the New:
Old
This and I'd also point out the I also think it's rather interesting how context kind of already sets what a method should take - an Does this look better to you? |
This approach looks good to me. I agree with your thoughts on |
0090fd9
to
348d1f7
Compare
…2. Remove unused centered_block with no edge-checking.
Moved everything back to private attribute. Added previously removed getters and setters. Added bindings for new getters and setters. Added bindings for Index. Add tests for Eigen Raw Image.
348d1f7
to
9a14c27
Compare
float y; | ||
float x; | ||
|
||
const Index to_index() const { return {(int)(floor(y - 0.5f) + 0.5f), (int)(floor(x - 0.5f) + 0.5f)}; } |
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.
This is assuming that the center of the pixel is (0.5, 0.5), correct? You had mentioned changing this assumption to be consistent with other approaches (although I can't remember which... maybe astropy?).
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.
Yes, the line in question is the one in stamps. This makes us consistent with both the Rubin stack and AstroPy I believe.
auto [corner, anchor, h, w] = indexing::anchored_block({(int)p.y, (int)p.x}, radius, width, height);
src/kbmod/search/geom.h
Outdated
// range is inclusive of the first element, and can not be longer than start | ||
// minus max range | ||
int length = end - start + 1; | ||
length = std::min(length, max_range - start); |
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.
Can this actually happen? It looks like it is covered with the mins and maxes above.
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 think this is a bit confusing because when start is 0 - we count that as an element, but when start is something like 7 and end is 10, then the length is just end-start
.
Removing it will break a test in test_geom.py
- but because that's the new functionality we've just added we can just remove this and fix the tests. It's a matter of what we decide the method should behave as. I'm seeing something is off (or confusing at least) regarding the range in the tests but left it as is to make progress. Have to revisit, would appreciate a sanity check.
@@ -248,19 +249,32 @@ void StackSearch::fill_psi_phi(const std::vector<RawImage>& psi_imgs, const std: | |||
|
|||
psi_vect->clear(); | |||
psi_vect->reserve(num_images * num_pixels); | |||
phi_vect->clear(); | |||
phi_vect->reserve(num_images * num_pixels); |
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.
psi_vect and phi_vect are both initially passed as size 0. The motivation of the reserve was to avoid a bunch of small copies during array doubling. Since we know the final size, we can preallocate the full vector at the start.
Either way, we should say consistent with psi_vect
and phi_vect
: preallocate both or neither.
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.
It makes no sense to remove these lines, my mistake - not sure what happened. Restored
src/kbmod/search/stack_search.cpp
Outdated
@@ -280,7 +294,8 @@ std::vector<float> StackSearch::create_curves(Trajectory t, const std::vector<Ra | |||
/* Do not use get_pixel_interp(), because results from create_curves must | |||
* be able to recover the same likelihoods as the ones reported by the | |||
* gpu search.*/ | |||
float pix_val = imgs[i].get_pixel(t.x + int(times[i] * t.vx + 0.5), t.y + int(times[i] * t.vy + 0.5)); | |||
Point p({t.y + times[i] * t.vy + 0.5f, t.x + times[i] * t.vx + 0.5f}); |
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.
This is orthogonal to this PR, but I think we should clean up the inconsistencies sometimes shifting the trajectory positions by 0.5 and sometimes not.
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.
Right. Best guess here is that this used to be a part of a for loop or something and the someone noticed rounding is sometimes funky, added 0.5 in. This 0.5 is now "extra" because the context was that origin was in each pixel or something like that. We should either shortcut this directly make sure Trajectory
returns Point
and Point.to_index
does the correct rounding.
src/kbmod/search/raw_image.cpp
Outdated
// replaced by | ||
// Eigen::Index, i, j; | ||
// array.maxCoeff(&i, &j) | ||
// Not sure I understand the condition of !furthest_from_center |
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 all for getting rid of furthest_from_center
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.
Cleaned up the comments, leaving to remember to open an issue.
Consistently handle all the various Cartesian vs indexing notation. Add tests for structs and functions in geom.h. Add bindings for missing functions. Improve bindings for Index and Point. - add comparison operators for Index==Index and Index==tuple - add comparion operators for Point==Point and Point==tuple - add casting to numpy structured arrays. - add constructors for Point Improve AnchoredRectangle: - rename to Rectangle - add constructors to enable use as Rectangle - anchor is a consequence of how we treat stamps (2r+1) and can be generalized, but that's a different PR. Treat that as implementation detail for now. Add comments, improve code readability. Clang and flakify.
26e7fd1
to
3462cd5
Compare
I'm a little bit confused by this error. On Baldur it returns
On bendis though:
Not sure where the difference comes from. I'll investigate more, but do you have an idea? |
I haven't seen a different like that before. What point of the code do those come from? |
https://github.com/dirac-institute/kbmod/actions/runs/6701639278/job/18209372552?pr=364#step:8:36 Test search, pixel_off_chip. Pretty consistently tests pass on baldur (by which I mean I haven't had them fail yet), but they also pretty consistently (which means: every time) fail on bendis. Cuda 12, gcc and g++ is some version of 8.5 on both machines. Bendis uses 1080, baldur two 2080 Ti's so drivers and nvcc subversions are different. |
Search produces 3 nearly identical results to within a pixel. Different gcc/g++/nvcc versions sorting algorithm produce different sorting of the results. This is version dependent as they are all correctly sorted, as per the likelihood which is equal for the results.
I'm not super happy with the |
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.
Looks good. A few small comments.
// it makes no sense to return RawImage here because there is no | ||
// obstime by definition of operation, but I guess it's out of | ||
// scope for this PR because it requires updating layered_image | ||
// and image stack |
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.
Good point. In a later PR we can change this to return the Eigen matrix.
Fix spelling mistake in geom_docs Co-authored-by: Jeremy Kubica <[email protected]>
Draft PR for discussion purposes.
vector<float>
image array withEigen::Matrix<float, Eigen::Dynamic, Eigen::Dynamic, Eigen::RowMajor>
The challenge in interpreting what are the cases processing methods are handling is probably the hardest part of the transition to Eigen. Many implementations either accrued some hidden deep knowledge about non-obvious edge-cases or are vestigial remnants of a debugging expedition that were never cleared out - it's hard to say.