some strange behaviours...

[GoFraRo]

Robin,

last night, I did an update from 4.1.10745.0 (64bit) to 4.1.1ß790.0 (64bit) to run some tests.

While using the stretch function in Histogram (right hand window), the programm stalled.
I was in a remote session (Windows remote desktop, both with the latest Win10 64bit). I had to quit the session and when I returned, SC was closed. I could reproduce it several times.

I decided then to switch back to 4.1.10745.0. Here, I experienced a couple of things:

- setting white balance to auto in the right hand histogram window (I had an ASI120MC-s connected), lead to a "wild" auto adjust, only to stop by setting it to manual. For normal capture, I let it on camera default, but I used the Guide-Cam for PA while it was still somewhat bright in the sky and had to lower the blue channel. I tried to set to auto afterwards but ran into the same issue.

- using my main cam (Player One Neptune-C), I tried to use the Brain feature of the Histogram function, but set the appropriate values for Exp/Gain/Offset etc. manually, switched to Livestack and let it run. After a while of running it unattented, I figured out, that the Exp and Gain settings were far away from what I've entered previously.

And another remark. When using the Goto by coordinates feature, an additional manual PlateSolve is needed in order to have the annotations in the proper place. The image is centered but the text and circles are not aligned, depending on the amount of previous recentering.

Hopefully, tonight will be cloud free and I can perform some other tests.

Regards
Gottfried

[admin]

Hi,

any chance you can find and send me the logs from the runs that stalled and then closed? I have seen an issue where the screen update slows over remote desktop if you stretch a nearly black image - that's because (I think) the image goes from being easily compressed by remote desktop (almost pure black) to being hard to compress (very noisy due to the strecth), which leads to a display update slowdown. Perhaps you were seeing an extreme version of this. The logs may help show what happened or at least give me some ideas on what setup to use to repro the issue...

The auto white balance is handled by the camera SDK for the ZWO camera (actually for all cameras that have an auto option in the right panel). That rather means that I cannot claim credit when it works properly, but on the flip side there's not really anything I can do about it when it misbehaves... SharpCap merely passes on the mesage to the SDK to turn the mode on or off...

The only thing that should change gain/expo during live stacking is dithering or recenter operations. Even so, those should only change exposure. The log here might reveal something (or might not - by default control changes are not logged, but maybe something unexpected will show up in the log at the right point in time).

On the final point, what are your plate solving action settings? Sync and recenter target? Offset GOTO? Each has a different mechanism that *should* mean that the annotation co-ordinates are correct after the operation, but maybe one of them is incorrect.

cheers,

Robin

[GoFraRo]

Robin, thanks for your attention.

I can't remember where to find the log files. (...user/apps/...or so ?), but going to look for it.

I know from my excursion in Allsky that the ASI120MC-s sometimes can do weird things, especially in rapidly changing conditions.

Regarding the last point, the sequence works fine, smoothly and I had only one unsuccessful Platesolve, when I underestimated the height of my neighbours house.
However. After all the steps, and when the object is nicely centered, when you now click the Deep-Sky-Annotation button, the annotation is placed on the coordinates before the re-centering step. And depending on the accuracy of the mount, this could be more or less off center.
In order to align the annotation with the actual position of the object, the annotation needs to be corrected or, as currently as workaround, a simple Platesolve is necessary to move only the annotation.

Screenshot 2023-06-18 181133.jpg (97.14 KiB) Viewed 435 times

Thanks again for your attention and your work.

Regards
Gottfried

[admin]

Hi Gottfried,

I will have to test the annotation issue myself the next time we have some clear sky - it's not the sort of thing that I can easily test out using simulated hardware or drivers. With a bit of luck that will be this evening, and then if I see it in action and have the log, I should be able to work out what is going on.

cheers,

Robin

[admin]

Hi,

I think I found the cause of this one... When the movement during the solve+sync stage contains a significant shift in declination (and you are away from the celestial equator), the code wasn't properly accounting for the shift in declination and the effect that has on the scaling of the RA co-ordinate (RA circles shrink towards the celestial pole).

I have a fix and it reduces the effect by at least a factor of 10 - getting rid of the last residual offset would require considerably more sperical co-ordinate geometry than is justified!

cheers,

Robin

[GoFraRo]

Thx, good to hear about a solution.