Incorrect/different sensor size on QHY-600M

[archer1960]

In all my tests, I disconnected and reconnected the camera, but didn't think to try changing the resolution...

[Jean-Francois]

Hello Robin,

glad we got there in the end

Not with my QHY600 or QHY268 ... Something is still not fine.
It crashed 2 times SharpCap with the "Try to exclude Overscan Area" (maybe you received a report).

But it is not correct for "Include Overscan Area" ... I did the test here with QHY268 camera:

QHY_Overscan.jpg (200.51 KiB) Viewed 456 times

It is 3 times the lower part of the detector with the left and right side together.
The "Pixel Value Readout" shows the pixel coordinates.

In the Still Mode(s) ... also Still Mode and LiveView with Force Still Mode, then it is fine.
But the Live View is not ... the image is shifted horizontally (2 pixels) and it seems that the missing 2 columns on the left appears on the right.

Note the black pixels are really = 0 value.

Regards,
Jean-Francois

[admin]

Hi Jean-Francois,

thanks for the heads up on the further issues - they seem to be caused by an additional pan/tilt being allowed by SharpCap when it shouldn't be (due to the offset of the effective area already using up all the available pan/tilt allowance). From the pan/tilt values set I suspect it is SharpCap trying to keep the ROI centered after a resolution or other change (the values set are half the maximum values). I must admit that I did think of that scenario, but I couldn't persuade anything to break when testing, so came to the conclusion that everything was OK.

So, I can fix the crash issue for the next update. Unfortunately on the black bars, I'm not even in a position to try to fix that - I have to work with the data that the SDK gives me on where the 'effective' area of the sensor is. It doesn't come out quite right on my 294PRO-C either, but as far as I can work out there is no other information to work with. So, even with the camera I have, I can't find a way to properly set up the SDK in still mode to capture the full active area of the SDK without me having to input magic numbers (measured pixel sizes and offsets) into the code. It's incredibly frustrating and I'm close to giving up on trying to fix this sort of issue

cheers,

Robin

[Jean-Francois]

Hello Robin,

I tested yesterday evening the new settings for the overscan handling ... here the summary of all the images with my QHY268 (not QHY600), but it can may be similar with the QHY600.

QHY268_Overscan_StillMode-LiveView.jpg (859.32 KiB) Viewed 384 times

I tested the 3 selections ("Classic", "Include" and "Try to exclude").

From the left to the right ...
The LiveView has all the time the overscan when to "Force Still mode" is OFF. It works partly as expected ... on the far right side of the image ... several full black columns should not be present.

With the LiveView when "Force still mode" is ON. It works. But in the case with the overscan visible ... the right side is not the same as the LiveView with overscan (on the left). In this case, the image will be not compatible with other "full" detector images done in LiveView-Force-OFF.

The Still Mode is fine too ... the new settings has no effect. I did not check that the dark pixel positions are exactly the same as the images without overscan with Force-ON.


Regards,
Jean-Francois

[admin]

Hi Jean-Francois,

thanks for reporting. My summary of this would be as follows I guess

* Still no success in excluding the overscan area properly in live view with 'force still mode' set to off (this is the case when the camera is truly in video mode). At least, still no success on this model

* 'Include' gives weird results in live view with force still mode on

* The results are still model dependent (you see different results to mine on the 294PRO-C).

I have a feeling that this is never going to be fully resolved (at least, not without proper SDK support that is less confusing to work with).

cheers

Robin

[Jean-Francois]

Hello Robin,

OK, that means that each observer has to perform a check with his camera and then use the working settings ... and no more change.
With the hope that the SDK update does not break some parts.

Regards,
Jean-Francois