[Issues] MasterFlat missing the overscan correction option

[Ewout M. Helmich]

Hi,

Indeed, in terms of the MasterFlatFrame, what would be wrong is if in 
making the input DomeFlatFrame, the overscan correction method for the 
BiasFrame were 0 and that of the RawDomeFlatFrames was 6. Clearly the 
net effect of subtracting the BiasFrame from the RawDomeFlatFrames in 
that case would result in subtracting the bias level twice. This match 
of overscan correction methods is enforced by the code.

It is our point of view that it is not incorrect to combine a domeflat 
and twilightflat which have been bias-corrected in different ways (as 
long as their BiasFrame and RawFrame overscan corrections match); 
afterall they're both flat-fields normalized to 1 that can individually 
be used to flat-field science images.

Unfortunately the query condition you describe is not unique, you can 
make the same case for any process parameter (SIGMA_CLIP, in the case of 
DomeFlatFrame/TwilightFlatFrame for example). Should we then add query 
options for each process parameter to the DBRecipes? We think that would 
be overkill. However we will add options to specify the filename of the 
inputs (the equivalent of the "raw_filenames" option, present in many 
DBRecipes), which allows you to specify exactly which DomeFlatFrame, 
TwilightFlatFrame and/or NightSkyFlatFrame you want to use.

Regards,
Ewout

heraud at astro.uni-bonn.de wrote:
> Hi John,
>
>   
>> Hi Philippe,
>>
>> It was decided when the overscan correction became a process parameter
>> that
>> the MasterFlatFrame did not require it.  This is because the
>> MasterFlatFrame
>> is derived from reduced calibration frames and not raw calibration frames.
>>     
> yes but these reduced calibration frames (i.e. masterdome and
> mastertwilight) depend on the overscan correction which was chosen to make
> them!
>
>   
>> As there is no overscan correction to be done, the parameter is
>> unnecessary.
>>     
> So it means you don't care if the masterflat is made of a masterdome and 
> a mastertwilight wich were obtained with a different overscan correction?
> Of course the bias level is supposed to be negligable compared to the dome
> and twilight levels but then what is the point of having an OC for dome,
> twilight and masterflat if we don't use it properly?
>   
>> Have you seen any overscan-related issues in your MasterFlatFrames?  If
>> so, what is the nature of them?
>>     
> It is simply not consistent as it is now.
> If there would be a overscancorrection parameter in the masterflat it
> would ensure that it is made from a masterdome and mastertwilight with the
> _same_ OC which seems logical.
>
>
> Cheers,
> Philippe
>   
>> Cheers,
>>
>>
>> -=John
>>
>>
>> On Fri, 18 May 2007, Philippe Heraudeau wrote:
>>
>>     
>>> Hi All,
>>>
>>> The MasterFlat recipe misses the overscan correction option,  which
>>> means it
>>> will pick up the last created master dome and master twilight
>>> indpendant of their overscan correction  parameter.
>>> This should be updated to  be consistent  with the dome and twilight
>>> creation
>>> and avoid using the wrong master dome or twilight.
>>>
>>> Cheers,
>>> Philippe
>>>
>>> _______________________________________________
>>> Issues mailing list
>>> Issues at astro-wise.org
>>> http://listman.astro-wise.org/mailman/listinfo/issues
>>>
>>>
>>> ** ACCEPT: CRM114 PASS osb unique microgroom Matcher ** CLASSIFY
>>> succeeds;
>>> success probability: 1.0000  pR: 24.7929
>>> Best match to file #0 (nonspam.css) prob: 1.0000  pR: 24.7929  Total
>>> features
>>> in input file: 1872
>>> #0 (nonspam.css): features: 1702195, hits: 936244, prob: 1.00e+00, pR:
>>> 24.79
>>> #1 (spam.css): features: 2522998, hits: 1700421, prob: 1.61e-25, pR:
>>> -24.79
>>>
>>>       
>
>
> _______________________________________________
> Issues mailing list
> Issues at astro-wise.org
> http://listman.astro-wise.org/mailman/listinfo/issues
>