Runtime of resample step in drizzle

[stscijgbot-jp]

Issue JP-3902 was created on JIRA by Timothy Brandt:

The runtime of the resample step in drizzle can be improved by reverting to the previous area function called "boxer" in drizzlepac, so long as we compute the slopes and signs of each interval once and re-use them over pixels.  This simplifies logic, removes branching, and reduces the number of floating point divisions per quadrilateral to eight (two for each vertex) over the implementation in drizzlepac.  Testing this on the JWST imaging demonstration notebooks at https://github.com/spacetelescope/jwst-pipeline-notebooks finds that the runtime of the resample step within drizzle is 2/3 as long as before.  The final, drizzled images differ at the level expected from floating point roundoff error (nanstd is a few 1e-10 times nanmedian).

[stscijgbot-jp]

Comment by Timothy Brandt on JIRA:

Addressed by spacetelescope/drizzle#175

I have not removed the new compute_area function, nor have I added tests for the old, reworked functions.  I suspect those can be found in previous versions and readily adapted.

[stscijgbot-jp]

Comment by David Law on JIRA:

Tyler Pauly Tim and I have been discussing how he believes there are runtime gains to be had in the drizzle code, and I asked him to open this ticket and associated PR to start the conversation.  I'm considering this a potential 'Standard' priority code maintenance ticket and sending it your way.  Would be useful to know what the drizzle experts think.

[stscijgbot-jp]

Comment by Timothy Brandt on JIRA:

Thanks, David Law and Tyler Pauly. This represents a reversion to previous logic and structure, but with cleanup, reduced branching and logic, the removal of an assert statement that I do not believe should have been there, and the caching of intermediate values. The exact same modifications can be made to drizzlepac for the same results.