Weird sensor analysis results with Touptek ATR585M

[nurbson]

Hey folks,

I just received my 585M from Touptek and did some sensor analysis for HCG and HDR mode. My camera has the latest firmware, 4.50, and sharpcap is v4.1.13319.0.
here are the results with the sharpcap drivers:
Normal mode

NormalMode.jpg (117.85 KiB) Viewed 3041 times

HDR mode

HDR.jpg (87.81 KiB) Viewed 3041 times

and also the results with the ascom drivers
HCG mode

HCG_ascom.jpg (99.3 KiB) Viewed 3041 times

HDR mode

HDR_ascom.jpg (104.73 KiB) Viewed 3041 times

What I don't understand is the high readout noise, compared to my other 585 camera and also to the charts from touptek themself. And also both drivers differ in the results.
Besides, what doesn't seem to work currently is setting SharpCap.SelectedCamera.SetGainsOfInterestForSensorAnalysis([100,150,200,250])

[admin]

Hi,

interesting results - the underlying problem is that the bit depth of the sensor is being incorrectly measured as 14 (should be 12) and sometimes 16 (although maybe that is an HDR effect). The 14 bit rather than 12 bit value will make all the e/ADU values 4 times smaller and I think that will then feed through into the read noise values too.

The incorrect bit depth measurement is often caused by some sort of processing of the image going on between it coming off the camera and getting to the sensor analysis - for instance on a colour camera with white balance controls, the white balance adjust might be multiplying all pixel values by 1.23456 in the green channel, and that would stop the sensor analysis code from being able to spot that the 12 bit sensor was creating 12 bit values (ie only multiples of 16 when scaled to 16 bit data).

The problem is, I can't see quite how that would happen for the mono ToupTek camera - you are in MONO16 mode, so the 'gamma' and 'contrast' controls have no effect. SharpCap processing shouldn't matter either, although it would be best to ensure that everything in the 'Preprocessing' section in SharpCap is turned off anyway, just in case.

I happen to have a similar ToupTek 585M here (ATR585M, but a specialized version of it). That seems to produce normal results as shown below for 'Normal' mode.

Screenshot 2025-05-16 162301.png (137.67 KiB) Viewed 3038 times

Because my camera is an unusual variant of the ATR585M, it has a different firmware derivative to you - it's not really possible to compare firmware versions because of that.

The other thing that might be affecting you here (contributing towards the high read noise, but not the incorrect bit depth) would be if you have a light leak - light getting to the sensor even when you are doing the dark measurements for read noise. If the histogram peak moves right significantly with increased exposures when the sensor is covered then that would point at a light leak.

I'm not going to try to get into the results of the ASCOM driver as that introduces more unknowns to the situation. I will however try to post a followup showing the sensor data I get in HDR.

One more suggestion would be to open the camera in SharpCap with <CTRL> pressed - that stops SharpCap from restoring any previously saved camera settings, which just might clear some setting that could be causing the wrong results.

cheers,

Robin

[admin]

HDR Analysis

Screenshot 2025-05-16 165116.png (147.09 KiB) Viewed 3037 times

Actually, yours is not so different except that you have slightly higher read noise for high gains and very high read noise at gain 100 (and a bit at 177)

cheers,

Robin

[nurbson]

Thank you for the quick reply!
I will try two things tonight, since the measurement initially posted were done during daytime: rerun a sensor analysis with ascom drivers in HCG mode in darkness. I prefere this over the SharpCap drivers because I'd rather set the readout mode to HCG in the driver directly. SharpCap does an automatic switch at "Normal Mode" at some gain (around 1300 if I remember correctly).
Second, I "reset" the camera data with crtl and check if the sensor depth is recognized correctly. btw: is SharpCap truely measuring the pixel depth or does the driver report it?

EDIT:
I just read the explaination about LCG/HCG switch in normal mode. Makes sense, but for a sensor analysis I'd like to measure gains at a certain mode and setting a specific gain range with SharpCap.SelectedCamera.SetGainsOfInterestForSensorAnalysis([100,150,200,250]) doesn't seem to work with the 585M.

[admin]

Hi,

in answer to the question about measuring the bit depth - SharpCap does attempt to calculate that measurement itself, and it should work fine providing that the data SharpCap gets in the image is the raw data from the sensor scaled up by the appropriate bit depth conversion factor (ie x16 for a 12 bit sensor being scaled up to 16 bits; x4 for a 14 bit sensor being scaled up to 16 bits).

SharpCap looks at the image data and tries to spot if all values are a multiple of 16 (=> 12 bit sensor), all values are a multiple of 4 but not necessarily 8 or 16 (=> 14 bit sensor), etc. The problem is that if something like the camera SDK is adjusting the values before they get to SharpCap, that can give the wrong result. While it's possible to ask the camera SDK for the bit depth on some brands, it's more useful to try to measure it - I've found SDK issues with support for certain models purely due to the fact that the bit depth measurement came out wrongly.

cheers,

Robin

[nurbson]

Thank for clearification.

I did some further testing and things get more confusing.
First, measuring in darkness did not change anything, same with crtl+click when opening the camera. So I switched to my mele quieter PC on the telescope and reran the measurements with the exact same SharpCap version and it's driver.
et voila:

NormalMode_SharpCapDriver.jpg (99.71 KiB) Viewed 2999 times

HDR result didn't change since they were fine in the first place.
So I reinstalled SharpCap on my laptop, where I ran the initial measurements but I still get the wrong 14bit pixel depth and odd results. I'm kind of lost tbh.

[nurbson]

I'm thinking about the "normal Mode" switching from LCG to HCG at a gain of 1365. How do I calculate the gain value for NINA where I can select LCG and HCG? Does 1365 represent a gain of 100?

[admin]

Hi,

on the difference between the laptop and the other PC, I am wondering if somehow SharpCap is picking up the wrong version of ToupCam.dll on the laptop (perhaps an older version from another application), leading to issues.

Currently SharpCap is installing Toupcam.dll version 57.27993.20250313 . If you run SharpCap and open your camera, you can then grab the content of the SharpCap log and paste it into Windows notepad (or some other text editor). Then search for 'using SDK version', and you should see a long line of text containing

Code: Select all

using SDK version 57.27993.20250313 

If the version number isn't the one shown above then SharpCap is picking up an incorrect version of toupcam.dll somehow. I would be tempted to search the disk for other versions of toupcam.dll, particularly checking to see if any copies are in folders in the path or in C:\windows or c:\windows\system32.

The switchover at gain 1365 works like this...

SharpCap gain 100 to 1364 - camera in LCG mode, camera gain 100 to 1364

SharpCap gain 1365 and above - camera in HCG mode, camera gain 150 and upwards (divide SharpCap gain by 9.1 to get the camera gain).

Like some other sensors, there seems to be a 'keep out zone' in HCG mode where low gains below 150 are best avoided. I haven't seen the sensor documentation for this model, but there is a similar thing on the IMX294/492 where raw camera gains of under 200 (2.0x) should not be used in HCG mode.

cheers,

Robin

[nurbson]

Thanks for the insights.
Both SDKs are identical

N100 PC

Code: Select all

#1 	Opening SharpCap.Cameras.ToupTek.sdk.SDKWrapper`1[SharpCap.Cameras.ToupTek.sdk.Toupcam] 
Camera ATR585M (#\\?\usb#vid_0547&pid_157c#5&c99ffec&0&14) : FLAG_CMOS, FLAG_ROI_HARDWARE, 
FLAG_MONO, FLAG_USB30, FLAG_TEC, FLAG_GETTEMPERATURE, FLAG_RAW16, FLAG_FAN, 
FLAG_TEC_ONOFF, FLAG_TRIGGER_SOFTWARE, FLAG_TRIGGER_SINGLE, FLAG_BLACKLEVEL, FLAG_BUFFER, 
FLAG_DDR, FLAG_CG, FLAG_RAW8, FLAG_CGHDR, FLAG_HEAT, FLAG_EVENT_HARDWARE 
using SDK version 57.27993.20250313	
in new SharpCap.Cameras.ToupTek.ToupTekCameraProxy(DeviceTagData dtd, IImageDisplay previewTargetWindow)

Laptop

Code: Select all

#1 	Opening SharpCap.Cameras.ToupTek.sdk.SDKWrapper`1[SharpCap.Cameras.ToupTek.sdk.Toupcam]
Camera ATR585M (#\\?\usb#vid_0547&pid_157c#7&24b62d9f&0&2) : FLAG_CMOS, FLAG_ROI_HARDWARE,
 FLAG_MONO, FLAG_USB30, FLAG_TEC, FLAG_GETTEMPERATURE, FLAG_RAW16, FLAG_FAN, 
 FLAG_TEC_ONOFF, FLAG_TRIGGER_SOFTWARE, FLAG_TRIGGER_SINGLE, FLAG_BLACKLEVEL, FLAG_BUFFER, 
 FLAG_DDR, FLAG_CG, FLAG_RAW8, FLAG_CGHDR, FLAG_HEAT, FLAG_EVENT_HARDWARE
 using SDK version 57.27993.20250313	
 in new SharpCap.Cameras.ToupTek.ToupTekCameraProxy(DeviceTagData dtd, IImageDisplay previewTargetWindow)

Besides, the SharpCap.SelectedCamera.SetGainsOfInterestForSensorAnalysis([100,150,200,250]) snippet is actually working just fine. It just ADDS the given measure points instead of replacing the defaults. To speed up measurements, is it possible to tell SharpCap to only measure certain gains?

[admin]

Hi,

there is only the option to add more gains to be measured (SharpCap will choose an evenly spread selection of ~10 gains for the basic measurement and also add gain points each side of any LCG/HCG changeover it knows about). You can't specify the exact set of gains you want, sorry.

Another idea on the weird behaviour on one computer...

Check the driver being used on each computer for the camera. Modern ToupTek cameras on Win10/11 do not need a ToupTek specific driver - they can run with a built in Microsoft driver called 'winusb.sys'. Maybe one PC has ended up using the winusb driver and the other is using the toupcam.sys driver. If there is a difference, you should be able to switch drivers in device manager to see if that helps on the PC with the weird behaviour. I tend to use winusb.sys now as the toupcam.sys is incompatible with some Win11 security features.

cheers,

Robin