Creation of calibration frames.

APP will automatically perform the proper workflow in this case. You can indeed just load in your masters and lights and let APP do the rest. I would advise to use masters that were created together (so loading in the bias frames, dark frames and flats). Regarding bias frames, I would also advise to not go for the fastest of exposures, but for exposures of about 0.5 seconds each. This is more of a general point these days as that will work fine for basically all camera's.

ps. you do need the darks and bias to have the same camera settings.

I am working on it now, all the camera settings are the same between the dark and bias frames, but after it creates the master bias it is not applying it to the darks before integrating them. There are a few different ways to generate cal frames in my software, I will try another.

I am having no joy whatsoever. I have tried generating 30 second darks and 0 second (They seem to work well with this camera) bias frames both with Voyager and with SGP, all with the same gain and offset. That I can see the master bias is not being used to calibrate the darks before integration into a master dark. I even tried loading some relevant flats in case the process looks for all three.

I can't send a handful of bias and dark frames across can I to see if you can spot any fits header issue or similar that might be preventing the bias/master bias from being applied?

I can if required just continue with my current workflow of creating a master flat using the master bias and otherwise uncalibrated flats, then loading the master flat in an integration using master darks created without master bias, it would just be smoother if I could throw everything at it at once and go.

I've found the asi2600 doesn't need dark frames really, especially if you are dithering. Flats might be needed in your setup, and bias is OK for this chip. Dark flats not the only option as it was for earlier cmos chips.I mix various exposure lengths and process as a single session as the darks are almost ide tical in all cases.

You only need bias to calibrate the flats anyway, app will sort it all out itself.

Small check/query: are your calibration frames labelled correctly from the capture software?  It should not matter if they are loaded correctly in app, it's strange what you see.

Also, when you set 0s, are you sure that translates to shortest exposure, I. E. Data is actually being recorded in the bias frames? If its a true 0s time measurement, it could be a blank? Just a thought. Hope you get it sorted. 

Yes, I have checked that there is data being recorded in the bias frames, and the FITS header tags them as bias, dark or light as it should. I can actually see a readout pattern in the master bias which is very similar to one that is visible in the master dark.

I have found a master dark to be useful in calibration with my ASI2600MC, I have not had the 2600MM long enough to make a call. With good flats that are calibrated with a master bias but no master dark or bias in the integration, the flats act on the bias information contained in the lights and the corners end up brightened a little. A master bias in the integration might help there as well so it is time for some experimentation. A well constructed bad pixel map, flats which were calibrated with a master bias, and the master bias in the integration to remove the bias info from light frames might be just as effective as what I am doing now.

Edit, having just looked at that, APP throws a calibration warning if no MD or MB is loaded and for good reason, milky corners. I am undecided about if I should continue with using darks (If I can't work out why the master bias is not being subtracted from my darks) or just throw a master bias at it and forget about darks. I need to try imaging something really dim to see how really heavily stretched data looks.

@the_bluester

sounds good but strange. If the darks, bias and flats are used as recorded, then APP takes care of the substration, division and calibration. No need to worry about substracting bias twice (from darks and flats), it works quite well.

Possible that the flats are not ideal in terms of ADU with some overcorrecting of the corners. I solved this using higher ADU in my flats so the division into the calibrated lights did not overcorrect.

I have found in my system where there is slight vignetting, i use no darks flats or bias and the light pollution tool takes care of everything. The sony imx571 chip is so consistent that I eliminated darks. My widefield APO has a 44 mm imaging circle, no need for flats (clean optics too). So life is a little easier. With the mak-newt, lpc handles the corners without needing flats.

There are lots of stories and evidence of overcorrecting due to the wrong ADU for flats and dark flat vs bias for CMOS, which causes effects like you see.

The master bias only substracts from the flats, and the darks substract from the lights. The calibrated flats divides into the calibrated light, as you likely know (sorry, I don't know your experience level, apologies if it is repetitive). If MB is subtracted from the darks and also the flats, then it gets subtracted twice which is a problem, but APP avoids that if they are loaded as normal. Probably a flats overcorrection maybe....

What I have found is that the flats (Created with a master bias) correct the field as they should with either of a master dark (Which does appear not to have bias subtracted from the dark frames first) OR with a master bias, so with this camera I can calibrate either way. I have just spent the day shooting a dark library to generate some good quality master darks so I can process some data both ways and see which produces the best result.

I was not using bias at all previously due to the well known issue with the ASI294 not producing useful bias frames, so I had to shoot fixed length flats with that camera and calibrate them with a master dark-flat.

Posted by: @the_bluester

I have just (Finally) received a new mono camera (AN ASI2600MM) and I am in the middle of creating a master dark and master bias library for it.

I thought I had read in the past that if you include a master bias or bias frames with the darks, APP will calibrate the darks with the master bias (Creating it from the bias frames first if required) so the master darks end up containing none of the bias information. I have created master darks both with and without a master bias (Same gain and offset etc) and with and without bias frames, but the resulting master darks are identical, changing from linear to calibrated with a dark frame on screen and the master bias loaded results in no change so the master bias does not seem to be being assigned to calibrate the darks. I previously understood that if the master dark was created using a master bias, you need to use the master bias in the integration as the master dark is missing that information, and conversely if the master dark was created without a master bias, the bias information ends up in the master dark and you should not use one when integrating the lights.

With the 2600MM, bias frames are useful and I am hoping to be able to simply throw lights, flats, master bias and master dark in the pot and have it calibrate out properly. What I had been doing previously was to use the master bias and flats to create a good master flat, then unload the master bias and flats before loading the master dark and light frames. I am hoping to have a smoother workflow.

The three likely things I can see are that I misunderstood the master creation workflow to begin with (I used to have an ASI294MC Pro and bias frames are not useful with that camera so I was not using them in the past) or that the workflow has changed, or I am simply doing something wrong to prevent my MB from being used to calibrate darks. Can I rule out 1 and 2 before I go diving deep on 3?

Hi @the_bluester, @vincent-mod, @cwm2col,

Let me first explain the behaviour of APP since about 2 years now:

• When a MasterDark is created, the bias is never subtracted if you did supply bias/MasterBias when creating the MasterDark. The reason is 100% flexibility and no problems going forward.
• THis MasterDark can be used to calibrate light frames with and without a MasterBias present.
• If a MasterBias is present, the MasterBias is subtracted from the MasterDark dynamically while calibrating your light frames. 😉
• If a MasterBias is not present, the MasterDark is still intact and correct to calibrate your light frames 🙂

So in this way, that MasterDark is always good in workflows with or without a MasterBias. APP is smart in this way.

More than 2 years ago, APP was not yet that smart, and thus a MasterBias (when present) was subtracted from the darks to create a masterbias subtracted MasterDark... Then that MasterDark was only usefull to calibrate lights when you also loaded the MasterBias. If you did not load the MasterBias, it would lead to problems.

So, for about 2 years now, you don't need to concern yourself with creating a MasterBias subtracted MasterDark, because APP will not do this becaus it will only lead to problems later... Whether you load a MasterBias or not, that MasterDark is always good now. If you load a MasterBias, APP will dynamically subtract it from the MasterDark when calibrating your lights 😉

Please let me know if this is 100% clear.

Mabula

Posted by: @the_bluester

I am having no joy whatsoever. I have tried generating 30 second darks and 0 second (They seem to work well with this camera) bias frames both with Voyager and with SGP, all with the same gain and offset. That I can see the master bias is not being used to calibrate the darks before integration into a master dark. I even tried loading some relevant flats in case the process looks for all three.

I can't send a handful of bias and dark frames across can I to see if you can spot any fits header issue or similar that might be preventing the bias/master bias from being applied?

I can if required just continue with my current workflow of creating a master flat using the master bias and otherwise uncalibrated flats, then loading the master flat in an integration using master darks created without master bias, it would just be smoother if I could throw everything at it at once and go.

@the_bluester, you can throw everyhting in at once, because APP is 100% smart here. Just don't worry about that masterdark still containing the bias signal + sensor offset, because we implemented this to make APP smarter and to give you a masterdark that will work in any workflow.

A MasterFlat can only be created properly when the flats are subtracted with bias and/or darkflats. If you create a masterflat from flats without loading bias/darkflats it will not work. And it is technically incorrect to subtract a masterbias/masterdarkflat from a Masterflat because flats (bias/darkflat subtracted) need to be normalized individually before the masterflat is integrated. That normalization process is very important and it will not work properly if the flats are not bias/darkflat subtracted.

Mabula

@the_bluester,

To conclude, if you load at the same time:

• flats
• bias with same sensor gain and offset as flats to calibrate flats
• darkflats with same sensor gain and offset and same exposuretime as flats to calibrate flats
• lights
• darks with same sensor gain and offset and exposure time as lights to calibrate lights
• bias with same senor gain ond offset as lights to calibrate lights

It will all work as expected 🙂 the MasterDarkFlat will be dynamically subtracted with the MasterBias to create a correct MasterFlat, and the MasterDark will be dynamically subtracted witht the MasterBias to correctly calibrate the Lights with a MasterDark, MasterBias and correct MasterFlat.

Whatever calibration workflow you use, you can always load all frames at the same time and go the 2) Calibrate to create all Masters correctly. If you get a calibration warning, it is because you are running a calibration workflow that can never work properly, hence the warning 😉

Mabula

Thanks Mabula, The first post there cleared it up for me perfectly, I was not aware of the change to the master bias not being subtracted in creation of a master dark, to be honest I might have missed that change even if I read it in a changelog. Until I bought the ASI2600 bias frames were not useful to me (As I had an ASI294 which does not generate useful bias frames) so I would probably have skimmed over it.

At least now I know I wasn't doing anything wrong, just a change in expected behaviour of APP that I had missed.

@mabula-admin Thanks for your clear answer.  Anyway, I'm just curious that in what situation do you really need the Bias frame whereas it already embedded in the MasterDark.

And how about the BPM?  Is it subtracted from the MasterDark /MasterFlat when created?   Do I need the BPM along with the MasterDark/MasterFlat for calibrating the Light, or I don't need it as it didn't subtracted from the MasterDark/MasterFlat?

Hi Suwat @muangmuk,

Anyway, I'm just curious that in what situation do you really need the Bias frame whereas it already embedded in the MasterDark.

Bias frames would still be necessary for calibration of your flats unless you provide darkflats for them 😉 Just keep in mind that if you use flat frames, you will need

• bias or darks to calibrate lights (to subtract the sensor offest and bias/dark current signal )
• bias or darkflats to calibrate flats (to subtract the sensor offset and bias/dark current signal)

The Bad Pixel Map or BPM is not subtracted from anything. It is a defect map of your camera's sensor indicating hot and cold pixels. The BPM will make sure that these faulty pixels are corrected using surrounding well behaving pixels. The BPM should always be included in any calibration workflow because it will not never harm your results, it will only improve the results.

Please let me know if this is clear 😉

Mabula

@mabula-admin Thank you for your clear answer.