coverage: 37.72% (+0.01%) from 37.706%
when pulling 7bb741d on cosmic_psf_parameters
into b83c3d0 on main.

I have fine tuned some of the parameters to further reduce the number of arc lines that have pixels masked as cosmic. Comparing between the darks processed with old psf parameters, there is a 1000-1500 pixel discrepancy in the number of pixels masked. This seems to be that the new parameters can't fit the tails as well. Below is a comparison where the difference shows the pixels not being masked by the new parameters.

I need to check if this is actually the old code overfitting the cosmic rays.

@jbanovetz it looks like you haven't pushed your updated coefficients to github, i.e. the ITL r coefficients are still the same as b. Please confirm.

I added the new numbers this morning and have been investigating the differences between the old and the new parameters. It looks like the difference in pixels is due to the old parameters masking a little more than the new. I verified this with ds9 and visual inspection. I also compared this to an on-sky image. There is about a 5000 pixel difference in the cosmic mask plane between the old and the news and about 2 cosmic rays missed, which I am going over with visual inspection now.

There were also a lot of failed tests when committing the updates. Looking into these, it looks like some issues with pip and desimodel and desi target.

Looking at a preprocessed science exposure (316245), almost all of the extra pixels come from the tails. I think the old psf parameters were causing extra tails to happen. Below are a few of examples showing the cosmic ray mask with the old psf parameters on the left, the new psf parameters in the middle with the flux values shown as integers (in electrons), and the right highlighting the difference between the masked pixels. The middle figure has the masked pixels (in this case will be bad pixels) set to zero which might cause some discrepancies looking between the two data sets.

Looking at the flux values, they are all in family with the surrounding pixels.

The two missing cosmic rays are also accounted for. The first is a hot column that is masked that have 3 pixels peaking through:

The second is part of a fiber that is masked as it might be unluckily not psf-like:

Updated params look good; I spot checked amp A of arc 20251027/318367 and dark 20251027/318359.

I also fixed the if/else logic because the original version would never have set psf_gradients for the case that "CCDTYPE" was in img.meta but it wasn't an ITL device. I don't think we have any headers like that currently, but we easily could in the future.

I am also attempting to fix the github test setup due to pip/25.3. If it doesn't work quickly I'll punt and merge anyway. That issue is tracked in desihub/desitarget#862.