Sensor Analysis

Somewhere to ask questions about the best way to use 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
rockenrock
Posts: 68
Joined: Tue May 03, 2022 12:53 am

Re: Sensor Analysis

#11

Post by rockenrock »

Hi Robin,
After working with QHY they (and I) think the camera defective. I will return it to them soon. Thank you very much for helping to find the root cause, and thus the defective camera. I am wondering how long it has had this problem.

Now I am looking to perhaps a new camera...

I would like your thought/opinion/advice about using a true 16 bit (vs 168c 14 bit) CMOS camera for light polluted (Bortle 8) skies. Maybe it does not matter so much since my exposures will be quite short, and chances of saturation are less, than with my old 300s or 600s images.

Is the Hi gain & Low gain of these 16 bit CMOS cameras (such as QHY 268C and ZSO ASI2600c) beneficial for light polluted skies? Maybe they are only better for dark sites.

Best regards,
Roger
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sensor Analysis

#12

Post by admin »

Hi Roger,

I think the biggest reason for choosing the newer range of cameras (IMX533, IMX571, etc) is that they have far fewer issues with camera generated glow ('amp glow') than the previous generation like the IMX294 or IMX183. This makes dark frames less critical (some people are starting to do away with them, just subtracting a constant bias).

I'm less convinced by the jump from 14 to 16 bit ADC - after all, if you look at the sensor characteristics of the IMX571 (16 bit sensor), you see that at minimum gain the read noise is about 3.5 electrons or about 4.5ADU (16 bit ADU). Compare that with the 533 (14 bit) which has a read noise of about 3.8 electrons at minimum gain or about 1.25 ADU (14 bit ADU). Now, you get 4 16-bit ADU to each 14-bit 1, but we can see that all those extra brightness levels that you can read out on the 571 are basically just measuring the noise to higher precision - you are unlikely to see much in the way of practical image quality improvements.

The other good thing about these new cameras is the very low read noise once you switch into HCG mode. This is more important however for those with darker skies, since the high light pollution levels of your bortle 8 skies will keep the required exposure lengths down even with the higher read noise in LCG mode. On the other hand, if you intend to use one of the newer dual/tri/quad band light pollution filters with your camera, the HCG mode will come into its own.

Overall... buy a camera with one of the newer model sensors, just for slightly different reasons :)

cheers,

Robin
rockenrock
Posts: 68
Joined: Tue May 03, 2022 12:53 am

Re: Sensor Analysis

#13

Post by rockenrock »

admin wrote: Sat Jul 23, 2022 3:01 pm Hi,

SharpCap's target brightness for each stage is typically 65% of histogram (+/- 7.5%, so the range is 57.5 to 72.5%). If it can get the brightness into that range then it takes the measurement and moves on. If it fails too many times to get into that range then it gives up - that's what you are seeing.

Looking through the final steps in the log, I can see that Sharpcap is getting measurements of about 57% for exposures of 364,390, 406,412ms and of about 76% for 429,431,435,451ms - that's not how exposure is supposed to work, but it's not clear if it is truly related to the exposure being set wrongly by the camera or is something to do with the high gain value.

I can see from the log that you are running the camera in RAW8 mode for the analysis - that might be part of it as it will have an effect on the way the camera works. Try RAW16 mode, since that is the one you really want anyway for deep sky work. It also may be worth trying 'force still mode = on' in the controls as you could be suffering from an issue where the changes in brightness due to control changes do not appear for a number of frames after the adjustment is made.

It would also be worth trying manually adjusting the exposure in the range noted about with the high gain values set to see if you also see a jump in the histogram rather than a smoth change as the exposure is adjusted.

cheers,

Robin
Robin,
I have tested a loaner 168c (and my own) manually at those exposure levels you spotted in my sensor analysis failure log. I tested with natural light. So it more seems the camera (sensor?) capability.
So my questions are...
--- Does this type problem show up very often?
--- Is one sensor (model number) causing more problems for sensor analysis (and brain) more often than others?
--- Do you think the new sensors, such as IMX533, IMX571 are performing better for SharpCap and your sensor analysis?
You also mentioned after I manually checked those problematic exposure/adu's:

"OK, that's good info as it confirms the issue as being in the QHY SDK (or camera firmware) as far as I can see. I had a similar discussion with a different camera manufacturer recently - they had run into the same issue in testing of a prototype camera and were very pleased that the analysis had found a bug in their camera that they might never have spotted otherwise!"

Roger comment: I think it difficult for me to convince the manufacturer anything is wrong, but I have a smart & experienced guy here in HK working on it. Perhaps my best solution is to move on.

Thanks,
Roger
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sensor Analysis

#14

Post by admin »

Hi Roger,

my honest opinion is that issues like these where there is a step change in actual exposure at a point where there shouldn't be are usually caused by bugs in camera SDK or firmware. From my point of view, I get to see lots of different models using the same sensor either personally or in use by SharpCap users, and I have never found a case where the same glitch is apparent accross all brands for a particular sensor (which is what would happen if it was a limitation of the sensor itself).

Unfortunately, the way that exposure is programmed on modern sensors is not simple, so a simple programming or mathematical error by the camera developers can lead to this sort of problem.

I have just looked back at the analytics reports I get of sensor analysis completion, and I can see that the last successful sensor analysis runs that were performed on the 168C were back in May using SharpCap 4.0.8973 - now that may or may not be significant... It could be that the issue you are seeing was introduced in a QHY SDK update after 4.0.8973, or it could be that not many people have even tried since then. It may be worth going back to that version of SharpCap to see if it helps.

cheers,

Robin
rockenrock
Posts: 68
Joined: Tue May 03, 2022 12:53 am

Re: Sensor Analysis

#15

Post by rockenrock »

Hi Robin,
Thank you for your in depth reply.
I uninstalled the current Sharpcap version and installed
SharpCap 4.0.8973. Then using Sharpvcap I ran through the same exposures. The same result of changing exposure time, and no ADU change., then at next higher exposure it jumps up. This, and below, is both using a tracing panel light source and natural light. No difference except natural light drifts as expected.

When I install that older Sharpcap, does Sharpcap use the older SDK that comes with it? I think so, but I am scratching my head.

I have tested both my camera and the very generously dealer loaned 168c. Same results on each. I am now pondering if something else on my computer can affect this. But I did use my old laptop with a 2019 version of EzCap and SDK. Same res Now back to my 2019 XPS15...
FYI I also ran those 8 exposure levels at both 100ms less time, and 200ms less time. Same stepping result, just lower ADU.
In the Sharpcap display histogram I can see 3 peaks for my color camera partially separated, none saturated. I have debayer off for all tests. Main histogram is reset.
Do you suggest I remove all QHY camera drivers/dll and reinstall both Sharpcap and QHY "All in One" install package. As you can tell, I am near the end of technical ideas, and looking at commercial solutions.
Any comments appreciated. I would love to find something wrong that I did, and get on with it!
Thank you.
Roger
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sensor Analysis

#16

Post by admin »

Hi Roger,

so, an older version of SharpCap should install the older SDK, and in general that would be guaranteed, but it all becomes a bit muddled if you installed the QHY all-in-one and chose any of the SharpCap options inside that. If you have done that then two different programs may have claimed to install the QHY SDK in the SharpCap folder, and it all becomes messy about what happens if you uninstall one and reinstall.

So... it is probably a good idea to uninstall SharpCap, and the all-in-one, then reinstall the all-in-one (system driver only, no SharpCap bits) and then the SharpCap version you want to test. However, I am suspecting that you will not see a change in behaviour. This seems to be a camera control bug in the QHY SDK :(

Does your camera work correctly for actual imaging? Obviously this issue should not be a problem with longer exposures used for deep sky or the shorter ones used for lunar/solar/planetary, so it may be that it is only really a problem in the sensor analysis procedure.

cheers,

Robin
rockenrock
Posts: 68
Joined: Tue May 03, 2022 12:53 am

Re: Sensor Analysis

#17

Post by rockenrock »

Hi Robin,
I completely uninstalled all QHY driver, EZCap, and All in One. Uninstalled Sharpcap. Then installed latest QHY All in One without checking the SharpCap install. Then I installed the old SharpCap4.0.8973.0. I get the same result as before with latest SharpCap.... Using natural light. The ADU is constant at slightly different exposures, then suddenly the ADU jumps up. So now my dealer/friend is checking using his special light panel.
At any exposure setting, the ADU responds smoothly to changes in brightness. So the camera is good for longer exposures where +/- .02 sec does not really make a difference.
Unless they find something to fix on my camera, then I will have to give up on Sensor Analysis in Sharpcap with this camera.
I am new to it, but I recall trying to use the Brain function and it would not complete. Will the inaccurate exposures of my 168c, affect Brain function working? I think there is a sensor analysis library in SharpCap, so this would fill in for my failed Sensor Analysis?

Thanks,
Roger
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sensor Analysis

#18

Post by admin »

Hi Roger,

SharpCap does ship with a pre-installed sensor data file for the 168C in both 8 and 16 bit mode, so you should be able to use the smart histogram/brain functionality without needing to do your own analysis. The variation in measured values between different samples of the same camera model tend to be small for CMOS camers so this is usually not a problem.

cheers,

Robin
User avatar
Hibou
Posts: 81
Joined: Thu Jul 05, 2018 3:25 pm
Location: French Alps
Contact:

Re: Sensor Analysis

#19

Post by Hibou »

Robin points out that amp glow is much reduced in recent Sony IMX CMOS sensors, but some camera makers claim that their own circuitry eliminates it, eg for the Touptek (?) IMX492 camera marketed by TS-Optics
https://www.teleskop-express.de/shop/pr ... -1-mm.html

The similar ZWO ASI249MM-Pro using the same chip has obvious amplifier glow, though ZWO also claim that their circuitry eliminates it with their more recent cameras.

Apart from the amp glow, I like the ASI249MM-Pro because, with a minimum back focus of only 6.5mm, it is easy to fit short focus micro-4/3" lenses to it. The alternative APS-C ASI2600MM is claimed to not have amp glow, but the minimum back focus is 17.5mm which makes it difficult to use a micro-4/3" lens adapter.

So is it even possible to reduce amp glow on the earlier IMX chips with external circuitry ? I don't understand how that could work.
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sensor Analysis

#20

Post by admin »

Hi,

as far as I understand it, 'amp glow' is now an inaccurate term carried over from CCD imaging for similar image defects in CMOS sensors.

However, the causes are similar - heat, electronic noise or even perhaps emitted IR light from parts of the circuitry (including parts of the sensor itself) can lead to an additional signal that we call amp glow.

Manufacturers are understandably reticent about revealing exactly what they do to minimize this, but I have heard suggestions that altering the way that the sensor is driven, or the way that the data is read from the sensor can have an effect. I believe that the addition of significant RAM onboard some cameras may be related to this by allowing the sensor data to be read quickly.

Well designed supporting circuitry is an important part of getting a camera to work nicely - for instance the horizontal banding that you see when some CMOS images are stretched seems to be at least partly related to noise on the power feed to the sensor and can differ considerably for cameras using the same sensor but made by different manufacturers. Global shutter sensors (like the IMX174) seem to be minimally affected by this banding.

cheers,

Robin
Post Reply