Yes, the question was for rbarberac

Exact exposure time is not relevant once you get some dark signal to look at. I prefer to use 30s but is up to you to use longer or shorter exposures. From your results, I can see clearly two different behaviors. On the first pair of images, I can't see any change, but I don't know if the way the Ekos draws the histogram has some influence. On the second pair you can see clearly how at 0 offset the background is touching the left axis, but at offset 30 there is clearly a gap, so no dark signal is truncate.

My procedure was different: I programmed a sequence increasing the offset on 5 ADU steps from 0 to 70. Take all the pictures and then I opened them on SiriL and zoomed the histogram 10x to look at the profile near 0.

Regards

Two comments here:

You do not need a dark signal for that calibration. What you measure is the noise of the ADC. If you have dark signal in that image, it will shift the whole histogram to the right, and you might end up with a too low offset that clips for short exposures. So I'd rather recommend short(er) exposures for this. For histograms, you need to use logarithmic view to properly judge the proper cutoff.

And, as someone who does this calibration for all his cameras, I strongly second the request to make such a table (only) a recommendation, and not an automatic override (the most important feature of any automatics is the button to switch it off ;^>)

For implementation, I could imagine a (camera-specific) gain-offset table in the sqlite database that can be edited by the user (somewhat similar to the focus offset table for filters). Filling that one with recommendations on first connect might indeed be helpful for many users.

I started a rework of the Observatory module, where I plan to add a tab for sky quality utilities. This calibration tool could go there although it is more related to the sensor than to the sky. I own an Atik Horizon, and while you can choose any combination of gain and offset you want, there are three presets written in the firmware, with increasing gain/offsets paired values. However I observe that Ekos modules are sometimes not consistent in setting the two values at the same time and that some of my frames are clipped when they should not, per exposure batch. For instance, the Align module contains a Gain parameter but no Offset parameter. What happens when we switch from one module to the other needs to be investigated.

-Eric

Eric, is there any chance your sky quality utilities could also utilize locally-saved SharpCap Sensor Analysis result files? My apologies if you are already aware: Dr. Robin Glover's SharpCap can run fairly intensive analysis against each of your cameras. This produces a table of results that you can paste into various sub-exposure length spreadsheets, but the magic is when you point your scope and imaging train at your target and then use the Smart Histogram feature to analyze sky quality and automagically recommend the optimal sub-exposure length.

SharpCap is Windows-only, but the files can be copied and accessed anywhere. N.I.N.A. has the ability to use these SharpCap sensor analysis files, though it does not calculate properly (last night I tried it for the first time and it said my EdgeHD 9.25 needed a 3,573-second exposure).

[Edit: This feature may be better in the Camera module, but still would be useful if available in the Observatory tab since I don't think you'd run it for each target -- not practical.]

Also, I love your suggestion for adding offset to EVERY camera-control interface such as guiding, alignment, etc. I *think* what probably happens is that the last-used offset in the camera module is used in any other modules that use that specific camera, but you're right, if you use higher gain for alignment and focusing it might black-clip like crazy if your offset is still set for a gain of 0.

There are a few algorithms available for optimal sub-exposure calculations, I haven't settled for one in particular yet nor actually implementing a single flavour. It all relies on proper frame statistics being available in the FITS data module, so there will be a review there first.

In terms of importing external data, there is also some work to do in various places. Telescopius schedules is one of the imports registered for implementation for instance. Would you point me to the documentation of the format for SharpCap analysis files?

The next question is how to make use of the imported or calculated data. If it is there as a reference, what do we use it for and where do we use it in Ekos. If we simply store the values in a database-backed spreadsheet, there are better tools than Ekos for this. I plan to have for instance an "auto" exposure value which would refer to the result of such utilities, but that only requires a small set of Ekos options, so there are better ideas such as calibrating periodically.

About the capture settings, yes, that exchangeable block could be a very interesting rework. This is in line with the future sequence wizard of the Scheduler that is waiting for the custom placeholder-based storage path generator being developed (yeah so many things in the pipe).

-Eric