-
Notifications
You must be signed in to change notification settings - Fork 32
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
Add common resample code to stcal. #320
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #320 +/- ##
===========================================
+ Coverage 29.56% 83.63% +54.07%
===========================================
Files 37 52 +15
Lines 8332 9978 +1646
===========================================
+ Hits 2463 8345 +5882
+ Misses 5869 1633 -4236 ☔ View full report in Codecov by Sentry. |
50484f2
to
ebbc003
Compare
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 left a few comments to try and address some of the CI failures.
There are also check-type failures.
I also don't see any tests. Are there tests that can be moved here from jwst/romancal?
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.
Overall it looks fine, but it's being reported that a lot of the code isn't tested by any test. Maybe add tests to get more code coverage.
attributes = { | ||
"data", | ||
"wcs", | ||
"wht", |
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.
Is this short for "weight"? When I see "wht", I think "what". I recommend simply using "weight".
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.
These have direct analogue in the JWST DataModel
. That is why I preserved the name.
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.
Here are a couple of examples:
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 agree with Brett, the major high-level thing I see is that this needs unit tests
int(output_wcs.bounding_box[0][1] + halfpix), | ||
) | ||
else: | ||
# TODO: In principle, we could compute footprints of all |
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 TODO (or any other ones in this code) be removed and if desired, turned into a GitHub issue or JIRA ticket so we can track work still needed?
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 could, but does it make sense to open a ticket to modify code that does not yet exist in the repository?
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's not necessarily my decision but I would say yes, because this is definitely going to get added at some point and it's easier to track issues than code comments
119a118
to
d20777f
Compare
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 overall, most of my comments are surface-level
src/stcal/resample/resample.py
Outdated
'pixmap': pixmap, | ||
'scale': iscale, | ||
'weight_map': weight, | ||
'wht_scale': 1.0, # hard-coded for JWST count-rate data |
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.
Is this okay for Romancal? If not, perhaps now is the time to allow it as a variable
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.
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.
great, thanks for checking. maybe update the comment to say that it was also tested for Roman, otherwise it looks like it may have been accidentally ported over from jwst without additional checking
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.
maybe update the comment to say that it was also tested for Roman, otherwise it looks like it may have been accidentally ported over from jwst without additional checking
I did not test it and I am not aware of this being tested but I assume the resample code was tested as a whole by Roman. I actually do not see under what circumstances wht_scale
would need to be != 1
. I think the comment should be removed as I think units of the data are irrelevant here.
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.
Most of the comments regard utils.py
src/stcal/resample/utils.py
Outdated
|
||
|
||
def compute_wcs_pixel_area(wcs, shape=None): | ||
""" Computes pixel area in steradians. |
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 not happy with this and the following routine. It is I think overly complex and doesn't even explain the methodology of how the pixel area is computed. I gather that it is an average area of pixels over the whole valid image area. But why not simply compute the area of one pixel in the center? If that isn't useful, then it needs to explain why it must be the average. So at the very least this is very poorly explained, in my opinion. Perhaps it can be handled in a subsequent PR if this is urgent. At the very least the docstring should be more descriptive for this PR.
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.
The purpose of this PR is to move code that may be shared by multiple pipelines (JWST, Roman, ...) to stcal
. This PR attempts to preserve how current pipelines work and I do not think this should be modified here.
I'm not happy with this and the following routine. It is I think overly complex and doesn't even explain the methodology of how the pixel area is computed.
I will add a little more documentation.
But why not simply compute the area of one pixel in the center?
We would not need to compute anything if we knew where/how PIXAR_*
were computed and them maybe we could used them directly without computing anything.
I gather that it is an average area of pixels over the whole valid image area. But why not simply compute the area of one pixel in the center?
It is too complicated to describe it here but this came from the ambiguity of how PIXAR_SR
was defined for JWST images. I attempted to provide a longer explanation here: spacetelescope/jwst#7894 (comment) and maybe this: spacetelescope/jwst#7894 (comment)
Further reading: spacetelescope/jwst#7668 (comment) and other comments in that issue.
Perhaps it can be handled in a subsequent PR if this is urgent.
Again, this is code already used in JWST. Please open an issue if you feel this is incorrect.
66f4c33
to
6f4ff5e
Compare
Co-authored-by: Ned Molter <[email protected]>
Co-authored-by: Ned Molter <[email protected]>
1c4b44c
to
6743256
Compare
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.
LGTM
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 left a few minor comments inline, but this looks good, thanks Mihai.
# TODO: if we want to support adding more data to | ||
# existing output models, we need to also store weights | ||
# for variance arrays: | ||
# var_rnoise_weight | ||
# var_flat_weight | ||
# var_poisson_weight |
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.
Do you just need one of these (i.e., for squared kernel terms), or do you need all of them?
xmax = min(data_shape[1] - 1, int(x2 + 0.5)) | ||
ymax = min(data_shape[0] - 1, int(y2 + 0.5)) | ||
|
||
return xmin, xmax, ymin, ymax |
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.
Feel free to ignore, but I'll note that I'm not immediately sure what to make of the usage of whole pixels vs. half pixels. I think I interpret that the bbox has the corners of the pixels, with values like (-0.5, N - 0.5). In that case the mins at int(x + 0.5) make sense, but the maxes at int(x + 0.5) look a bit weird. I might have guessed floor(x + 0.5), ceil(x - 0.5). Of course, there's not a lot of space between int(x + 0.5) and ceil(x - 0.5); maybe just a comment about what the intent is re half / whole 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.
Somehow, github won't allow me to reply separately to each comment.
Do you just need one of these (i.e., for squared kernel terms), or do you need all of them?
I think so. I do not think it needs to be done now, especially that I've heard that Roman is no longer interested in this functionality, but this is something to keep in mind for later only if we will keep current method of estimating variances. If we propagate errors like it was proposed in spacetelescope/jwst#8997 and spacetelescope/drizzle#163, then these arrays are not needed.
the maxes at int(x + 0.5) look a bit weird. I might have guessed floor(x + 0.5), ceil(x - 0.5).
int(x + 0.5)
is the same as int(floor(x + 0.5))
. xmin, xmax, ymin, ymax
must all be integer numbers. If we make a rounding error here, it preferably should be to expand the box, not to shrink it: minor efficiency loss is probably preferable to missing data.
Closes #279
This PR add the common resample code used by both JWST and Roman pipelines to stcal. Also, for the first time, this PR adopts the new
drizzle
API from spacetelescope/drizzle#134 for the resample code used in the pipelines. This PR is a second attempt to #279 and therefore merging this PR should close #279.This work is related to https://jira.stsci.edu/browse/AL-835
Tasks
docs/
pageno-changelog-entry-needed
)changes/
:echo "changed something" > changes/<PR#>.<changetype>.rst
(see below for change types)"git+https://github.com/<fork>/stcal@<branch>"
)jwst
regression testromancal
regression testnews fragment change types...
changes/<PR#>.apichange.rst
: change to public APIchanges/<PR#>.bugfix.rst
: fixes an issuechanges/<PR#>.general.rst
: infrastructure or miscellaneous change