OpenCV for the QHY5 on Linux

[HenkSB]

I want to use my QHY5 with OpenCV on the Raspberry Pi.  From what I know so far OpenCV supports v4l2.  So if the QHY5 driver is a v4l2 driver it should work without a problem.  But it does not. 

Looking at the PHD2 code I see that it is used with the plain libusb API, so perhaps the QHY5 driver is a plain USB driver but not a v4l2 driver.  The device is listed as /dev/QHY5 while I suspect it should be /dev/video0 because v4l2 is a video driver.  Yet, I have seen Python code (at http://sy2000.blogspot.com/) that uses the QHY5 with OpenCV happily, unfortunately little was said about the driver. 

Any suggestions?  Thanks in advance.

[HenkSB]

(BUMP!)  Sorry to bump this but maybe I started this thread at the wrong time being not in the mainstream SGL continent.  I noticed a good deal of  Linux/RasPi savvy posts on here so please chime in.  Maybe I should have picked the DIY forum?

Anyway what I found meanwhile is that QHY has published a Linux SDK on git but no source code.  Even then, their API does not seem to have anything to do with v42l or OpenCV.  So I am still puzzled what supports the Python code in that link. 

Any help appreciated, thanks again.

[HenkSB]

Reading that link again there is actually no reference to a QHY5 just "USB camera" so I must have had the links in my head messed up.  Nevertheless if anyone knows an OpenCV or v4l2 driver for QHY5 I would appreciate it.

[SteveBz]

Hi HenkSB,

Did you make any progress here. I'm on the exact same voyage. 

One of the problems with opencv is that you have to twist its arm for a 16 bit imread. There is a flag that you have to set (cv_any_depth or something from memory). Zwo asi120 is much easier, so I may swap out my qhy for zwo if I can't fix it.

Steve.

[NickK]

Surely it's just recompiling the OpenCV .. as long as it has a back end for SIMD instructions. There is an OpenCL variant of OpenCV but the issue there is, again, the GPU code needs to be specific for the architecture to get any real performance boost - especially with the shared memory systems on embedded (such as PI and Odroid etc).

 

[SteveBz]

On 18/11/2017 at 11:17, NickK said:

Surely it's just recompiling the OpenCV .. as long as it has a back end for SIMD instructions. There is an OpenCL variant of OpenCV but the issue there is, again, the GPU code needs to be specific for the architecture to get any real performance boost - especially with the shared memory systems on embedded (such as PI and Odroid etc).

 

I used apt-get, but do you mean wget/make/make install?  Will that link the QHY5 code?

I could try it.

Regards

Steve

[NickK]

11 hours ago, SteveBz said:

I used apt-get, but do you mean wget/make/make install?  Will that link the QHY5 code?

I could try it.

 

You may find that you need additional dependencies - sometimes you can apt get the source packages.

Judging by your original post - it sounds like there's a piece of code or a configuration that is needed.

Sometimes drivers installed only detect each other at start up so also worth trying a reboot.

[JamesF]

Only just seen this.

There are no V4L2 drivers for any of the QHY cameras that I am aware of.  The QHY libraries provide a user-space interface layered on top of libusb and as already noted, they're closed source (pretty much the same case as for the ZWO cameras, to be fair).  The impression I have is that resources for developing the SDK are limited, so they're focusing on specific cameras at the moment.  I'd guess as they're a business those are the ones that are most "interesting" commercially from their point of view.  Getting new V4L2 drivers into the kernel is likely to be quite a time-consuming affair and their code is currently C++ which I believe would need to be converted back to C, so I think it's unlikely they'd ever bother to try.

I've not checked, but I'm not aware that OpenCV supports using the QHY SDK directly to grab frames.

I've written open source drivers for the QHY5, QHY5-II, QHY5L-II and QHY6 that work on Linux and OSX and in the next (imminent) release I've added support for the IMG132E, but again they're layered on top of libusb so there's no V4L2-style interface.  I'll probably add more in the future.  I might even "do requests" as long as I can get hold of a camera to work with, but (for QHY cameras at least) they'll still be using libusb.  Writing a V4L2 kernel driver isn't an itch I feel a desperate need to scratch unless someone else has an itch go give me a large pile of cash to do so

So, that's pretty much where you are...  No V4L2 driver, possibly you can use the QHY SDK and bodge up what you need to make it work with OpenCV as long as it supports the camera you want to use, or you're welcome to take my interface and do the same/use it as you wish (or even just rip out the driver code and use that).

James

[SteveBz]

On 17/12/2017 at 00:06, JamesF said:

Only just seen this.

There are no V4L2 drivers for any of the QHY cameras that I am aware of.  The QHY libraries provide a user-space interface layered on top of libusb and as already noted, they're closed source (pretty much the same case as for the ZWO cameras, to be fair).  The impression I have is that resources for developing the SDK are limited, so they're focusing on specific cameras at the moment.  I'd guess as they're a business those are the ones that are most "interesting" commercially from their point of view.  Getting new V4L2 drivers into the kernel is likely to be quite a time-consuming affair and their code is currently C++ which I believe would need to be converted back to C, so I think it's unlikely they'd ever bother to try.

I've not checked, but I'm not aware that OpenCV supports using the QHY SDK directly to grab frames.

I've written open source drivers for the QHY5, QHY5-II, QHY5L-II and QHY6 that work on Linux and OSX and in the next (imminent) release I've added support for the IMG132E, but again they're layered on top of libusb so there's no V4L2-style interface.  I'll probably add more in the future.  I might even "do requests" as long as I can get hold of a camera to work with, but (for QHY cameras at least) they'll still be using libusb.  Writing a V4L2 kernel driver isn't an itch I feel a desperate need to scratch unless someone else has an itch go give me a large pile of cash to do so

So, that's pretty much where you are...  No V4L2 driver, possibly you can use the QHY SDK and bodge up what you need to make it work with OpenCV as long as it supports the camera you want to use, or you're welcome to take my interface and do the same/use it as you wish (or even just rip out the driver code and use that).

James

Hi James,

Great answer. Have seen the zwo python interface interface? Do you have a view on it?

I felt if I only needed to grab the occasional frame maybe zwo would be easier.

Regards

Steve.

What do you think?

[JamesF]

Haven't looked at the Python interface, I have to admit.  Many moons ago I worked as a developer (mostly in C and assembler) for a company whose main business was COBOL development tools.  I've been unable to overcome my aversion to languages dependent upon indentation ever since   I recognise that's no fault of Python's.  I don't know why.

Grabbing the occasional frame should certainly be fairly easy with the ZWO cameras and I believe the same sort of thing should work with some of the newer QHY cameras and their SDK too (the QHY5L-II, for instance).  There is also an SDK for the Toupcam cameras which I think could be made to work.

If you want to stick with the V4L2 interface and OpenCV can do all the work then you could also look at some of the USB TIS and Celestron monochrome cameras.  Many are UVC compliant, so are handled by the kernel (colour ones are more tricky though).

James