*** Please do not post license keys - please report any problems with licensing to 'admin' by private message ***
Please include the following details in any bug report:
* Version of SharpCap
* Camera and other hardware being user
* Operating system version
* Contents of the SharpCap log after the problem has occurred.
[If SharpCap crashes, please send the bug report when prompted instead of including the log]
Hi,
I notice that the SUBEXP header fits gives me wrong values.
For exemple SUBEXP = 0.7192195 when real Exposure=15,000s.
On the other hand EXPTIME is right.
I use last sharpcap version.
Best regards,
2023-02-20_09h51_08.png (22.35 KiB) Viewed 369 times
looking at the code, the value of the 'SUBEXP' header comes from the last frame that is sent to live stacking before the save (regardless of whether it is added to the stack or not, which is probably not correct behaviour).That leaves me wondering why could the last frame have had an odd exposure time marked against it?
The most likely reason would seem to be that either the exposure was changed just before the stack was saved (when the exposure is changed with a long exposure in progress, the in progress exposure gets stopped early, which could give the 0.719...s value). Alternatively if the stack got saved as a result of closing the camera or changing some camera setting like resoution or bit depth, you would similarly get a short frame created, which might arrive fast enough to affect the data used when saving.
I will make some changes to the code to see if I can minimize the chances of this effect happening.
possibly the dithering - the switch from longer to shorter exposures could lead to a frame with an odd length as the long exposure would start and then get cancelled. Either that or the closedown could have been the cause.
Either way, I've tweaked the code so that only frames that make it into the stack will affect the recorded sub-exposure header, so it should be OK in future.
