[linux-uvc-devel] Leopard Imaging LI-USB3-C661C - sort of working.

[Erik Hovland]

We recently acquired a Leopard Imaging LI-USB3-C661C (color) camera.
We hooked it up to a NUC running Ubuntu 14.04. The camera was
recognized and when guvcview was brought up we can see see an image
displayed from the camera. The problem is that the image is all green
(see attached).

I am hoping that this is just a pixel packing or colorspace issue.
Hopefully someone can offer some advice on where to take this further.
It seems that during the dmesg output that under linux it reports as
the 'M' or black and white version of the camera.

This camera is supported by Leopard Imaging in Windows using their
software and we have demonstrated the camera working using that setup.
We have not gone as far as to see how that software communicates with
the camera, but it is our next likely step.

The dmesg log can be found here:
https://drive.google.com/file/d/0B5nx3Nn3ob43UTJsUzFCUDdPQWM/view?usp=sharing

The lsusb output is attached as well as an example image.

Thanks

E

[Oleksij Rempel]

This post might be inappropriate. Click to display it.

[Erik Hovland]

Post by Oleksij Rempel

Post by Erik Hovland
This camera is supported by Leopard Imaging in Windows using their
software and we have demonstrated the camera working using that setup.
We have not gone as far as to see how that software communicates with
the camera, but it is our next likely step.
https://drive.google.com/file/d/0B5nx3Nn3ob43UTJsUzFCUDdPQWM/view?usp=sharing
The lsusb output is attached as well as an example image.
Thanks

First step will be to test windows native uvc driver. Without camera
extras. If it is green, then this cam is not UVC webcam.
Then you can take a look to linux uvc driver and check if it is possible
to force some different colorspace for it.

Their camera tool requires the Windows native UVC driver to work,
although I don't know if that is only for transport. Any suggestions
of Windows programs to try that are known to only use the Windows UVC
driver?

Thanks

E

[Erik Hovland]

Post by Erik Hovland

Post by Oleksij Rempel

Post by Erik Hovland
This camera is supported by Leopard Imaging in Windows using their
software and we have demonstrated the camera working using that setup.
We have not gone as far as to see how that software communicates with
the camera, but it is our next likely step.
https://drive.google.com/file/d/0B5nx3Nn3ob43UTJsUzFCUDdPQWM/view?usp=sharing
The lsusb output is attached as well as an example image.
Thanks

First step will be to test windows native uvc driver. Without camera
extras. If it is green, then this cam is not UVC webcam.
Then you can take a look to linux uvc driver and check if it is possible
to force some different colorspace for it.

Their camera tool requires the Windows native UVC driver to work,
although I don't know if that is only for transport. Any suggestions
of Windows programs to try that are known to only use the Windows UVC
driver?

We tried the Windows 8 stock Camera app and it shows the same green
cast. So the CameraTool is doing something to get color.

Is it worth it to put in something like USBpcap to see what it is doing?

I have trying guvcview 2.0 as pending. I'll likely get to that tomorrow.

E

[Paulo Assis]

Hi,
I'm not sure what guvcview version you are using but if you could
increase verbosity:

(for version < 2.0.0) guvcview --verbose
(for version >=2.0.0) guvcview --verbosity=2

and post the console output it would help debug any colorspace issues.

Also if you could save a raw frame, that would also help (>= 2.0.0
just pick raw from the picture->save dialog).

Regards,
Paulo

Post by Erik Hovland
We recently acquired a Leopard Imaging LI-USB3-C661C (color) camera.
We hooked it up to a NUC running Ubuntu 14.04. The camera was
recognized and when guvcview was brought up we can see see an image
displayed from the camera. The problem is that the image is all green
(see attached).
I am hoping that this is just a pixel packing or colorspace issue.
Hopefully someone can offer some advice on where to take this further.
It seems that during the dmesg output that under linux it reports as
the 'M' or black and white version of the camera.
This camera is supported by Leopard Imaging in Windows using their
software and we have demonstrated the camera working using that setup.
We have not gone as far as to see how that software communicates with
the camera, but it is our next likely step.
https://drive.google.com/file/d/0B5nx3Nn3ob43UTJsUzFCUDdPQWM/view?usp=sharing
The lsusb output is attached as well as an example image.
Thanks
E
--
Erik Hovland
http://hovland.org/
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Linux-uvc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linux-uvc-devel

[Erik Hovland]

---------- Forwarded message ----------
From: Erik Hovland <***@hovland.org>
Date: Tue, Nov 25, 2014 at 9:02 AM
Subject: Re: [linux-uvc-devel] Leopard Imaging LI-USB3-C661C - sort of working.

Post by Paulo Assis
I'm not sure what guvcview version you are using but if you could

I installed guvcview 2.0.0 from the provided PPA.

Post by Paulo Assis
(for version < 2.0.0) guvcview --verbose
(for version >=2.0.0) guvcview --verbosity=2
and post the console output it would help debug any colorspace issues.

Attached.

Post by Paulo Assis
Also if you could save a raw frame, that would also help (>= 2.0.0
just pick raw from the picture->save dialog).

I saw no picture->save dialog so I used luvcview to save some raw
images. Here is a link:
https://drive.google.com/file/d/0B5nx3Nn3ob43UzNCa3Y5emZIamc/view?usp=sharing

Thanks

E

--
Erik Hovland
***@hovland.org
http://hovland.org/

[Erik Hovland]

Post by Erik Hovland
---------- Forwarded message ----------
Date: Tue, Nov 25, 2014 at 9:02 AM
Subject: Re: [linux-uvc-devel] Leopard Imaging LI-USB3-C661C - sort of working.

Post by Paulo Assis
I'm not sure what guvcview version you are using but if you could

I installed guvcview 2.0.0 from the provided PPA.

Post by Paulo Assis
(for version < 2.0.0) guvcview --verbose
(for version >=2.0.0) guvcview --verbosity=2
and post the console output it would help debug any colorspace issues.

Attached.

Post by Paulo Assis
Also if you could save a raw frame, that would also help (>= 2.0.0
just pick raw from the picture->save dialog).

I saw no picture->save dialog so I used luvcview to save some raw
https://drive.google.com/file/d/0B5nx3Nn3ob43UzNCa3Y5emZIamc/view?usp=sharing

Just so I have an email with our current state.

We were able to get the provided Windows program CameraTool to work
with the camera. When that tool comes up it shows the camera in black
and white mode. There is a property under options called 'MonoSensor'
and it is checked. If one unchecks it then another dialog 'PixelOrder'
becomes available. Under this dialog are the options: GBRG, GRBG, BGGR
and RGBG. If one selects RGBG, then the program displays a color image
that looks mostly correct beyond some white balance issues. It looks
like this option evaluates to an enum that means that the incoming
pixels are in RGBG order and it is calling a function called
ConvertBayer2BMP with that enum.

Thanks

E

[James Fidell]

Post by Erik Hovland
Just so I have an email with our current state.
We were able to get the provided Windows program CameraTool to work
with the camera. When that tool comes up it shows the camera in black
and white mode. There is a property under options called 'MonoSensor'
and it is checked. If one unchecks it then another dialog 'PixelOrder'
becomes available. Under this dialog are the options: GBRG, GRBG, BGGR
and RGBG. If one selects RGBG, then the program displays a color image
that looks mostly correct beyond some white balance issues. It looks
like this option evaluates to an enum that means that the incoming
pixels are in RGBG order and it is calling a function called
ConvertBayer2BMP with that enum.

I'm making a few guesses here as my experience is really only with
The Imaging Source cameras which are mostly implement a UVC interface
though they aren't strictly compliant...

It is possible that the camera may offer both raw colour frames (such as
is the case here) and ready-demosaiced frames. I believe both options
(and perhaps also "video" format frames such as YUY2 etc.) can be
offered concurrently by the camera within the UVC specification.

My recollection is that in that case the V4L2 spec should allow you to
choose which one you want. It's entirely possible however that either
the camera doesn't offer demosaiced frames or that gucview doesn't
allow selection of the frame type/decoding of raw frames and that's why
you're getting the green frames all the time.

I think you should be able to use v4l2-ctl to show all the possible
frame options (with the camera plugged in) and verify what is offered
by the camera. If it only offers a raw frame type then you'll probably
need a video application that can either demosaic on the fly if you
want to use them in real time, or post-process them if not. It's not
that uncommon for video applications to be able to handle RGB and video
format frames, but not raw ones.

Certainly I don't think this sounds like it's specifically a driver
problem at the moment. I'm more than willing to help further if I can,
but if it isn't a driver problem people may prefer that we take it
off-list.

(I'd guess it's a typo btw, but I think your pixel format might well be
RGGB.)

James

[Erik Hovland]

Post by James Fidell

Post by Erik Hovland
Just so I have an email with our current state.
We were able to get the provided Windows program CameraTool to work
with the camera. When that tool comes up it shows the camera in black
and white mode. There is a property under options called 'MonoSensor'
and it is checked. If one unchecks it then another dialog 'PixelOrder'
becomes available. Under this dialog are the options: GBRG, GRBG, BGGR
and RGBG. If one selects RGBG, then the program displays a color image
that looks mostly correct beyond some white balance issues. It looks
like this option evaluates to an enum that means that the incoming
pixels are in RGBG order and it is calling a function called
ConvertBayer2BMP with that enum.

I'm making a few guesses here as my experience is really only with
The Imaging Source cameras which are mostly implement a UVC interface
though they aren't strictly compliant...
It is possible that the camera may offer both raw colour frames (such as
is the case here) and ready-demosaiced frames. I believe both options
(and perhaps also "video" format frames such as YUY2 etc.) can be
offered concurrently by the camera within the UVC specification.

I think this camera only offers raw color frames. Especially since it
seems that their software doesn't do anything to the camera to produce
color, instead their software switches to a filter function.

Post by James Fidell
My recollection is that in that case the V4L2 spec should allow you to
choose which one you want. It's entirely possible however that either
the camera doesn't offer demosaiced frames or that gucview doesn't
allow selection of the frame type/decoding of raw frames and that's why
you're getting the green frames all the time.

I think I agree with this point. The camera doesn't offer demosaiced
frames and guvcview doesn't support the right decoding of the raw
frame. But really, guvcview shouldn't have to guess what the decoding
is. It would be nice if I could insert a filter in to guvcview that
did the decoding. I'll take a look, pointers appreciated.

Post by James Fidell
Certainly I don't think this sounds like it's specifically a driver
problem at the moment. I'm more than willing to help further if I can,
but if it isn't a driver problem people may prefer that we take it
off-list.

Right, from this point forward, I don't think there is anything that
the driver can do. It works the way it should.

Post by James Fidell
(I'd guess it's a typo btw, but I think your pixel format might well be
RGGB.)

I took some raw frames. I figure I can try out a few different decode
functions on the frames and see if I can't understand how to decode
them. If anyone has any advice on further directions, feel free to
contact me off-list.

Thanks

E

[James Fidell]

Post by Erik Hovland
I took some raw frames. I figure I can try out a few different decode
functions on the frames and see if I can't understand how to decode
them. If anyone has any advice on further directions, feel free to
contact me off-list.

Done.

James

[Erik Hovland]

In case anyone is interested, we were able to figure out what this camera does.

The camera reports that it is in YUYV format, but it turns out that it
was in bayer format (RGGB). Since it reports YUYV, guvcview, OpenCV
and Windows UVC driver all take the camera for its word (big mistake)
and the green image is produced.

At least in OpenCV with the cv::VideoCapture object, one can call
cv::cvtColor to turn the produced frame into a grayscale and then use
the bayer transfer (also in cv::cvtColor) to demosiac into a color
frame.

We have contacted the vendor to try to convince them to change how the
camera reports what is available, so that we can get the right format
in V4L2/uvcvideo.

Thanks again for all the help. It was invaluable.

E

Post by Erik Hovland

Post by James Fidell

Post by Erik Hovland
Just so I have an email with our current state.
We were able to get the provided Windows program CameraTool to work
with the camera. When that tool comes up it shows the camera in black
and white mode. There is a property under options called 'MonoSensor'
and it is checked. If one unchecks it then another dialog 'PixelOrder'
becomes available. Under this dialog are the options: GBRG, GRBG, BGGR
and RGBG. If one selects RGBG, then the program displays a color image
that looks mostly correct beyond some white balance issues. It looks
like this option evaluates to an enum that means that the incoming
pixels are in RGBG order and it is calling a function called
ConvertBayer2BMP with that enum.

I'm making a few guesses here as my experience is really only with
The Imaging Source cameras which are mostly implement a UVC interface
though they aren't strictly compliant...
It is possible that the camera may offer both raw colour frames (such as
is the case here) and ready-demosaiced frames. I believe both options
(and perhaps also "video" format frames such as YUY2 etc.) can be
offered concurrently by the camera within the UVC specification.

I think this camera only offers raw color frames. Especially since it
seems that their software doesn't do anything to the camera to produce
color, instead their software switches to a filter function.

Post by James Fidell
My recollection is that in that case the V4L2 spec should allow you to
choose which one you want. It's entirely possible however that either
the camera doesn't offer demosaiced frames or that gucview doesn't
allow selection of the frame type/decoding of raw frames and that's why
you're getting the green frames all the time.

I think I agree with this point. The camera doesn't offer demosaiced
frames and guvcview doesn't support the right decoding of the raw
frame. But really, guvcview shouldn't have to guess what the decoding
is. It would be nice if I could insert a filter in to guvcview that
did the decoding. I'll take a look, pointers appreciated.

Post by James Fidell
Certainly I don't think this sounds like it's specifically a driver
problem at the moment. I'm more than willing to help further if I can,
but if it isn't a driver problem people may prefer that we take it
off-list.

Right, from this point forward, I don't think there is anything that
the driver can do. It works the way it should.

Post by James Fidell
(I'd guess it's a typo btw, but I think your pixel format might well be
RGGB.)

I took some raw frames. I figure I can try out a few different decode
functions on the frames and see if I can't understand how to decode
them. If anyone has any advice on further directions, feel free to
contact me off-list.

[Paulo Assis]

This post might be inappropriate. Click to display it.