search

spacetelescope / wfc3_dash

Tools for reducing HST/WFC3 DASH observations.
1 stars 5 forks source link

Centers of bright objects are black #37

Open rosaliaobrien opened 5 years ago

rosaliaobrien commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

(@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 commented 5 years ago

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 commented 5 years ago

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...