Touptek ITR3CMOS01300KMA (GLUX9701BSI)

[lateralus35]

Hi,

I have a touptek ITR3CMOS01300KMA(gpixel GLUX9701BSI sensor) camera and I'm trying to run a sensor analysis on it. It keeps giving me the error that the "Exposure is too short. Reduce lighting to increase exposure to at least 0.1s". I've set my phone to the dimmest and also used multiple layer of Kleenex(to the point it is extremally dim) but still the same issue.

Also, when I use the ascom drive Sharpcap is crashing. Native drivers seems to work fine.


Thanks

[admin]

Hi,

the exposure needs to be relatively long at the start of the analysis process, since during the analysis the gain will be increased and that will reduce the exposure quite a lot. If the initial exposure is too short then the minimum exposure might be reached later on which would spoil the measurements.

You could try a sheet (or 2 or 3) of white A4 paper between the phone screen and the camera to dim the light level down, or just do away with the phone (they are a bad choice for this, since they tend to auto-adjust the screen brightness based on the environment light level, and that's the last thing you want to happen). Wait until it is dark out so that interiour room lighting is the only contribution to light, and then try experimenting with the camera in different places (under a desk, behind a monitor, in a shadowed corner, etc) until you find one with the right level. In that sort of set up it's best to sit still during the process so you don't change the light level by moving about.

It's usually best to ignore the ASCOM option for cameras that are directly supported in SharpCap. The ASCOM drivers are a great option when you want to use a camera in an application that doesn't support it directly, but the direct support almost always gives more of the camera features and better performance.

cheers,

Robin

[lateralus35]

Ended up having to use 8 layers of paper sheets.My phone was set to the lowest brightness (auto brightness turned off). That sensor is crazy sensitive.

[lateralus35]

Hi,

the exposure needs to be relatively long at the start of the analysis process, since during the analysis the gain will be increased and that will reduce the exposure quite a lot. If the initial exposure is too short then the minimum exposure might be reached later on which would spoil the measurements.

You could try a sheet (or 2 or 3) of white A4 paper between the phone screen and the camera to dim the light level down, or just do away with the phone (they are a bad choice for this, since they tend to auto-adjust the screen brightness based on the environment light level, and that's the last thing you want to happen). Wait until it is dark out so that interiour room lighting is the only contribution to light, and then try experimenting with the camera in different places (under a desk, behind a monitor, in a shadowed corner, etc) until you find one with the right level. In that sort of set up it's best to sit still during the process so you don't change the light level by moving about.

It's usually best to ignore the ASCOM option for cameras that are directly supported in SharpCap. The ASCOM drivers are a great option when you want to use a camera in an application that doesn't support it directly, but the direct support almost always gives more of the camera features and better performance.

cheers,

Robin

Here are my result. Looks like running the camera in HDR mode is the way to go. In HDR its weird that the read noise and full well do not change relative to the gain. Looks like the gain setting is locked in HDR so there is no point in changing gain in that mode? Also, sensor linearity does not look great.

Also, is the MONO16(Ultra Low Noise) the same as the Touptek "Low Noise" option?

HDR

HDR

HDR.jpg (101.58 KiB) Viewed 2857 times

HDR+MONO16 (Ultra Low Noise)

HDR+LowNoise.png (69.79 KiB) Viewed 2853 times

HCG

HCG

HCG.jpg (96.79 KiB) Viewed 2857 times

[admin]

Hi,

I would guess that there is a bug in the SDK that is stopping the gain from working properly in HDR mode (unless that particular sensor has a fixed gain HDR mode - I have now experience with that sensor, so maybe that is the reason). You are correct that the 'Ultra Low Noise' option is the same as 'Low Noise Mode'.

Usually the cause of low linearity scores is variable illumination during the calibration process - I would tend to assume that is the cause until proven otherwise by calibrating with alternate light sources that you can be sure do not vary.

Otherwise, the two lower graphs look fairly reasonable.

cheers,

Robin

[lateralus35]

I ran couple sensor analysis in HDR mode and I'm getting weird results. I'm also getting some sort of banding in the image(see bottom image). A bit like when your filming a crt camera with a camera. USB speed seems to influence the the thickness of the banding.

I thought read noise was not temp sensitive:

HDR_TEMP4.png (354.3 KiB) Viewed 1750 times

HDR_TEMP3.png (355.83 KiB) Viewed 1750 times

HDR_TEMP2.png (314.23 KiB) Viewed 1750 times

HDR_TEMP1.png (330.31 KiB) Viewed 1750 times

HDR_TEMP1.png (330.31 KiB) Viewed 1750 times

[admin]

Hi,

there's something odd going on here - firstly in all of the graphs, there is no variation in e/ADU or read noise with the gain value setting - that would tend to imply that the gain control isn't actually doing anything with this camera (note that the relative gains are all the same). I can understand that maybe the camera doesn't have a gain adjustment, but in that case you'd expect the gain control to report itself as unavailable or to have zero range. Given that the gain control does have a range, I'm wondering if this is some SDK bug that is preventing the gain on the camera being set properly when new values are sent to the gain control.

On the flip side, the various runs that you have shared screenshots for show different e/ADU measurements - these cause the other values to come out differently (basically, the e/ADU measurement that is done initially at minimum gain gives a scaling for all the other measurements). Given this, it's worth watching the first graph that comes up when the analysis is doing the e/ADU measurement - it should be a nice straight line. If it isn't, then (a) something isn't quite right and (b) random variations in the data and trying to measure the straight line out of less than ideal data might lead to the various e/ADU values.

For the last image with the banding, to me that looks like the interaction between flicker of artificial lights and the progressive scan of the sensor. Try reducing the illumination level and increasing the exposure well above 0.1s and see if that reduces the bands - it should if it is the flicker causing it.

cheers,

Robin

[lateralus35]

there's something odd going on here - firstly in all of the graphs, there is no variation in e/ADU or read noise with the gain value setting - that would tend to imply that the gain control isn't actually doing anything with this camera (note that the relative gains are all the same). I can understand that maybe the camera doesn't have a gain adjustment, but in that case you'd expect the gain control to report itself as unavailable or to have zero range. Given that the gain control does have a range, I'm wondering if this is some SDK bug that is preventing the gain on the camera being set properly when new values are sent to the gain control.

Touptek confirmed that the gain was not user changeable in HDR mode(it is if using HCG or LCG mode). Would it be possible that it's the actual gain that is not being reported correctly or at all? I think that it should at least report the Rel.Gain being applied even if it does not scale with the gain range.

On the flip side, the various runs that you have shared screenshots for show different e/ADU measurements - these cause the other values to come out differently (basically, the e/ADU measurement that is done initially at minimum gain gives a scaling for all the other measurements). Given this, it's worth watching the first graph that comes up when the analysis is doing the e/ADU measurement - it should be a nice straight line. If it isn't, then (a) something isn't quite right and (b) random variations in the data and trying to measure the straight line out of less than ideal data might lead to the various e/ADU values.

The e/ADU seems to scale with the temp. TEMP4 image is -9.90C and e/ADU is 0.27 while the TEMP1 image is 39.9C and e/ADU is 0.44. All other run scale depending on the temps(higher temp = higher e/ADU). In any cases, it should not be like that either. There is definitively something funny going on.

For the last image with the banding, to me that looks like the interaction between flicker of artificial lights and the progressive scan of the sensor. Try reducing the illumination level and increasing the exposure well above 0.1s and see if that reduces the bands - it should if it is the flicker causing it.

That's what I thought. Can it influence the results?


I will try to contact Touptek regarding the above issues. I just hope I won't have to fight too much to get help. So far they were unable to answer my questions regarding the dual gain settings in HDR mode. Plus you add those 2 issues. I think I will probably have to run the camera in HCG Ultra mode and more shorts exposure to compensate for the lost of DR in HDR mode.

[admin]

Hi,

thanks for the update - I wonder if the SDK does report a fixed gain in HDR mode, but maybe SharpCap just doesn't re-query the range on the assumption that the range is fixed for a particular camera (it has been up to now).

For the horizontal banding, if you see that during the analysis, make the measurement box tall and narrow so that it covers a number of bands - that will reduce the impact of the banding on the measurements.

cheers,

Robin