4.1.10987.0 and QHY183C

[MarMax]

I had an interesting thing happen last night with the Windows 10 Mini-PC running 64-bit V4.1.10987.0 On the third object, SC just stopped stacking frames. Everything else seemed to be running fine except no frames were stacked. I tried shutting down SC and the camera and restarting but it continued.

The log of the session where this started at the end is attached.

[admin]

Hi,

thanks for posting the log. I think it's possible that in one case when you reset the stack, it had just finished dithering but not resumed stacking, and that might have left things in an odd state which then meant that the code *thought* it was waiting for the short frames while dithering to finish, but wasn't. I will try to reproduce a similar case myself and see if I see problems.

cheers,

Robin

[admin]

Ok, I was close, but not quite right...

As far as I can work out, the problem was caused by a manual exposure change just after the program automatically set the exposure back after short exposures during dithering. Unfortunately the code wasn't set up to cope with this, so it was happily waiting for what it was expecting to be the 'proper' exposure length, and always getting frames that were shorter than expected, so going round and trying again.

I've tweaked the code in this weeks update so that if you manually change the exposure during or just after dithering then it won't change the exposure back to the original value and won't wait for ever hoping for an exposure of the original length either.

cheers,

Roibn

[MarMax]

Thank you Robin. This may also have something to do with my trackball mouse and operating over in the right panel. I'm the guy that's always moving around in that panel and crossing over areas susceptible to scroll wheel changes. It's likely that's what I did that changed the exposure.

On the topic of some strange camera behavior, something happened with the Offset between the second target and the last one. I've been running an Offset of 10 with a Gain of 11 most of the time using the 183C. For some reason, my histogram, instead of being offset on the left, was cut off on the left. I even bumped the Offset up to 80 and was barely able to get the full histogram.

I've pretty much given up on the 183C at this point. It's been too aggravating to work with. And continuing with this same issue, last night with the ASI533MC-Pro, everything was fine initially and then at some point the same Brightness (Offset) problem appeared. I run the 533 at a Gain of 200 and Offset of 10 an this keeps the histogram from cutting off the black point. But about the third target into the session the histogram was cut off on the left. Here is a screen shot.

SC_HistoCutoff_08272023s.jpg (358.05 KiB) Viewed 6634 times

The log file is attached. And EDITED to say I should have posted this in a different place since it's no longer a Beta version.

[admin]

Hi,

I'm not sure about the cause of the offset shift for the QHY camerea, but having a look through the log you included for the ZWO run, I can see that you are using both dark subtraction and background removal, both of which could (in theory) lead to over dark images.

For dark frames it's fairly simple - if you keep a dark frame for say 30s loaded and change the exposure to 5s then it might over-subtract. Even more likely if the offset is different between the dark and light frames.

For dark subtraction, the code is supposed to avoid over-subtraction and it should leave a reasonable but constant background level behind to avoid this, but I suppose it might encounter patterns of brightness that cause that not to work properly - it would be worth saving some raw frames at some point and then if it happens we could experiment in the folder monitor camera.

Of course, the other potential way it could happen is that the offset value somehow changes behind SharpCap's back as it were - the value on the camera changes but SharpCap isn't expecting that to happen, so it won't be checking for it. If you suspect that, try changing the camera ROI to a different size or change between 8 and 16 bit mode. That should trigger a re-read of all the control values which would suddenly show a different offset value if it had changed unexpectedly.

cheers,

Robin

[MarMax]

Very interesting regarding dark subtraction and background removal. I've always used a dark, a flat and some form of background subtraction, typically linear gradient removal. I just assumed the linear gradient removal was a process to minimize image gradients and did not realize it was a form of dark subtraction. My workflow for calibration frames is fairly simple and I always match darks / flats / lights (gain, bin, brightness/offset, white balance, temp) and always match exposure for darks and lights.

The issue with brightness/offset and cutting off the histogram is still a mystery to me since I've been using different versions of SharpCap 4.0 and 4.1 for a couple of years now and this has not happened before. The only time I experience a histogram brightness/offset shift is at a dark site (as compared to home). At a dark site I usually need to double the brightness/offset value I use at home. I'm only using two gain levels with the cameras. For the 183C I use 11/18 and for the 533/2600 I use 200/350.

For reference, here is a typical (normal) screen grab using the 533MC-Pro with the same gain/brightness (200/10) as in Post #4.

SC_HistoNormal_Sm.jpg (143.22 KiB) Viewed 6566 times