Investigate possible replacements for opencv functions in jump step

[stscijgbot-jp]

Issue JP-3120 was created on JIRA by Howard Bushouse:

As originally documented in JP-3109, the use of "opencv-python" functions in the snowball/shower correction added to the jump step has caused some dependency issues for external users (although not very many) and also just adds yet another dependency to the jwst package. Hence we'd like to explore solutions to this, either in the form of finding a way for external users to be able to reliably install that package or find equivalent functions from existing dependencies (e.g. astropy, scikit-image, etc.) to replace the opencv functions.

[stscijgbot-jp]

Comment by Howard Bushouse on JIRA:

From Zach Burnett :

Possible options going forward:

restore opencv-python to a hard dependency in setup.cfg - this would break some users' workflows, but perhaps they can move to a platform that has built binaries, or figure out how to build opencv-python on their own

use a less-heavy dependency

spacetelescope/stcal#138 scikit-image and shapely can perform similar functionality; however, the resulting snowball masks are slightly different

Alternatively, we could use astropy.regions:

Astropy regions can do this easily. You can make ellipses and circles and then export them as pixel masks. And also interface with shapely if needed.
#7409 (comment)

use binary operations instead of ellipse / circle fitting:

Perhaps going too far, a much simpler approach would be to not fit circles and ellipses at all (which can lead to fitting errors and masking half the image), but to use scipy.ndimage.binary_dilation instead. Just grow regions. And select regions of a minimum area to grow using scipy.ndimage.binary_erosion. This is vastly simpler and probably more robust. And handles shapes that are not exactly circles or ellipses.

#7409 (comment)

[stscijgbot-jp]

Comment by Anton Koekemoer on JIRA:

This issue was discussed in JWST CalWG Meeting 2023-03-07 and here are the steps forward from that discussion:

• First, Misty and Alicia check back with Mike to obtain a description of the different datasets and tests that he has been running, and ask him to confirm whether or not these tests indicate that it's robust enough to proceed with enabling in the Ops pipeline (when using opencv), also track this discussion in the comments on this ticket please (JP-3109).
• If the above provides sufficient confirmation that the code is robust enough (when using opencv) can then consider re-enabling in Ops
• Then, separately, alongside the above:
  ** Investigate what other fitting routines we can use that are in astropy, scipy, or scikit-image, for doing ellipse-fitting in the same way as is currently done with opencv
  ** If a replacement is feasible, Howard will work with Mike on replacing opencv dependency with the best choice from one of these (astropy, scipy, or scikit-image)
  ** If replacing opencv is not feasible then please indicate that as well

[stscijgbot-jp]

Comment by Michael Regan on JIRA:

I think we need to look at this as cost/benefit issue. Can someone find out how many people had problems and what their problems are? It doesn't make sense to spend resources without knowing what the underlying problem is.

As far as I can tell the number of people having problems is less than five. This implies a non-mainstream OS or an unsupported version.

And the answer is that I tested with NIRSpec darks and MIRI darks. Beyond the unit tests I did a lot of comparisons between the diff frames and groupdq extension to search for false positive and false negative detections of both showers and snowballs. The snowball detection has a very high sensitivity and specificity. For showers the sensitivity is lower (see Build 9.2 for updated version) but the specificity is still high.

[stscijgbot-jp]

Comment by Anton Koekemoer on JIRA:

Thanks very much Mike.

For the SCSB folks Howard Bushouse , could I ask a couple more details (along with Mike's question) if you could let us know please the specifics of the system / OS causing the problem with opencv, from the user reports you received?

(edited to replace "SCSB folks" with a tag to Howard Bushouse who is representing SCSB on the watchlist)

[stscijgbot-jp]

Comment by Zach Burnett on JIRA:

Hello! This issue comes from https://jira.stsci.edu/browse/AL-691

Here are the incidents where external users were unable to install the pipeline due to failure to build opencv-python:

User on MacOS 10.14.6 (Mojave), on a 2.6 GHz Intel Core i7 on Python 3.10:
https://stsci.service-now.com/nav_to.do?uri=%2Fincident.do%3Fsys_id%3D19bd0695973a591023a2fe971153afed%26sysparm_stack%3Dincident_list.do%253fsysparm_query%253dactive%253dtrue%26sysparm_view%3DJWST%26sysparm_view_forced%3Dtrue

Another user (no information on OS version) on Python 3.10:
https://stsci.service-now.com/nav_to.do?uri=%2Fincident.do%3Fsys_id%3Db0b19c6b47b15510ec5b9448436d43af%26sysparm_record_list%3Dactive%253dtrue%255eassignment_group.name%253dPipeline%255ecaller_id.nameSTARTSWITHdavid%2Bnataf%255ecompany%253d%255eORwatch_listCONTAINS67312cd3dbfc4708fb50f9baae9619f2%255eORcompany%253dc3478b5edb013e0042685434ce961951%255eORcaller_id%253d67312cd3dbfc4708fb50f9baae9619f2%255eORopened_by%253d67312cd3dbfc4708fb50f9baae9619f2%255eORDERBYDESCnumber%26sysparm_record_row%3D1%26sysparm_record_rows%3D1%26sysparm_record_target%3Dincident%26sysparm_view%3DJWST%26sysparm_view_forced%3Dtrue

It seems that the issue is limited to only a few users / platforms. We could probably add opencv-python back to the hard dependencies (#7499) until an alternative can be implemented. I apologize for all of the hassle!

[stscijgbot-jp]

Comment by Anton Koekemoer on JIRA:

thanks very much Zach Burnett for the additional details.

Indeed MacOS 10.14.6 is pretty antique, I think Apple stopped supporting it in 2021.

So I agree a feasible path forward is to continue with opencv-python at this time, and that we resolve this issue by placing a statement on the github jwst repo that this particular vintage setup is not supported.

[stscijgbot-jp]

Comment by Zach Burnett on JIRA:

as a status update on this, I do still occasionally get tickets lamenting the inability to install the pipeline on older macOS hardware because of the OpenCV dependency. I have been informing these users that unfortunately they need to update their hardware, or alternatively use Linux, to install the pipeline.

[stscijgbot-jp]

Comment by David Law on JIRA:

I think this can be resolved; the relevant warning statement is on the pipeline installation page, and supporting increasingly-outdated OS versions isn't a priority.  Ongoing jump step revisions exploring a different algorithm may end up resolving this issue anyway though.