Capture with ascom yield 14bit data in a 16bit container (not scaled)

[Former user]

Nina 1.10, qhy294c (dlls manually copied from sdk 2019-11-15)

I'm not if it's something I'm doing wrong, but here is the simplest way to describe it.

My cam is 14bit, when capturing using native driver I get values up to 65k when overexposing. I don't know if it's the driver that scales the values or nina.

When using ascom driver I also get values up to 65k when overexposing ..all good

Then I took flats (white tshirt) method) with the wizard.

Using native driver, it detected optimal exposure of 0.06s. mean value in fits where good, around 30k adu.

Using the ascom driver (5mins later same sky conditions), wizard complained it was too bright as it detected optimal being 0.02s. I asked to continue (to keep brightness source the same). Mean value in fits where around 8k ..which is good for 14bit scale, BUT isn't supposed to be 16bit scaled?

Fit header in both captures show "bitpix"=16.

Fits captured with same config (offset 0, temperature -30c 1600gain).

Let me know if I should provide fits, logs or any other information.

[Daniel Lorenzo]

Im the one who created this issue, I was able without logging in ..didn't notice

[Daniel Lorenzo]

Just wanted to add that I think it is the flat wizard that interpret 16bit data as if it was 14bit maybe because it know that camera specs are 14bit?

I'd like to change this issue title to reflect what I think.

[Daniel Lorenzo]

According to the qhy manual

https://www.qhyccd.com/index.php?m=content&c=index&a=show&catid=30&id=212

"05 Using QHY294C in ASCOM
QHY294C works on many software that supports the ASCOM platform. Currently QHY294C only supports regular ASCOM connection, but does not support ASCOM VIDEO connection. It should be noted that the QHY294C will always transmit the largest bit depth to get the best DSO imaging performance. The format of the image is 16bit, the high bit is aligned, and the low bit is zero."

[Dale Ghent]

Did you put a value of 14 under Options → Equipment → Camera → Bit Depth? If so, make it 16…. or just use the native driver. That bit depth value should not reflect the senor’s native output, but the bit depth of the pixel data we get. If it’s 14 bit unscaled, a 14 would go there. But we get 14 scaled to 16 from the camera, so 16 should be there.

[Daniel Lorenzo]

Indeed, the “Bit Depth” field is set to 14.

Soon, I will try again capturing flats with value set to 16.

I suppose these value were populated by camera specs… If this effectively fixes the flat wizard issue, I suggest that the wizard uses the bit depth in the fits header when possible/available instead of the Bit Depth value in equipment section.

[Daniel Lorenzo]

Changing the bit depth in the equipement section worked. I was able to use the flat wizard and got consistent results wheter it was with ascom or native driver.

Its odd to put 16 in settings and leave max adu value to 16353.. Anyway I still think the flat wizard should check the headers of the outputted image instead of camera specs when possible.

[Stefan B]

the output image header will always specify 16 bit data. there is no 12bit or 14bit data format for fits available and this header is created and set by nina.

i’m not sure if the ascom driver does bit shift the data, but the native driver will do that. Due to this mix of behavior through different brands we need this setting inside the options, as not all brands provide the bit depth on their own.

‌

[Dale Ghent]

No, you should have the correct bit depth set. As I explained, this value should reflect the data we get from the camera and its SDK, not the bitness of the sensor. If the camera takes a 14 bit (or 12 bit) sensor and scales it to 16 bit internally, and hands the data to us and says “This is 16 bit data” then that’s what we have to believe. As a matter of course, the QHY SDK will hand out either 8bit or 16bit data. There is no other possibility.

[Daniel Lorenzo]

Ok I understand, thanks for the clarifications.

Should I set also the Full Well capacity (max adu?) according to the 16bit depth setting?

It as been automatically set to 16383, which is 14bit max range.

[Daniel Lorenzo]

I suppose not everyone would have needed to do this. The bit depth was set automatically upon detection, I think based on camera specs.

I suggest the tweak I had to do be part of the documentation, perhaps in the flat wizard section. A notice for future users like me.

[Stefan B]

yes i agree that this setting is causing confusion. I also am trying to find a way to get rid of it altogether, but failed to get it consistent yet.

[Daniel Lorenzo]

Maybe always assume 16bit images and specific cameras can use the upscale option in the equipment section? or even a separate advanced setting in the flat wizard section, that defaults to 16