×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Re:Automatic Offset Calculation

  • Posts: 42
  • Thank you received: 1
I've been using KStars/Ekos for over a year, and I used it to build all my bias, dark and dark flat calibration libraries.  In doing so, I used the gain and offset that I typically use during imaging sessions, which was often gleaned from online commentary.

However, I recently ran into that equipment connection issue in INDI, so I began using a Windows MiniPC running ASCOM.  I really like how ASCOM automatically adjusts the offset for ASI cameras based on the gain, but this wasn't always in agreement with what I had been using in my camera's calibration libraries.  So, I'm going to identify the ASCOM offfset for each of the gains I use and re-generate my calibration libraries to match what ASCOM recommends.

My question to the INDI team is:  Can INDI also auto-compute the ideal offset based on a user-specified gain?  This one feature will help improve imaging sessions, particularly for new hobbyists who don't yet have the discipline to run a checklist three times before pressing the start button.
2 years 10 months ago #71309

Please Log in or Create an account to join the conversation.

  • Posts: 535
  • Thank you received: 109

Replied by Jim on topic Automatic Offset Calculation

This would be very handy.
2 years 10 months ago #71310

Please Log in or Create an account to join the conversation.

Is this a lookup table? or what exactly?
2 years 10 months ago #71312

Please Log in or Create an account to join the conversation.

  • Posts: 220
  • Thank you received: 27

Replied by PDB on topic Automatic Offset Calculation

As far as I know there is no calculation in Ascom, but just a preset (from ZWO) in the ASCOM camera interface.

Paul
2 years 10 months ago #71322

Please Log in or Create an account to join the conversation.

  • Posts: 42
  • Thank you received: 1
I wonder if my experience was somehow based on the ASCOM "presets" in the driver and not any active calculation then. Maybe when I selected the same gain as the preset, it chose the correct offset. My gear is all packed up in the car so I can't check right now. I did find this article on ZWO talking about the presets: astronomy-imaging-camera.com/tutorials/c...in-ascom-driver.html

I also found this CN thread related to how people were calculating the offsets for various gain levels based on the presets:
www.cloudynights.com/topic/542048-gain-a...ngs-for-zwo-cameras/
www.cloudynights.com/uploads/monthly_05_...68100-1493879582.jpg

Better than interpolating those values, adjust offset so your histogram doesn't clip at your commonly-used gain levels:
daleghent.com/2020/08/understanding-camera-offset

I saw another thread that seemed to indicate that offset can very slightly even among the same model camera, so maybe this isn't something that can be calculated after all.  My apologies if I misinterpreted what was happening in my other software, but it's a backup PC that I've only used once or twice.

This could be automated, to automatically calculate the best offset for gain levels from 0 to max in steps of 10... but I personally only use 2, 3 or maybe 4 gain levels for each camera.  I think I'll just go back through and re-characterize my sensors at my common gain levels.
Last edit: 2 years 10 months ago by MountainAir.
2 years 10 months ago #71337

Please Log in or Create an account to join the conversation.

Thanks folks. If there is some lookup table we can incorporate in the driver, then sure we can proceed with this. Can someone assemble such table for the various models?
2 years 10 months ago #71346

Please Log in or Create an account to join the conversation.

  • Posts: 42
  • Thank you received: 1
OK, I fired up a Windows VM with ASCOM to look at the presets but I'm not sure what I'm seeing.

Offset should vary with gain.  I checked two cameras, each of which has a preset for highest dynamic range, unity gain, and lowest read noise.  They are:
  • ASI183MC-Pro
    • Gain 0, offset 10
    • Gain 111, offset 10
    • Gain 270, offset 10
  • ASI294MM-Pro
    • Gain 0, offset 30
    • Gain 120, offset 30
    • Gain 390, offset 30
These fixed offsets are contrary to what I understand about gain & offset.  Then I started thinking this offset value was based on the maximum hardware gain, a common trick for standardizing your calibration library on a single offset -- but when I tested the ASI183 at Offset 10, it was pretty clearly clipping at gain 270.  20 seems decent, 30 seems safer still.  

So, I don't know how these presets are supposed to work.  Maybe I've got some ASCOM driver issue or something, though I did install the latest ZWO ASCOM drivers and it didn't make a difference.

I switched to the native driver for the ASI294MM-Pro and noticed that ASCOM default offset of 30 works great at gain 120 (unity), but is not enough for gain 390.

Then I thought I would try ZWO's ASIStudio software -- maybe they calculated offset automatically?  That didn't expose offset at all, so initially I thought it must automatic... Gain "low" looked good.  Gain "medium" seemed clipped.  Gain "high" was badly clipped.  So, I don't think it adjusts offset at all, and if you can't adjust it manually then it's effectively broken as an imaging application.

This seems like a missed opportunity for camera makers to deliver gain/offset lookup tables with their drivers (in ASCOM you can add your own presets, apparently).  Software makers could provide a "calibrate offsets" button, but this would be best specified by the mfg in a lookup table.  But absent the lookup table, the button in the astroimaging software could take some pictures to calculate a good offset for a given gain (e.g. at Gain 120 it could take 2-second exposures at offsets in increments of 5 or 10 (starting at 5, never 0) until no pixels clip).  This would be a more automated way to do what the human eye can do with a histogram.  Then it could do this for multiple gains.

Another consideration would be to maybe make the default in KStars larger than 8; 30 seems safe, but I'm sure this varies a lot by camera.  I have no idea what a universally "safe" figure would be for all cameras and gains without needlessly affecting dynamic range.

Hopefully someone with more experience imaging and/or with ASCOM can comment on this further.
The following user(s) said Thank You: Eric
Last edit: 2 years 10 months ago by MountainAir.
2 years 10 months ago #71384

Please Log in or Create an account to join the conversation.

  • Posts: 219
  • Thank you received: 41
Yes, offset varies from model to model, but also from camera specimen to camera. So two ASI533MC could have different offset. A lookup table could be valid only if we put there maximum values. It will be better to have a "sensor analysis tool" as sharpcap has. Also, you can perform this analysis by hand:

1. Put the cap on the camera / telescope.
2. Set the desired gain and enable cooling if your camera has the option.
3. Put offset to 0.
4. Take a 30s dark

You can see that the maximum histogram peak is to the left, touching the zero border. This will mean shadow clipping, so you need to increase the offset. Increment offset by 5 or 10 and repeat. Repeat until you can see a gap between the left histogram border and the beginning of the dark frame maximum peak. This will be the optimal offset for your camera at this gain (maximum range and no shadow clipping).

I've performed this analysis on my ASI533MC and a good offset for me is 30 at unit gain. The ASCOM driver for this camera has a backed in value of 70 that is safe from the point of view of manufacturing tolerances, but very high for my concrete sample :).

So if INDI ends having an offsets table defined, I hope that those values will be only recommendation and we can override them.

Regards
The following user(s) said Thank You: Eric, Doug S
2 years 10 months ago #71394

Please Log in or Create an account to join the conversation.

  • Posts: 42
  • Thank you received: 1
Yep, that's exactly what I normally do to determine offset. Just this one time my images were coming out poorly until I realized that I had forgotten to change the default KStars offset of 8, and thus my calibration library needs to be re-shot. I also run all my sensors though SharpCap's sensor analysis, which I occasionally use with the Smart Histogram feature to suggest good exposure lengths when I change cameras or have different sky quality. Great feature, but I don't think it recommends an offset so that's always a separate step. BTW, SharpCap uses the term "brightness" for offset.
Last edit: 2 years 10 months ago by MountainAir.
2 years 10 months ago #71408

Please Log in or Create an account to join the conversation.

  • Posts: 54
  • Thank you received: 4
I am a bit late to the discussion but I read the thread a few days ago and decided to try the method of finding the optimum offset suggested by rbarberac.I set up on the bench an ASI533mc pro osc camera connected to a powered usb hub plugged into an rpi4 running Stellarmate 1.5.8. Communication between a Macbook air and the rpi was by wifi using external antennas on both the mac and the rpi4.First I connected to the Stellarmate by novnc. Using 30 sec exposure screenshots for a 100 offset and 0 offset.P { margin-bottom: 0.21cm }  are attached.As can be seen there is not a lot of movement along the x-axis of the fits viewer.This would indicate that the change in offset is not being applied to the camera although in the indi control panel for the camera it is shown to have changed. Due to my inexperience I suppose I have not set a parameter to a good value or not pressed a tab somewhere. Can anyone suggest where I am going wrong please?Meanwhile I thought about accessing the camera using Kstars on the Mac. Here are the results of a 100 and a 0 offset. In the screenshots attache the histogram can be clearly seen to move along the x-axis of the fits viewer, as expected, allowing optimisation of the offset.The other curious thing is that the frequency and intensity scales in the 2 cases,one using vnc and the other using Kstars on the Mac, are different. Shouldn't these be close in values? What am I missing?My thanks in advance for any suggestions.P { margin-bottom: 0.21cm }
 
2 years 9 months ago #72090
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
So, why a 30 sec dark and not 20 or 45 or 61.472458 sec?
2 years 9 months ago #72092

Please Log in or Create an account to join the conversation.

  • Posts: 54
  • Thank you received: 4
I was following a suggestion of rbarberac from a previous post.
2 years 9 months ago #72102

Please Log in or Create an account to join the conversation.

Time to create page: 1.295 seconds