Problem with DQ extension from gsreduce

Home Forums Gemini Data Reduction Problem with DQ extension from gsreduce

This topic contains 2 replies, has 2 voices, and was last updated by  webberm 8 months, 3 weeks ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #1477

    webberm
    Participant

    I am processing long-slit data from GMOS-South (Hamamatsu CCDs) with the gsreduce task, setting the parameter fl_vardq=yes. I have found that good pixels are marked in the DQ extension with a value of 4 and bad pixels (and chip gaps) with 16. I would have expected the good pixels to have values of 0 and the bad to have values of >=1. This causes every pixel in the DQ extension for the extracted spectrum to be labeled as bad, which is wrong. Does anyone know of a solution for this?

    I am running the gemini package v1.13 on Iraf v2.16 through Ureka.

    0
    0
    #1479

    jturner
    Keymaster

    DQ=4 is supposed to be for saturated pixels. Are these flats? Are they definitely not saturated? I’m not sure off hand what would cause that flag to be set erroneously (perhaps some bad header keyword values), but the first thing is to verify the actual rough values.

    Cheers,

    James.

    0
    0
    #1482

    webberm
    Participant

    This problem was on flats, but also on the science and calibration exposures; they were not saturated.
    I have managed to fix this issue by replacing the gemini package v1.13 with v1.13.1.

    Thank you for your input!

    0
    0
    #1570
    Jessicasilva09
    Jessicasilva09
    Participant

    (Awaiting moderation)

    0
    0
Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.