Skip to content

JP-3997: Enable interpolation in pixel map creation for imaging data in resample#10137

Open
emolter wants to merge 18 commits intospacetelescope:mainfrom
emolter:JP-3997
Open

JP-3997: Enable interpolation in pixel map creation for imaging data in resample#10137
emolter wants to merge 18 commits intospacetelescope:mainfrom
emolter:JP-3997

Conversation

@emolter
Copy link
Collaborator

@emolter emolter commented Jan 13, 2026

Resolves JP-3997

Closes #9440

This PR updates calls to gwcs_blot during resampling of imaging data to take advantage of interpolated computations made available by spacetelescope/stcal#488. Spectroscopic data are not affected.

I have confirmed that this change meaningfully improves runtime.

For a tiny (3-image) subset of the large mosaic program jw04111, the time spent in calc_pixmap went from 6.6 seconds on main to 0.8 seconds on the PR branch. In this case, calc_pixmap was not the rate-limiting step - overall runtime of calwebb_image3 went from 120s to 113s, a 5% decrease.

For a larger (~30-image) subset of the same program, the time spent in calc_pixmap went from 123 seconds on main to 14 seconds on the PR branch. The fractional runtime gain of calwebb_image3 was more substantial, going from 530s to 430s, a 20% decrease.

I'd anticipate that the fractional gain here will become larger for bigger mosaics, although I don't really feel like waiting for the full many-hundreds-of-images dataset to run through.

Tasks

  • If you have a specific reviewer in mind, tag them.
  • add a build milestone, i.e. Build 12.0 (use the latest build if not sure)
  • Does this PR change user-facing code / API? (if not, label with no-changelog-entry-needed)
    • write news fragment(s) in changes/: echo "changed something" > changes/<PR#>.<changetype>.rst (see changelog readme for instructions)
      • if your change breaks step-level or public API (as defined in the docs), also add a changes/<PR#>.breaking.rst news fragment
    • update or add relevant tests
    • update relevant docstrings and / or docs/ page
    • start a regression test and include a link to the running job (click here for instructions)
      • Do truth files need to be updated ("okified")?
        • after the reviewer has approved these changes, run okify_regtests to update the truth files
  • if a JIRA ticket exists, make sure it is resolved properly

@codecov
Copy link

codecov bot commented Jan 13, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.33%. Comparing base (bbf1e5f) to head (68ee77d).
⚠️ Report is 79 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #10137      +/-   ##
==========================================
- Coverage   85.98%   85.33%   -0.65%     
==========================================
  Files         368      370       +2     
  Lines       38457    39132     +675     
==========================================
+ Hits        33066    33393     +327     
- Misses       5391     5739     +348     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@emolter
Copy link
Collaborator Author

emolter commented Jan 14, 2026

initial regtest round https://github.com/spacetelescope/RegressionTests/actions/runs/21000948898

The five failures all look very small.

It is unclear why test_nirspec_mos_spec3 and test_nirspec_fs_spec3_moving_target were affected. Although those differences are small, we did not expect to touch spectroscopic data - will investigate. These are also present in regression tests of Tim's stcal PR branch pointing to jwst main, so I'll investigate those on that ticket instead. It's not a bug with the way the jwst side of things is implemented.

test_miri_image3_i2d differences are only in the weight array, only in 4 pixels, and at the 0.2% level.
test_fgs_image3[i2d] differences are only in the weight array, only in 3 pixels, and at the 0.02% level.

@emolter emolter added this to the Build 12.3 milestone Jan 15, 2026
@emolter emolter requested review from t-brandt and tapastro February 11, 2026 16:16
@emolter emolter changed the title Jp 3997 JP-3997: Enable interpolation in pixel map creation for imaging data in resample Feb 11, 2026
@emolter
Copy link
Collaborator Author

emolter commented Feb 11, 2026

new round of regtests after merging and okifying the stcal PR: https://github.com/spacetelescope/RegressionTests/actions/runs/21924519427

@emolter emolter marked this pull request as ready for review February 11, 2026 21:55
@emolter emolter requested a review from a team February 11, 2026 21:55
@braingram
Copy link
Collaborator

Based off #9440 (comment) shouldn't these be optional step parameters that INS can test and then chose to enable via pars files?

@emolter
Copy link
Collaborator Author

emolter commented Feb 11, 2026

As I stated at spacetelescope/romancal#2136 (comment) I'm not particularly happy with doing it that way. I had not realized that David had specifically requested this though, and I guess what he and @tapastro say goes.

Copy link
Member

@mcara mcara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also suggest updating stepsize and order to pixmap_stepsize and pixmap_order to keep this in agreement with changes in stcal and romancal.

Comment on lines 214 to 215
stepsize=1,
order=1,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this hardcoded to use the full (not "sparse") pixel map?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same reason as above re spectroscopic data, although if we do indeed make all the parameters available at the step level then I suppose users will be able to decide if they want to turn it on

Comment on lines 514 to 515
stepsize=1,
order=1,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this hardcoded to stepsize=1?

Copy link
Collaborator Author

@emolter emolter Feb 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is only used for outlier detection of spectroscopic data. In talking with Tim and others earlier we had initially decided not to attempt this for spectroscopic data. Has that changed? If so, I'd be happy to modify this.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think we probably shouldn't attempt the speed up for resampling spectral data without further study.

Copy link
Member

@mcara mcara Feb 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought it was disabled because when testing it with the original version of the stcal PR that did not account for the bounding boxes of spectral images it resulted in all NaN pixel maps - see my comment in spacetelescope/stcal#488 (comment) This, however, has been fixed.

@emolter
Copy link
Collaborator Author

emolter commented Feb 12, 2026

https://github.com/spacetelescope/RegressionTests/actions/runs/21959536402

All passing as expected, since this is not on by default

@emolter
Copy link
Collaborator Author

emolter commented Feb 12, 2026

The last few commits should have addressed comments from @mcara and @braingram. Talking with @tapastro and @drlaw1558 , we are indeed going to make these parameters available at the step level for imaging data, and request for the INS teams to test them out for a build or two before turning this on by default.

Interpolation is only performed if ``pixmap_stepsize > 1``. Default is 1.

pixmap_order : int, optional
Order of the pixel map interpolation used. Default is 1.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Order of the pixel map interpolation used. Default is 1.
Interpolating spline order for pixel map computation. Default is 1.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 68ee77d

Comment on lines 273 to 276
pixmap_stepsize : int, optional
Step size for pixel map interpolation during resampling.
Larger step sizes result in faster performance at the cost of accuracy.
Interpolation is only performed if ``pixmap_stepsize > 1``. Default is 1.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

stepsize is not required to be integer.

Suggested change
pixmap_stepsize : int, optional
Step size for pixel map interpolation during resampling.
Larger step sizes result in faster performance at the cost of accuracy.
Interpolation is only performed if ``pixmap_stepsize > 1``. Default is 1.
pixmap_stepsize : float, optional
Indicates the spacing at which WCS is evaluated when computing pixel map. WCS coordinates of the full pixel map is computed by interpolating over this sparse pixel map when ``pixmap_stepsize > 1``.
Larger step sizes result in faster performance at the cost of accuracy. Default is 1.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 68ee77d

enable_err = boolean(default=True) # Compute and report the err array
report_var = boolean(default=True) # Report the variance array
pixmap_stepsize = integer(default=1) # Interpolation step size for pixel map; interpolation is used for stepsize > 1
pixmap_order = integer(default=1) # Order of the pixel mapping polynomial fit, must be 1 or 3
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
pixmap_order = integer(default=1) # Order of the pixel mapping polynomial fit, must be 1 or 3
pixmap_order = integer(default=1) # Spline order for pixel mapping, must be 1 or 3

First, it is not a "fit" - it is interpolation. Second, "polynomial" is too general, for example piece-wise polynomial interpolation is generally different from spline (which guaranties interpolating function smoothness when order>1).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in a6f5693

@@ -0,0 +1 @@
Add ``pixmap_stepsize`` and ``pixmap_order`` parameters to allow interpolated calculation of pixel map for imaging mosaics; improves runtime of calwebb_image3 by 20 percent for a 30-image mosaic tested, with bigger improvements expected for larger mosaics.
Copy link
Member

@mcara mcara Feb 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with bigger improvements expected for larger mosaics.

I’m not fully convinced that larger output mosaics will translate into additional speedups. Since WCS evaluation cost mainly depends on the size of the input images, the practical improvement is still limited to about stepsize**2 (minus spline overhead) - and pixel map computation is only a fraction of the total resample step. Unless JWST cal images become larger, we may not see further gains. It might be helpful for each instrument team to identify the largest stepsize that preserves scientifically valid distortion behavior and include those recommendations in the calibration reference files.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair, I think it's probably sufficient to just quote the single test I did here, without additional commentary

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed in a6f5693

@@ -0,0 +1 @@
Add pixmap_stepsize and pixmap_order parameters to allow interpolated calculation of pixel map for imaging mosaics when resampling
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Add pixmap_stepsize and pixmap_order parameters to allow interpolated calculation of pixel map for imaging mosaics when resampling
Add ``pixmap_stepsize`` and ``pixmap_order`` parameters to allow interpolated calculation of pixel map for imaging mosaics when resampling

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be fixed in a6f5693

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support faster pixel coordinate computations for mosaics

4 participants