BIAS frame issue

[wjlockett]

Hi

Having a problem with Bias frames acquired in AA5.   Noticed in the FITS headers of AA files that BZERO is absent in the short exposure bias frame but present (and set at 32768) in the longer darks and images.  When loading into Pixinsight the bias frames get the 32768 added anyway with obvious consequences!   Simple enough to subtract it again with Pixlemath but is there a way to stop the problem when loading.

Does it matter if substraction is done on the master bias after integration, or on the indiviual bias frames before integration.
 


Thanks

John

[Nocturnal]

Hi,

something I think you should mention to the friendly folks that write AA, if you haven't already

If you average your bias frame it won't matter if you add or subtract a constant to each frame or to the final image. Write down the operation on a piece of paper for a single pixel and you'll see. I think for median it's the same but it's not as obvious. I'm not sure about the other combination methods.

[Harry page]

Hi

I have had this discussion with Fabio and Juan long ago and AA5 is not incorrect , as Juan would say it a fits thingy problem 

Anyway go to format explorer-select fits -mis options-default integer - select " signed integer images store data" this will load up the file correctly

Juan does recommend this is disabled by default

Harry

[Juan Conejero]

I have had this discussion with Fabio and Juan long ago and AA5 is not incorrect

Not exactly. The FITS standard allows to do this, but I think it is an incorrect way to store raw CCD data, which should always be stored as unsigned integers. Even worse when some raw CCD images (bias frames) are being stored as signed FITS images and others (lights, flats, ...) as unsigned FITS images using the BZERO/BSCALE trick. All applications have their idiosyncrasies, but this case is pretty inconsistent.

Anyway the "Signed integer images store raw data" setting allows you to load these peculiar bias frames in PixInsight. A better way that doesn't require you to modify global FITS preferences is  using format hints.  Format hints are special control words that can be used with some PixInsight tools, such as ImageCalibration and ImageIntegration. In this case, you can write this hint:

signed-is-physical

in the input hints parameter of ImageIntegration (Format Hints section) when you integrate your master bias frame.

[Harry page]

Hi
Yes good tip master Juan , did not think about that 

Harry

[wjlockett]

Thanks for your prompt and helpful replies.  I would never have worked that out for myself!

[RBA]

In this case, you can write this hint:

signed-is-physical

in the input hints parameter of ImageIntegration (Format Hints section) when you integrate your master bias frame.

Sorry if I missed it but is there any place where all the possible format hints are described?

[Alejandro Tombolini]

Hi,
Here you have some

http://pixinsight.com/forum/index.php?topic=3118.msg21348#msg21348

Regards,

[RBA]

Sweet, thanks!! I knew I had seen something like that somewhere! It's now bookmarked!

PS: This is what I'm talking about when I mention scattered documentation that could be compacted without much effort. While a "true" image processor doesn't stop in the absence of official, nicely structured and all-in-one-place documentation, a "true" software developer tries to make sure that documentation they produce about their software isn't just scattered all over the place.

...Thought I'd mention it

[Nocturnal]

Really. I think Juan has slight masochistic tendencies. He's been beaten up over (lack of) documentation for so long he'd miss it

Just teasing Juan.

[RBA]

Really. I think Juan has slight masochistic tendencies. He's been beaten up over (lack of) documentation for so long he'd miss it

He's never going to miss it. As it's written, this issue is set to hunt him forever.
IMHO, and sorry for hijacking a thread once again, this is a productivity vs quality vs swiftness issue.

Producing just one set of complete documentation versus a quick one first and a complete one later increases productivity, because you do it only once, and it saves you some explaining to do while the official docs are released.

Producing one set of quick documentation first and a complete one later increases quality in the later because then you take your time to write top-notch official docs, and also furnish them with details gathered from people's questions and feedback while they use the tool before official docs are released.

Producing first one set of quick documentation is driven by giving something to the users quickly, because producing the later more extended and "official" docs will take longer.

I don't care that much which approach is used, particularly since each approach can ensure quality either way, but as it is, the time between the quick docs and the more official docs is long enough to be a dragging issue for the rest of times.