Weird behavior SC 4.1.11824

[Anthony Quintile]

I upgraded to 4.1 and, aside from needing to get generally reoriented on some new functionality, (plate solve was way too fast ;-P), I observed some odd things:

-When multi-star auto-focusing, during the first step, first frame, image preview frame has large text saying something about capture, like scroll over help instructions maybe (?).

-After auto-focusing, and I think when switching from Live View to another screen, all controls and tool bars momentarily disappear. This does not seem to cause any issues, but it is unnerving.

-The amount of time it takes to add a sub to the live view stack seems to be very long. It's 20-30 seconds whereas it used to take around 10 seconds.

Info is pasted below, (log file size too big to attach file according to forum restrictions, let me know if you want me to Dropbox it to you.)

-Anthony Quintile

ASI2600MC Pro, ZWO 12v EAF, ASI120MM Mini guide cam, (All USB), Losmandy G11G2 v6 using crossover network cable

Device name LAPTOP-DVIMBO8J
Processor AMD A8-7410 APU with AMD Radeon R5 Graphics 2.20 GHz
Installed RAM 8.00 GB (6.91 GB usable)
Device ID D2A07032-589B-4838-9846-1B7CB8B2DBD8
Product ID 00325-80599-89336-AAOEM
System type 64-bit operating system, x64-based processor
Pen and touch Touch support with 10 touch points

Edition Windows 10 Home
Version 22H2
Installed on ‎9/‎25/‎2020
OS build 19045.4291
Serial number PF0MK7PE
Experience Windows Feature Experience Pack 1000.19056.1000.0

[Jean-Francois]

Hello,

I can confirm one thing with the version 4.1.12100 and the long time after the capture of one image.

It was yesterday evening not possible to use the Live Stack.

I wanted to image with 20 s per exposure. But, SharpCap was adding another 20 to 25 seconds after the 20 s exposure.
I tested with the Live mode and the Still mode. I stopped and restart SharpCap ... it was all the time at least the same time after a capture.
And not only on the first image after a setting modification. It was for each capture the case.
I used yesterday only my QHY174GPS camera. I can do some additional test with different camera.

Regards,
Jean-Francois

[Anthony Quintile]

After another night of use I wanted to add an additional observation...

The new focus routine seems to be more complicated and unnecessarily so. I can see how it is trying to improve the focus result, however I was not having any issues with the previous routine's accuracy/precision.

At one point last night it was not giving me a curve with a best-focus-result, nor was it adding steps to improve accuracy as it now seems to typically want to do. The apparent curve that I could visually glean from the results of the steps on the graph was enough for me to guess the focus point precisely, but for whatever reason the program could not do the math. After a few more attempts, it "fixed itself", which was weird.

[admin]

Hi,

OK, I can shed some light on some of the issues...

1) Controls vanishing briefly after focus scans - SharpCap 4.1 puts the camera into still mode for focus scans if the exposure is above about 2s - this helps avoid frames being captured during focuser moves and speeds up the scan, but can mean a re-initialization of the camera when switching live=> still or still=> live on some brands of camera

2) Focus scan result not giving a curve - SharpCap has some fairly stringent checks for the curve to make sure that the curve is significant and not just a random variation in focus data. It's probably stricter than you would be to avoid confidently picking a best focus point that is completely wrong. If you have a session where you are convinced that the curve looks good but SharpCap will not pick it up, please post the log showing the session so I can investigate.


I'm not aware of anything specific that would slow down live stacking, but will investigate. It would be helpful if you could check if the problem happens when using previously saved images via the 'Folder monitor' camera - that would elimanate the camera itself being a cause of the problem. Also, look in the 'Status' tab of live stacking, where there are some timings displayed that would help narrow down the area where the problem might be.

cheers,

Robin

[Anthony Quintile]

Robin-

Here is an image of the odd text while the first image for focus is being captured.

https://drive.google.com/file/d/1wXr0lA ... sp=sharing

Also, in case it is helpful, I was looking at the Log tab in Live Stack, (I think I have been calling this "Live View" incorrectly above...), while an image was saving and stacking, and I noticed that the Log was populated with FWHM and other info much more quickly than the image was stacked and graphically processed, (FWHM on "FWHM Filter" tab takes a long as the image to be graphically stacked, ~30 seconds.) I had meant to check if the FITS file populated my save folder as quickly as the Log updated, but forgot. Hopefully that makes sense and is helpful.

-Anthony

[Anthony Quintile]

Re:

"2) Focus scan result not giving a curve - SharpCap has some fairly stringent checks for the curve to make sure that the curve is significant and not just a random variation in focus data. It's probably stricter than you would be to avoid confidently picking a best focus point that is completely wrong. If you have a session where you are convinced that the curve looks good but SharpCap will not pick it up, please post the log showing the session so I can investigate."

Here is the log where I was not getting a curve at first, was fine for the rest of the night, and previous and following nights:


https://drive.google.com/file/d/1P2ye4f ... sp=sharing

Although this occurrence may have been a glitch of some sort, I generally find that the newer focus routine is slower and no more accurate, essentially extra steps for nothing. I can confirm that the previous routine was fine for me because my images are not out of focus, and, (objectively), I could repeat the focus routine several times and get the same result (maybe, occasionally, +/- 1 step). I have done this on numerous occasions to confirm focus. I think I understand how the new routine is checking itself, but I don't know if it's functionally helpful.

[admin]

Hi,

thanks for the data - I can see the plots for the cases which failed and they look like the should work, although they are very much 'V' shaped curves rather than 'U' shaped, which might be part of the issue (you tend to get U shapes if you do a narrower scan close to best focus position, V shaped with a wider scan that goes a long way from best focus).

I will check through the code and see if I can spot exactly why it is rejecting these and what could be done to improve it

thanks,

Robin

[admin]

Hi,

I had a look at the focus graphs recorded in your log. In most cases the problem seemed to be that the scan was starting too close to the point of best focus, so that there were only a small number (2 or 3) points being measured before best focus is reached. SharpCap is looking for (ideally) three points each side of best focus that have focus scores significantly worse than the best focus score. Two points will do if those points are *strongly* significantly worse than the best focus score. In a couple of cases, the 3rd point was pretty much at best focus, so that one couldn't count.

I have tweaked the code a little in the latest update to allow 2 points each side if one is significant and the other is very strongly significantly worse than best forcus, which will pass a number of your scans, but perhaps not all. In terms of configuration, it would be best to either reduce the number of movement steps between measurements for the focus scan or start a bit further from best focus - both would help make the scan more robust.

Additionally, since you are measuring over quite a wide range each side of best focus, you get a 'V' shaped graph - SharpCap has an experimental option to allow a V shaped graph fit, which may do better because it fits the data better than the default U shaped curve. When this is enabled in the latest version, it will automatically use either V or U depending on which provides the better fit to the data. If you measure over a smaller movement range each side of best focus, you tend to get a U shaped graph - another option to try, but would require smaller step size.

cheers,

Robin

[Anthony Quintile]

Robin-

Another thing that I verified last night...

After a focus run, I used to be able to start capture of a frame by setting exposure time (240 seconds in this case), clicking off that box, (onto Gain box for example), and then opening Live Stack and un-Pausing. The first frame would save to folder and stack.

Since 4.1x, the first 240 second exposure is lost. It doesn't show as dropped or anything, it just doesn't stack or save to the folder, (pretty sure on the not saving to folder, but I haven't confirmed).

Here is last night's logs where I am positive that this happened on at least two separate occasions after focusing.

https://drive.google.com/file/d/10hLOXk ... sp=sharing

I shot Flats and Flat Darks last night as well using the Capture function (as opposed to the Live Stack as described above) and the first frames captured for both of those runs. Incidentally, the calibration frames captured in the Capture function register as captured immediately (I understand that there is no stacking calculation involved) whereas the stacking and saving of frames in Live Stack continues to take ~25 seconds, which is much longer than before 4.1x.

-Anthony

[admin]

Hi Anthony,

do you have the option in live stacking to 'Only stack while guiding is active' switched on the the live stack guiding tab? I think that might be the cause of the first frame being dropped...

In your log, I can see that the first 240s frame after focusing starts at 23:00:12. You start live stacking a couple of seconds later and by 23:00:16 live stacking is fully running and has detected that PHD2 is guiding. Now, the code that checks to see whether guiding is lost may be spotting that guiding wasn't active during that first few seconds and dumping the frame because of it. If that's happening, it would be recorded in more detail in the small log on the right of the live stacking area (it doesn't make its way to the main log). If that looks like it might be the case then it may be easiest to just turn off the 'only stack while guiding is active' option - I do have a plan to improve that option to reduce exposures while guiding is failed, but haven't had a chance to do it yet.

For the slowness is updating, the key information is from the 'Status' live stack panel, which shows various timings of how long it took to process the frame. Knowing which of those is very high would help me understand which part of the code is slow.

cheers,

Robin