Flatframe Autoexposure fails

[MikeB838]

Hi Robin,

thanks for the new version (v4.1.13758.0)
To check the CRVAL <> epoch things I used the clear sky this night. I had some difficulties (loose cable, misbehaving laptop etc),
but when I was able to start my routine, flat frame autoexposure was not able to succeed (I had the same light source as usual (tablet with
a white page). I do not see the advances in the histogram and it failed with a message box 'Auto exposure failed'.
I continued without flat frame successfully.

At the end of the session I tried it again: without success. I attach my log. The last try has the correct light source (starting at line 2946).

Is this known? Do I have to change something?

Thanks and cheers,
Michael

[admin]

Hi Michael,

from the log it looks like the flat illumination was too dim to give a proper histogram within the constraints used by the autoexposure code.

The autoexposure limits the exposure length to a maximum of 1s (much longer and the autoexposure process itself would take a very long time), and it allows the camera gain to be used up to a maximum of 300x multiplier (if the camera goes that far). However, in this case even at the maximum gain/exposure allowed, the histogram peak only got to about 25% of the way across.

Was your flat frame illumination dimmer than usual for some reason? That would be my first guess if this usually works.

cheers,

Robin

[MikeB838]

Hi Robin,

thank you very much for the inspection of my log!

No that was the same light source as usually and very bright.

Last night I tried it again with thw same result, so I changed exposure time and gain manually, as I remember where the 4 curves in the histogram of RGB and I have to be. What I observe was: as I change eg. gain, I have no curves that move around in the histogram, but they are kind of pumping.
Sometimes all show as a small needle, then they show again as a normal gauss curve, but not all colors: one or more are only a needle and sometimes
there is nothing to see at all. I captured a flat, but that was a total mess (see: www.twus.de/flat.zip).

I have an PlayerOne Uranus-C Pro and have not done the firmware/FPGA update for HDR (I'm not sure that after the update I can measure brightness of objects correctly (linear vs. HDR)?). Can this be the problem: the new SDK needs the update in the camera???

Last night I also have problems with the planetary stacking. The picture of Saturn was always dim, no matter what I change. And in some shots
I have problems adjusting the colors. Might be all the same culprit?

If you need any more information, I will be pleased to send it!

Thanks and cheers,
Michael

[MikeB838]

Hi Robin,

I forgot: and I have problems controlling the cooler of the Uranus-C Pro. When I start it, it overshoots (target -10°C, goes to -18°C). After
switching cooler off and on (more than once), changing the speed of the fan, it reaches it's target and then it stays there the whole night.
I never experienced this with older SC versions. May be the firmware update is needed here too??

Cheers,
Michael

[admin]

Hi Michael,

I think you may be onto something there with the idea that the FPGA update might be necessary for the new SDK that has been included in SharpCap - if the histogram is not responding properly to your manual gain changes (and is not showing a normal gauss shape) then it sounds like the image coming through to SharpCap isn't correct.

If going back to 13685 cures the issue and then 13724 and 13758 are giving the problem then it is definitely pinned down to the SDK update.

cheers,

Robin

[MikeB838]

Hi Robin,

I will give it a try (with the old versions) - tomorrow, as I have to leave soon.

Do you have an Idea about the linearity in the new version, so I can still measure brightness values??

Cheers,
Michael

[MikeB838]

Hi Robin,

I connected the Uranus-C Pro to my desktop PC with the same SC-version. Getting flats worked as it should.

I compared the profiles and found that on my laptop the values for "White balance RGB" had been set by the last
software update to 1,1,1 (instead of 50,50,50). After correcting that getting the flats works as intended.
I never had changed that values before and missed their changes.
Astonishing that the update does not harm the desktop PC.

This night the cooler works as good as before. I think I will replace the PlayerOneCamera.dll with older ones from the SDK to see, if I can get rid of the
problem with the cooling if it come back.

Before updating the firmware and FPGA of the camera I want to hear from some experiences.

Thanks for your help and sorry for the noise!

cheers,
Michael

[admin]

Hi Michael,

I don't think the update will have changed the colour balance settings, rather I expect that it is related to the auto-restore of last used camera settings in SharpCap. Normally this is helpful, since it will put the exposure etc back to the last used ones, but if there was perhaps a glitch at some point the odd values of 1,1,1 could have been read back from the camera when SharpCap was saving the last used settings, then those get re-loaded every time after that. The trouble is, there is no real way to filter out this sort of issue without losing the general convenience of having the settings restored on re-open.

cheers,

Robin

[MikeB838]

Hi Robin,

that makes sense, but I never changed that values before (may be by chance). Or a incorrect shutdown changes that values and the wrong values
were loaded the next time I started SC. In that special cases one has to live with it.

In case something odd happens again, I should check better, but it was a little bit of hecticness (I thought the clouds were coming )

cheers,
Michael

[admin]

Hi Michael,

same thing happened to me the first time I used the new version with my PlayerOne Poseidon, so I did a bit more digging into why...

Turns out that older versions of the SDK had colour balance values that could range from 0 to 100. Oddly both 0 and 50 were neutral values, with 1 being 'lots less of that colour' and 100 being 'lots more'. In those old versions the default for the 3 values was zero - ie neutral.

The latest version of the SDK removes the odd 'zero is neutral as well as 50' - now the control ranges from 1 to 100 with 50 being neutral.

SharpCap doesn't understand this change, so when it tries to re-load your previous settings (or a profile with saved values of zero for the colour balance sliders), it tries to load zero, realizes that it is out of range, so loads the nearest available value that is in range - ie. one. So, the first time you use your camera with the new SDK and reload old settings or profiles, the colour balances all end up being set to one

I must admit that I didn't spot this, and looking back at the changelog of the SDK, it was mentioned What's more, it's the second time they have changed the meaning of these values recently...

I will try to add something for the next release to avoid the wrong value being set when reloading old settings - it will be interesting to see if I can work out a way to unpick this both for people who have used the most recent version that set everything to 1 and for those who haven't

cheers,

Robin