Centers of bright objects are black

[rosaliaobrien]

The centers of bright objects are black, even after removing cosmic rays within them. This is possibly due to the subtraction of the ima's from one another during split_ima?

[mgennaro]

Is this behavior observed for objects that don't have CR flagged in their neighborhood? I can see that happening if the drift rate is really high

[rosaliaobrien]

They did originally have CR flags, but the black spots remain after lacosmicx removed them. I am not sure if there were CR flags outside of the boundaries of objects.

The black spots seemed to be in the same area as 256 flags; I added the option for astrodrizzle to ignore 256 flags (here: https://github.com/obrienr2434/wfc3_dash/blob/e0c705bc64c6482dac6dc0c5e4e1b9283673efd8/wfc3_dash/reduce_dash.py#L284), but from what I recall that also didn't help

[mgennaro]

256 is the DQ flag for saturation. This might be reasons you're seeing black centers, because after saturation is reached, those pixels won't be recording any more signal, thus the diffs go to 0 -> dark spots in the saturated centers. CR detection does not have to do with this, and can't fix the 256 problem

[mgennaro]

As for why astrodrizzle doesn't ignore those flags, this might be by design, because the 256 flag does not propagate into the .flt files....checking with @Vb2341

[catherine-martlin]

(@shannnnnyyy - This seems like it may also have to do with the issue that the user with the help question about DASH is having. Sounds like we will want to provide some documentation about this in our final DASH pipeline package.)

[catherine-martlin]

Interestingly, I've been doing some testing on PID 15141 as a user had some questions on that proposal and I found running our current pipeline on a single IMA (idmc01e9q) leads to a drizzled final image where most sources in the image don't have the center missing - in fact only the largest/most saturated source in the corner has this issue.

[Vb2341]

That behavior is odd. If there is any good pixel (i.e. NOT flagged as 256) then that value should be the one used, meaning drizzle should NOT be ignoring the flags. It's possible that the non-256 flagged pixels are being used in the median image (if driz_sep_bits includes 256, then this is true), which causes the unflagged cores (that are good) to be flagged as CRs during the CR rejection step, as the low values from the post saturation cores bias the median. To avoid this, I think it would make sense to NOT include 256 in either driz_sep_bits or final_bits. If they are already excluded, then something odd is happening indeed...