QHY-183M 8-16 bit images

Post Reply
Jean-Francois
Posts: 360
Joined: Sun Oct 13, 2019 10:52 am
Location: Germany

QHY-183M 8-16 bit images

#1

Post by Jean-Francois »

Hello Robin,

I receive some days ago a new QHY-183M camera .
I test it with SharpCap and I see some strange thing with the camera.

In 8-bit colour space:
The frame per second drops from ~ 6.5 fps at 155 ms exposure to 0.1 fps at 156 ms exposure with the version 3.2.6482-64bit.
The frame per second is stable around 155 ms exposure with the version 4.0.7785-64bit, but not 6.5 fps but only ~ 3.3 fps.
Does somebody already remark this ?
USB traffic = 0, no dropped frame.

In 16-bit colour space:
The saved images are not in 14 bits but only in 12 bits. An overexposed area has a value of 4094 in place of 16384 with both version (3.2 and 4.0).

In addition ... the image is not correct ... it seems that the full columns are shifted by 2 pixels.
I test the camera with the EZCAP and Prism (with ASCOM) softwares, here the results:

First row with EZCAP and last row with Prism, both have 4 columns with dark pixels and the detector ends with useful pixel.
With SharpCap ... only 2 columns on the left and 2 columns on the right with constant values (= 0 in 8 bit and = 2048)
QHY-183_software_test.png
QHY-183_software_test.png (61.59 KiB) Viewed 1329 times

I install the last driver with QHYCCD_Win_AllInOne.21.03.13.17 software.
In addition ... I test first with 4.0.7752.0-64bit and then with the last version 4.0.7785.0-64bit, but why do you "delete" the reticle with the Pixel-Readout ?

Can you have a look ?
The most important is to retrieve the full 14 bit ... If we buy a 14 bit camera, it is sometime good to have the full range.

Regards,
Jean-Francois
User avatar
admin
Site Admin
Posts: 13173
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: QHY-183M 8-16 bit images

#2

Post by admin »

Hi,

firstly the 183 camera only has 12 bit output from the sensor, so you will never get 14 bit data from it. If you found somewhere saying that this camera is 14 bit then that source is incorrect. This is the same for all brands that use the 183 sensor (QHY, ZWO, Altair, etc).

Next, the pixel value readout has moved from the reticules list to the tools menu in the latest versions of SharpCap 4.0 - it's a better place for that option.

On the subject of the bad data rows/columns around the camera image, these should be fixed if you use SharpCap 4.0 in 'still mode' and are using the camera in high bit depth (RAW16). SharpCap 3.2 does not have support for the parts of the QHY SDK required to remove these bars from the image and as far as I can work out trying to use the same features to remove them in RAW8 mode is not always successful. They should not show anyway if the camera is in video mode.

I'm afraid I don't know anything about the frame rate change at 155ms - SharpCap does not have any code that would change the behaviour of the camera at that exposure value, so it sounds like something buried in the SDK. I don't have that camera to test with, but did check my 294C, which has no similar effect that I could find. It would be interesting to see if anyone else sees the same thing.

cheers,

Robin
Jean-Francois
Posts: 360
Joined: Sun Oct 13, 2019 10:52 am
Location: Germany

Re: QHY-183M 8-16 bit images

#3

Post by Jean-Francois »

Hello Robin,

Sorry for the confusion. In reality I receive 2 cameras ... a QHY-183M cooled and a QHY-5III-178.
Yes, the 183 is only 12 bit and the 178 is 14 bit. (I mixed the bit value between the cameras, sometimes I think that the cooled camera has 14 bit).

The fact is that I note 4 problems ... one with the left/right columns, so that on the SharpCap images with the 183 camera, the 2 most right columns are constant @ 2048 ADU.

The second problem (not mentioned in my preceding message ... also new in this message) is that the saved image of the 183 camera is not saved with the correct value. Here with an image:
Camera_test_QHY183_8-16bit.png
Camera_test_QHY183_8-16bit.png (540.77 KiB) Viewed 1294 times
Same illumination, same exposure time and other parameters, only the 8/16 colour space is changed. The setting "Save 10/12/14 bit images in FITS file without scaling in 16 bit" is checked.

Left image: 8 bit colour space, view grey scaling from 0 to 255, note the dark grey and the pic position of the histogram.
Middle image: 16 bit colour space, view grey scaling from 0 to 4096 (12 bit), the image is darker and the pic is shifted to the black.
Right image: 16 bit colour space, view grey scaling from 0 to 2047 (11 bit), the image is now similar to the 8 bit view.

I perform the Sensor Analysis with both camera. Something is strange too with the 5-III-178 ... the result shows only a little bit more than 12 bit ... 12.3 bit dynamic range. I expect a little bit more than only 12.3 bit. The QHY-183 dynamic range is exactly 12.00 bit, I expect a little bit less than 12 bit.


Regards,
Jean-Francois

Note: why 2 new cameras ? ... I start end of February a new project. I'm not alone ... a lot of people starts with me the same project :-)
Here the link of this project: http://www.astrosurf.com/solex/sol-ex-p ... on-en.html

For this project ... I have an idea of a new tool in SharpCap ... a "Quick Scan" analysis of the video during the exposure.
User avatar
admin
Site Admin
Posts: 13173
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: QHY-183M 8-16 bit images

#4

Post by admin »

Hi,

I think I would recommend turning off the 'Save without scaling' option and see if the problem goes away - the problem with that option is that the data always comes to SharpCap as 16 bit and then SharpCap has to undo the scaling that the QHY SDK has already applied. In order to undo the scaling, SharpCap needs to know the bit depth of the sensor, which it has to ask the SDK about. It's not unknown for hardware manufacturers to get this information wrong on some cameras, which then means this feature in SharpCap will not work correctly.

The dynamic ranges sound about right - SharpCap calculates these are FWD / Read Noise. Perhaps you would expect a little over 12.5 for the 178, but it would be worth looking at the FWD and read noise values to see if any differ markedly from other measurements on the same sensor (ZWO put graphs for their models on their web site).

cheers,

Robin
Post Reply