realtime exposure time adjustment

[lspitler]

Ideally without compromising frame rate (too much), change the exposure time based upon the sky background based on the mode of a central region of the image.

Parameterise as a max/min fraction sky_background_min_fraction sky_background_max_fraction of the full well depth.

Example code here:
https://chatgpt.com/share/67241dac-19ac-800b-aac1-769bc9c66f1e

[MartinCupak]

This will need a bit of experimenting with the driver - test whether it is possible to change exposure time without stopping video capture. Not sure with that.

[lspitler]

Algorithm likely can be adapted from:
https://github.com/AstroHuntsman/huntsman-pocs/blob/develop/src/huntsman/pocs/utils/flats.py#L233

[lspitler]

@MartinCupak it will be hard to do everything with this mode (e.g., maintain high frame rates as video mode goes on/off) the prioritised requirements would be (from to high to low priority):

1. make sure there is enough photons to get useful science data
2. make sure that the source is not saturating - will be hard to figure out where the source is, so how about the criteria should be max(pixel_values) < 0.8 full_well_depth
3. frame rates should be as high as possible, but willing to accept lower rates by not using video
4. willing to accept risk that occasional images are not ideal, so could consider only changing exposure time every time_recalculate_optimal_exposure_time.

[lspitler]

@MartinCupak it seems like autoexposure setting is actually available from the ZWO camera itself when in video mode: https://bbs.zwoastro.com/d/10423-auto-exposure-and-auto-gain-settings

So might be trivial to implement. It would be good to know (and set) what metric they are using. Max pixel value would be ideal.

[MartinCupak]

So it turns out that the in-camera auto trimming of exposure time is working, and yes, it is trivial. There is not much control over it though (eg min/max exposure time, at least in the documented API).
It is also possible to change the exposure time on the fly while the video record is not interrupted.
I have added a simple demo how to use these (commandline options -a and -v).
I have tested it on the DFN camera system with ASI1600 only, as I did not have luck connecting to Huntsman today.
No fancy algorithm to change the exp time, just a simple loop, to verify it is actually doing something.

[MartinCupak]

frame_15_and_21.zip

I was sometimes getting frames that had part of the bitmap darker, part brighter. Not quite sure what was causing that.

[MartinCupak]

Oh, I forgot to mention an important thing - the auto exposure time and variable exposure time modes (user changing exposure time while video is running) does not seem to have any noticeable impact on frame rate.

[lspitler]

@MartinCupak great!! Thanks for the quick implementation. Is there a PR? Or did you just push it through?

I might keep this one open with a note to @lspitler self that we should probably try and understand and ideally adjust the algorithm they've implemented in hardware.

[lspitler]

frame_15_and_21.zip

I was sometimes getting frames that had part of the bitmap darker, part brighter. Not quite sure what was causing that.

These cameras have rolling shutters, so maybe that has somehting to do with it. The 2 examples appear to have a jump at different rows, so it might be a timing thing, where the exposure time change / sensor reset is somehow happening in the middle of a readout??

[MartinCupak]

@MartinCupak great!! Thanks for the quick implementation. Is there a PR? Or did you just push it through?

I might keep this one open with a note to @lspitler self that we should probably try and understand and ideally adjust the algorithm they've implemented in hardware.

Good morning, Lee. there is no PR, it is just a few commits in the main branch.