QHY410C pixel size and bit depth confusion (SDK-driver and N.I.N.A. settings)

As far as I know if the ADC is 14 bit you should enter 14 bits in the settings but normally NINA sets that according to the info provided by the drivers. Now, is a matter of record that QHY's drivers can be somewhat, what shall I say, odd so I'm not really sure there. You can try to override the spe'd pixel size in NINA, and it should find its way into the FITS header. Not the a difference of 0.33% makes any practical difference anywhere…

Hello fellow IMX410 user!

Yes, you are correct that despite the A/D converter being 14 bit, it is a 16 bit output. You will run 16 bits FITS.

I could be wrong, but the reason the 14 bit output is noisy is because its taking an interpolated 14 to 16 bit file and reducing that back to 14 bit using the interpolated values. I wish I could output 14 bit direct from the camera, but on the contrary, I really, really wish the camera would have been equipped with a 16, or even 18 bit ADC from default. (I'll see about doing something evil in the future after I monochrome convert this camera.)

The pixel size being wierd doesn't matter too much, I've seen conflicting numbers from A7III, ASI2400, and QHY410C, which all use the same sensor. I've gotten 5.91um from my A7III, 5.94 from ASI2400 and now I've seen 5.96 from your 410C. I'm thinking there is a margin of error of +-.03um. Part of me thinks that could be a QHY SDK typo, as newer 533/571/455/461/411 sensors all use 3.76um arrays, makes me wonder if someone that wrote the code after looking at the chart said "three point seven… wait no, five point nine six!"

I think that because it is such a small value your platesolving wont be so affected, .02um is not a very large size difference in regards to sampling, in my mind it will likely give you the same results as a correct number in the end.

V:
Hello fellow IMX410 user!

Yes, you are correct that despite the A/D converter being 14 bit, it is a 16 bit output. You will run 16 bits FITS.

I could be wrong, but the reason the 14 bit output is noisy is because its taking an interpolated 14 to 16 bit file and reducing that back to 14 bit using the interpolated values. I wish I could output 14 bit direct from the camera, but on the contrary, I really, really wish the camera would have been equipped with a 16, or even 18 bit ADC from default. (I'll see about doing something evil in the future after I monochrome convert this camera.)

The pixel size being wierd doesn't matter too much, I've seen conflicting numbers from A7III, ASI2400, and QHY410C, which all use the same sensor. I've gotten 5.91um from my A7III, 5.94 from ASI2400 and now I've seen 5.96 from your 410C. I'm thinking there is a margin of error of +-.03um. Part of me thinks that could be a QHY SDK typo, as newer 533/571/455/461/411 sensors all use 3.76um arrays, makes me wonder if someone that wrote the code after looking at the chart said "three point seven... wait no, five point nine six!"

I think that because it is such a small value your platesolving wont be so affected, .02um is not a very large size difference in regards to sampling, in my mind it will likely give you the same results as a correct number in the end.

I would love to see some details on the mono conversion. I always feel a bit ripped off that companies charge more for mono versions verses the color versions of the same camera.

andrea tasselli:
14 bit images are usually right-shifted to fit in 16-bit words, not interpolated. Just look at the BZERO word value in the FITS header. Acid-stripping/solvent-stripping the outer layer from a sensor isn't for the faint of hearts and may well ruin everything.

Just wondering if the methods have improved past the caveman stage.