run_astrodriz should record the number of cosmic rays detected in each drizzle attempt

[Vb2341]

Another way of verifying relative alignment could be to count the number of cosmic rays detected in an image, and comparing that to the other astrometric solutions. Since the default astrometric solution (IDC__________) should generally have decent relative alignment, this can be used as a benchmark to compare the other solutions to. After each drizzle attempt, the number of cosmic rays detected in each input image should be recorded in the log file. A large jump in this count could be a sign of bad alignment. Naturally, this only works for datasets where there is overlap between 2 or more images.

Anyway, the code to do something like this is simple:

from astropy.io import fits
from drizzlepac.tweakback import extract_input_filenames

def cr_count(im):
    # Iterate over each extension to get DQ arrays for each chip
    hdu = fits.open(im)
    count = 0
    for ext in hdu:
        if 'DQ' in ext.name:
            count += np.sum(np.bitwise_and(ext.data, 4096))/4096 # Get the number of pixels with CR flag
    return count

def get_cr_count_dict(drz):
    count_dict = {}
    for flt in extract_input_filenames(drz):
        count_dict[flt] = cr_count(flt)
    return count_dict

If the flts are in a subdirectory that is not the current directory, then the path to the subdirectory will have to be prepended. I'm not exactly sure where in the drizzlepac code this should go, but recording this information in the log files is probably sufficient.

[stsci-hack]

If this is to be used as a verification criteria, it would be helpful to have some initial limit that can be used to flag whether or not there is a problem. For example, would a 10% jump in CRs indicate a problem or would it need to be double? Simply recording the computations in the log may be useful for anyone looking at the logs, but a pass/fail indication based on a limit would make it easier for an end user to recognize when there was a recognized problem.

[mcara]

I do not think this is a clear and reliable criterion for alignment. In addition, this requires many drizzle attempts to just check the alignment. This makes this test also inefficient.

[Vb2341]

Multiple checks are already done in the alignment step- in total 3 attempts are done. One for the default solution, one for the apriori solution, and a final check for the aposteriori. This is just another metric for encapsulating information from those tests. It could be true that this isn't a great way of finding subtle misalignments (I'm not sure), but I believe I used this method to previously find issues with some of the apriori solutions, though I don't have that data on hand anymore.

Regarding a limit to determine passing/failing- I think it could be a good idea, but I haven't found enough failure cases yet to nail down a boundary. Synthetically generating bad alignments could work to determine these limits. From some of the recent data I have been able to run myself, it's unclear, as I don't see anything that looks misaligned, and some of the CR counts go up by a factor of 25%.

I'm also not sure if its something more complicated than an a ratio, as going from 10 to 11 CRs is less alarming than 100000 to 110000. For the sake of saving time in the future, the code for a limit could be implemented, but have the limit set to something quite high, until a threshold can be determined.