Poseidon-C and Cut-Off Histogram

[MarMax]

Robin,

I'm not sure if this is a camera issue because this is the third time this has happened over the past four years when I'm up at our JCO Darwin dark site property. The first time was with an ASI533MC-Pro (in 2021), the second time was with an ASI2600MC-Pro (2024) and now again with the Player One Poseidon-C camera. What happens is what you see in the histogram.

CutOffHisto.jpg (215.17 KiB) Viewed 1139 times

I started with an offset/brightness of 60, which should be optimum for this sensor. Once I saw the cut-off histogram I re-took darks and flats with an offset/brightness of 80 and it did not help, the histogram looked the same. At that point I gave up and moved on to other things. Please let me know what you need to help troubleshoot this. I may have a FITS stack and have log files. This is running SC version 4.1.14120 on a WIn11 laptop.

Mike

[admin]

Hi Mike,

seeing that particular problem is usually an indication of a mismatch between the darks and lights as you suspected. To be more exact, something has made the dark frames brighter than they should be relative to the light frames, so that over-subtraction is going on. Things to check are

* Exposure and gain are the same between lights and darks
* The value of the offset/black level/brightness control is the same between the lights and the darks
* Similarly colour balance controls should be the same
* You don't have a light leak when capturing dark frames

As an emergency measure if this happens, you can try increasing the value of the offset/brightness in the light frames to move the histogram away from the left hand side. This could work out reasonably in the case that it is the colour balance/offset being mismatched, but will not help in the case of a light leak (which will be a non-uniform brightening).

The best thing to do to investigate this is to check the 'capture settings' files for the light and dark frames to see if any settings were changed that you hadn't planned on changing that could be the cause.

cheers,

Robin

[Jean-Francois]

Hello,

"The value of the offset/black level/brightness control is the same between the lights and the darks"

Are you sure ?
In the case of high light pollution, then the background level of the light image will be higher than the dark.
In this case no problem to do the subtraction.
What if the sky is very dark (or with short exposure) ?
If the background (offset) of both images are the same, then the subtraction will produce negative values, because of the pixel noise.

What I do ? ... (but note not every time):
Set the offset value for the optimal histogram of the dark image.
Take an light image with SharpCap automatic dark subtraction ... and adjust the offset so that the histogram does not clip.
Depending on the light pollution, sometimes not necessary to change the offset.
But in dark site or short exposure, I change the offset value until no clipping of the histogram.

Some image processing software convert the image to a higher bit number to a signed image ... 16 bit unsigned to 32 bit signed.
Then all the processing is done with the signed 32 bit images ... in this case no problem with losing values below zero.
I guess that SharpCap does all the calculations with signed image format.

Regards,
Jean-Francois

[MarMax]

Robin,

Thank you for the reply. I've been using the "Auto gain/exposure" for flat frames and it has worked well at home (B8). The flats taken at the dark site used the "auto" feature so their gain was different than the lights (and darks). I've been led to believe that flat frame gain/exposure does not matter but this must not be correct.

Up until I started using the "Auto gain/exposure" for flats I'd always taken them with the same gain as the lights (and darks). It sounds like I need to stop using the "Auto" feature and go back to my old workflow.

EDITED to say the gain/exposure for the lights did match the darks (there was no mismatch). I've never had a light leak problem with darks using the filter drawer so can't imagine that is the problem.

Also, the cut-off histogram was with the Poseidon-C. The next night I ran the 2600MC-Pro with the same settings (gain 200, offset 60) on a different telescope and the histogram was fine.

Mike

[admin]

Hi Mike,

there is no requirement for the exposure/gain of flats to match lights/darks, and I wasn't trying to imply that.

I still think there was probably something set unintentionally when capturing either the darks or the light frames that led to the over-subtraction.

I wonder if it could have been the colour balance settings... Player One have changed how the colour balance values work *twice* in recend SDK updates - once to a new system and then back again, presumably after everyone complained. I have brought those new updates into various versions of SharpCap and done my best to auto-correct if you have saved a capture profile previously with a different definition of the colour balance controls and then reloaded it into a new version of SharpCap with a different SDK. Unfortunately it was impossible to perfectly correct for this (probably why PlayerOne had to change things back). So, if you have used the colour balance controls in SharpCap, and used saved capture profiles or have SharpCap restore the old settings then this could have been the cause.

cheers,

Robin

[MarMax]

Robin,

Thanks for the flats clarification. I do like using your "auto gain/exposure" when taking flats.

I'd agree the Player One SDK is the culprit. I always run all OSC cameras at the color balance mid-point. For ZWO it's 50-50 and for Player One it has been 0-0-0 and I did check and confirm this for the cut-off histogram session. So it still does not make sense to me.

I ran the Poseidon-C with a CB of 0-0-0 and took new flats and darks, yet the histogram was cut-off. This was all done on the night of the session with SC 4.1.14120. A MasterFlat txt file is attached.

If this was at home I'd not give it a second thought but at the dark site it pretty much kills the session. And when this kit was last run at home it worked fine with the same settings. Maybe the Player One 0-0-0 color balance is different between SDK's. Seems idiotic but what else could it be.

Mike

[admin]

Hi Mike,

to give a bit more detail, the original Player One colour balance controls were in the range -1200 to +1200 with zero being neutral (lets call this 'A'). Then there was an SDK update that changed them to be in the range zero to 100 with 50 being neutral (like ZWO, call this 'B'), then the next SDK update changed it back to the original -1200 to +1200 range ('C').

I tried to make SharpCap cope with this as best as possible, which meant that if you had a zero value saved white balance in 'A' then the SharpCap with option B would spot the zero and change it automatically to 50 to preserve the neutral balance. Then, when they changed it back I had to write more code that spots the neutral value of 50 from option B and changes it to zero for option C white balance. It was all very yucky and only worked nicely if you had things set to neutral from the beginning.

The history was :

SharpCap 4.1.13724 brought in the new SDK that introduced the type 'B' white balance. I didn't know about that at the time, so that version did not try to auto adjust the white balance values if they were loaded

4.1.13789 added the code to auto adjust the white balance values if they looked like they were old style neutral values and set them to 50 to match the new type B SDK

4.1.14089 brought in the new SDK that changed the white balance to the original way again, and also tries to fix saved white balance values of '50' by setting them to zero.

Sorry if this has caused you issues - to be honest, if I had known about the change in the SDK when it first happened, I would have been reluctant to update to it, but of course all of these SDK updates also add support for new models which other people are calling out for

cheers,

Robin

[MarMax]

Robin,

Thank you for the additional explanation. It seems best, regardless of the SDK, that I check the color balance every time I select a camera and make sure the white balance settings are neutral. I've hesitated to use camera profiles because of the changes with SDK's. And I don't think anything you did caused the cut-off histogram.

I'll need to up my game at troubleshooting the cut-off histogram. It seems to happen about every year or so at the dark site. From the discussion on CN it seems like upping the gain/exposure is the best approach and just because something works at home (B8) does not mean it will work at the dark site (B2). Is there any advantage (or disadvantage) of using higher gains at the dark site?

I understand that more offset may be needed at a dark site to prevent black clipping. I'm just not sure how to pick the correct offset when I'm setting up equipment at home (B8). Last time this happened with the 2600MC the offset needed to be 70. This time an offset of 60 worked with the 2600MC but an offset of 80 did not work with the Poseidon-C. Is there any way to estimate an offset increase from B8 to B2 for a given sensor?

Mike

[admin]

Hi Mike,

my usual recommendation for setting offset is to set up to capture dark frames at the longest exposure and the highest gain you are likely to use for deep sky. Adjust the offset to ensure that the histogram peak clear of the left hand side, with just a little space between the left hand vertical axis of the histogram and the start of the 'hill' for the dark peak. That's now the offset to use, and you can use it for shorter exposures and lower gains the ones that you set it up on. Probably longer exposures too, just not higher gains.

Keeping that setting should ensure that raw frames from the camera are not black clipped. Once the raw frames are avoiding black clipping then if you see it in dark subtracted frames you know that somewhere a setting has been changed between the darks and lights that is leading to over-subtraction.

cheers,

Robin