Possible corruption of camera control data: orientation, Bayer Pattern...

A place to report problems and bugs in SharpCap
Forum rules


If you have a problem or question, please check the FAQ to see if it already has an answer : https://www.sharpcap.co.uk/sharpcap-faqs

Please also read about Troubleshooting USB Issues before posting.

*** 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]
Post Reply
BobHehmann
Posts: 17
Joined: Thu Sep 16, 2021 11:17 pm
Location: Moorpark, California, USA

Possible corruption of camera control data: orientation, Bayer Pattern...

#1

Post by BobHehmann »

My setup is the most recent version of SC at the time (v8861 for this issue), latest patch of Win10 Pro, driving an ASIO071MC Pro camera, with a Pegasus hub sitting betwixt camera and laptop. This setup served flawlessly for more than 6 months, until this, a few days ago:

At session setup, when SC was first initializing its connection to the 071, the connection glitched - this was due to a loose USB cable, jostled during physical setup. The OS "dinged" for the detected then lost USB device. SC, of course, could not see the camera at this point. I found and re-seated the offending cable, restarted SC, and all seemed well. No problems with SC Polar Alignment, target plate-solving/synching, and SC focus assist. During imaging, the local SC image window presented subs normally.

However, upon opening the first sub in PixInsight (PI), the image orientation had been flipped in one (possibly both) axis from normal, and Red/Blue had been swapped. PI was set to auto-detect the Bayer pattern, but it did not appear to - forcing it to "BGGR" corrected the coloration. AutoStakkert had the same issue. The FITS header had the BAYERPAT and COLORTYP fields set to "BGGR" (they should have been "RGGB"), and the BAYOFFX, BAYOFFY, XBAYERPAT, and YBAYERPAT fields all "1" ("0" is correct.) All subs had this problem, and until fixed, was repeatable in testing.

NINA had no such camera management glitch (it oriented properly and set the FITS header data as expected), so it wasn't the camera driver per se. To no avail, I tried uninstalling and reinstalling SC; uninstalling and installing an older version of SC; uninstalling and reinstalling the camera driver; deleting all AppData (Roaming and Local) for SC between installation attempts. Ultimately, I think some camera-related data in the registry became corrupted, leading SC to believe the camera's operation was different than reality. As there were no associated system or hardware problems reported at that time in the Windows event logs, I'm assuming SC wrote some glitched control data back to the registry - but did not correct it upon subsequent runs.

To fix this, I ended up reverting the OS to a restore-point taken several days back - which lends credence to "bad registry values."

If this were to repeat, are there any recommended shortcuts e.g., specific registry values that can be manually reset, a way to totally "uninstall / reinstall" a camera, or a way to totally uninstall SC, leaving no residual context behind?
Cheers, Bob
User avatar
admin
Site Admin
Posts: 13173
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Possible corruption of camera control data: orientation, Bayer Pattern...

#2

Post by admin »

Hi Bob,

two things that I can think of for you to check...

1) What setting do you have for FITS header compatibility in the SharpCap 'Saving' settings? Unfortunately various processing applications disagree with each other on which way round the BAYERPAT fits headers should be, so SharpCap has to have an option to control this
Capture.PNG
Capture.PNG (40.79 KiB) Viewed 637 times
2) Are you using the 'Flip' option for your camera? In theory SharpCap should correct the FITS headers for any possible flip setting, but it makes things more complex, so worth turning off for further testing if you have it turned on.

cheers,

Robin
BobHehmann
Posts: 17
Joined: Thu Sep 16, 2021 11:17 pm
Location: Moorpark, California, USA

Re: Possible corruption of camera control data: orientation, Bayer Pattern...

#3

Post by BobHehmann »

Dr G: Apologies for not responding more quickly. As a beta-tester, I've been helping a mount vendor with testing their new mount-controller firmware release and ASCOM driver, and things got, uh, interesting - I lost track of everything else AP related.

I'm a PixInsight (PI) user, and I verified that the SC setting for interpreting the Bayer pattern is "Normal". I sometimes open FITS files in ASTAP, and pre PI, used DSS for stacking - all use this same setting, and I've never experienced this issue before (or since!)

I'm unaware of any "flip" setting for the ASI071, outside of the pulldown in the SC Camera Controls panel, "Flip - None". I didn't intentionally alter that setting, and unfortunately don't recall if it were accidentally changed at the time of the glitch.

I'll keep an eye to the flip setting if I ever encounter this again. If that's all it is, no problems. If not (fails, but Flip is still correct i.e., "None"), I'll contact you again on the forum.

Cheers, and best wishes, Bob
Cheers, Bob
User avatar
admin
Site Admin
Posts: 13173
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Possible corruption of camera control data: orientation, Bayer Pattern...

#4

Post by admin »

Hi Bob,

sounds a good plan

cheers,

Robin
Post Reply