openpnp-capture multiple cameras

[Jason von Nieda]

Continuation of https://groups.google.com/d/msgid/openpnp/84a4e97f-122f-4db7-8bf5-90b3743982f4%40googlegroups.com?utm_medium=email&utm_source=footer

Marek said:

Hi Jason,

Don't be upset, but on my two computers with W7-64 AMD-A8 I cannot run two ELP on the same USB controller. Openpnp_capture not Opencv driver.
It was some time ago when I fighted with this. I remember I can run them if set some very low resolution (320x250?) and some very low FPS (2-3fps?) , I'd have to reproduce it.
Here at home I have some web + ELP which also works wrong if they are connected to the same host.
If you have a time for analyses and want to get some test result, tell me what exactly you want me to set (parameters) and I can give you an effect feedback.

You can tell I repeat this for months maybe year but it is the fact in my case.
Note, I decided that it does not make sense to report it to you any more and get answers "it's not true".
I have mounted additional controller and take it as "it must be so"...

I suspect that the problem is probably "Windows 7". Maybe Mark is using this too?

The easiest way to determine if this is a openpnp-capture issue is to see if you can get the correct behavior in another app. OBS (Open Broadcast Studio) is a good app for testing webcams, although it's just one of many. See if you can find a piece of software that will allow you to show both cameras at once at a resolution and frame rate you find acceptable. Most of these apps use the same mechanisms we use in openpnp-capture so if they can do it we should be able to, too. If not, there may be a bug.

For what it's worth, I do all my testing on Windows 10. I don't "officially" support Windows 7, but if we can make it work without too much trouble then we might as well.

Jason

[Mark]

Thanks Jason

 

I moved this over here, including your answer below, fused to Mareks answer.

 

> I am honestly just so tired of reading this incorrect claim. I invite you to *test* it yourself. Hook up two ELP (or other well behaved) cameras and actually try it, as I did, repeatedly. As Neils did *while developing the library* you are quoting. It works correctly on all three operating systems. This was the entire reason we undertook the months long development effort and is the reason we released it when it was *tested* and finished.

 

Oh, believe me, I tried and tried again. And I reported the issue here.

https://github.com/openpnp/openpnp/issues/717#issuecomment-381389641

and here:

https://groups.google.com/d/msg/openpnp/fVv7PvArwiQ/-uqPOGoSCgAJ

and here:

https://github.com/openpnp/openpnp/issues/687#issuecomment-381394138

 

 

I just tried again with develop branch built 2018-11-20. Two ELP “6mm 2MP Full HD High Speed MJPEG USB” cameras on a new USB 2.0 external hub (tried various hubs including a USB 3.0 hub – to no avail).

 

Second Camera stays black. No error messages in Log or stderr:

 

The same hardware on a separate root hub:

 

Please note that there are different ELP cameras. Mine are the “6mm 2MP Full HD High Speed MJPEG USB” (ebay listing no longer active).

 

920 (H) x 1080 (V) pixels MJPEG 30fps YUY2 6fps

1280 (H) x 1024 (V) pixels MJPEG 30fps YUY2 6fps

1280 (H) x 720 (V) pixels MJPEG 60fps YUY2 9fps

1024 (H) x 768 (V) pixels MJPEG 30fps YUY2 9fps

800 (H) x 600 (V) pixels MJPEG 60fps YUY2 21fps

640 (H) x 480 (V) pixels MJPEG 120fps YUY2 30fps

352(H) x 288 (V) pixels MJPEG 120fps YUY2 30fps

320 (H) x 240 (V) pixels MJPEG 120fps YUY2 30fps

 

There are slower ones like the “ELP 6mm 1.0MP 720P HD MJPEG USB Camera”

 

1280 (H) x 720 (V) pixels MJPEG 30fps YUY2 10fps
960 (H) x 720 (V) pixels MJPEG 30fps YUY2 15fps
800 (H) x 600 (V) pixels MJPEG 30fps YUY2 20fps
640 (H) x 480 (V) pixels MJPEG 30fps YUY2 30fps
352(H) x 288 (V) pixels MJPEG 30fps YUY2 30fps
320 (H) x 240 (V) pixels MJPEG 30fps YUY2 30fps
176(H) x 144 (V) pixels MJPEG 30fps YUY2 30fps
160 (H) x 120 (V) pixels MJPEG 30fps YUY2 30fps

 

Doubling the FPS on the same resolution might explain why USB 2.0 is still flooded by the fastest hires cameras. I don’t know which camera Niels used for testing. However in my view it is to be expected that the best cameras will exploit whatever bandwidth they can get.

 

For me this  is no issue except perhaps for the misleading Wiki entry I reported. The bandwidth limitation is in hardware and I don’t see how OpenPNP could solve it universally (true USB 3.0 cameras will in time).

 

However, not being able to set a custom FPS and therefore reducing the bandwidth might be considered an issue. I opened such an issue in openpnp-capture now:

https://github.com/openpnp/openpnp-capture/issues/29

 

But like I explained in this thread, I believe that high FPS is actually a good thing for low latency. So I personally rather live with two USB connectors from the machine, saving time on each vision capture. I’m also not so sure that the camera hardware would actually support reducing FPS. So I consider this a low priority issue.

 

Yes I’m using Windows 7. Maybe that’s the reason. But frankly I doubt it.

 

For a test of said cameras see here:

https://makr.zone/camera-selection/262/

 

_Mark

 

Von: ope...@googlegroups.com [mailto:ope...@googlegroups.com] Im Auftrag von Jason von Nieda
Gesendet: Montag, 3. Dezember 2018 16:47
An: ope...@googlegroups.com
Betreff: Re: [OpenPnP] disable move to safe z

 

Hi Mark,

 

The "physical FPS" I am referring to is part of the "format". The formats are enumerated by the camera and one is chosen. The custom FPS field you are referring to as not implemented was added to provide a way to reduce the frame rate from the max, instead of just using the max.

 

I'm not claiming that there isn't latency - of course data takes time to move through the various systems - but there is no piling up of frames when OpenPnP isn't keeping up with reading them. When OpenPnP calls Camera.capture() for a vision operation the image it will get will be the last one processed by the camera.

 

In case it's been lost in the thread, the claim I was refuting was:

 

When 2 can't take the 10 FPS all the time then the data from the camera will
buffer up somewhere on the way and when the vision wants a picture it will
not get a fresh image from the camera, it will gets the oldest picture from
the buffer.
If 2 stalled for some reason, then the "fresh" picture can be as old as the
stall.

 

Again, this is *very easy* to test and prove if you want to see it yourself. openpnp-capture has a simple interface that you can write a test program for in about 10 minutes. Capture an image, write it to disk, sleep for 10 seconds and during those 10 seconds change what is in view of the camera. Capture an image, write it to disk. Look at the two images.

 

I'm not talking about a theoretical system - I'm talking about what happens in OpenPnP today.

 

a) why one USB Root Hub can still only manage one camera even with MJPEG compression (as tested under Windows) and

 

I am honestly just so tired of reading this incorrect claim. I invite you to *test* it yourself. Hook up two ELP (or other well behaved) cameras and actually try it, as I did, repeatedly. As Neils did *while developing the library* you are quoting. It works correctly on all three operating systems. This was the entire reason we undertook the months long development effort and is the reason we released it when it was *tested* and finished.

 

If you are unable to get two cameras working on a single hub please file a bug report with details on the cameras, operating system, and USB tree. We will attempt to reproduce and fix it.

 

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jw7fG2Euvoiv9_4kyn7_yfWxDZ-Z3ufPXym3n-UhhfO7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Marek T.]

I don't remember the soft name that used to test it instead of Openpnp.

But I remember that using it two cameras 2Mpx/25fps connected to the same controller worked without any problems (at occasion with minimal CPU load, some 3-5%).

Unfortunately I have now at home only webcam and ELP that gives no video (something failed in camera hardware). So cannot reproduce it responsibly on the moment.

I will do this asap and comeback with report.

Downloaded OBS.

[Jason von Nieda]

Hi Mark,

As I suggested to Marek, I also suggest that you see if you can get it working in another piece of software. If you can, and it doesn't work in OpenPnP then we'll consider that a bug and try to fix it. If you can't, then as you mentioned, this may be a hardware / bandwidth issue that we can't do anything about.

The purpose of openpnp-capture is to expose the operating system's native camera capabilities, so my benchmark is basically: If the OS or another piece of software can do it, we should be able to, too.

Now, here is the reason I am so frustrated by this:

When you (and Marek, and others) make statements like "why one USB Root Hub can still only manage one camera even with MJPEG compression" this causes me a massive support issue. I understand, and accept, that this might be the case for your specific camera, but it is not universally true and it is patently false for the *recommended* cameras. When statements like this are made people see that, it sticks in their head and then they say things like "Since only one camera is supported per USB host I...", and then I have to have this whole discussion over again.

The truth is that if you use the cameras that are recommended on the OpenPnP site and Wiki, you *can* use two cameras on a single USB host using openpnp-capture where previously using opencv you could not. And in general, if you can get two or more cameras to show up using any other piece of software on your computer, then you should be able to get the same behavior in OpenPnP.

So, maybe this is an issue of improving the documentation. Perhaps we need to add a note that only certain cameras have been tested. It's hard to provide a general statement because there are thousands of different cameras with different capabilities.

So here is my ask: If you are going to repeat the statement that "it doesn't work" you would be doing me a great service if you include a caveat that it may be specific to your setup.

In the meantime, I am happy to spend some time on this to see where the problem actually lies and to fix it, if we can.

As I mentioned, I suspect Windows 7 to be an issue. Microsoft broke MJPEG on at least one occasion so I wouldn't be surprised if they broke it in Windows 7 and then decided not to fix it since that OS is no longer supported.

https://www.thurrott.com/windows/windows-10/76719/microsoft-broken-millions-webcams-windows-10-anniversary-update

I don't have a Windows 7 machine to test on, but I can at least try to prove the opposite. If you'll confirm that this looks like the camera you own I'll buy a set and see how they perform in Windows 10.

Is this it? https://www.amazon.com/ELP-Camera-Megapixel-Windows-Android/dp/B00KA7WSSU/ref=sr_1_1?ie=UTF8&qid=1543869491&sr=8-1&keywords=amazon+elp+2mp

And likewise, Marek, if you'll send me a link to the cameras you use I'll test them as well.

Thanks,

Jason

On Mon, Dec 3, 2018 at 11:57 AM Mark <ma...@makr.zone> wrote:

Thanks Jason

 

I moved this over here, including your answer below, fused to Mareks answer.

 

> I am honestly just so tired of reading this incorrect claim. I invite you to *test* it yourself. Hook up two ELP (or other well behaved) cameras and actually try it, as I did, repeatedly. As Neils did *while developing the library* you are quoting. It works correctly on all three operating systems. This was the entire reason we undertook the months long development effort and is the reason we released it when it was *tested* and finished.

 

Oh, believe me, I tried and tried again. And I reported the issue here.

https://github.com/openpnp/openpnp/issues/717#issuecomment-381389641

and here:

https://groups.google.com/d/msg/openpnp/fVv7PvArwiQ/-uqPOGoSCgAJ

and here:

https://github.com/openpnp/openpnp/issues/687#issuecomment-381394138

 

 

I just tried again with develop branch built 2018-11-20. Two ELP “6mm 2MP Full HD High Speed MJPEG USB” cameras on a new USB 2.0 external hub (tried various hubs including a USB 3.0 hub – to no avail).

 

Second Camera stays black. No error messages in Log or stderr:

 

The same hardware on a separate root hub:

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/!%26!AAAAAAAAAAAYAAAAAAAAAIksy9bq9upCo/PrMujuDwDCgAAAEAAAAM0II395t1NKiA1IaCuoRkUBAAAAAA%3D%3D%40makr.zone.

[bert shivaan]

Hi Jason, I am also happy to test things in win7. Its all I have on all computers I own and operate.

Having said that I am trying to figure out the "recommended" camera. It seems like I have read on the docs page I want a "ELP 720P" usb camera. If this is true it sure looks like that only narrows it down to a few dozens of choices.

I was personally fine with your answer to me about why my second camera didn't work, made perfect sense. I suppose some folks have luck and get 2 to work on the same hub?

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jx%3DLwWDbtHm3gyQ_uN0cbbFhGtyEK7UiVYs1r-EFhe6tQ%40mail.gmail.com.

[Mark]

Hi Jason

 

I am very sorry that these statements caused massive support issues! I will of course try hard to be more careful in the future.

 

> The easiest way to determine if this is a openpnp-capture issue is to see if you can get the correct behavior in another app. OBS (Open Broadcast Studio) is a good app for testing webcams

 

I can confirm I do have the same issue with OBS Studio. One cam OK, both cams not OK. The difference is that OBS won’t even let me activate one cam unless I unplug the other. OpenPNP will at least allow the first one to be activated even if the second one is plugged in.  Likewise OBS will run both cams if on separate hubs. Unfortunately OBS can’t configure the FPS either (or I don’t know how).

 

With VLC the same issues. FPS config does not seem to matter, connecting the second cam will always create an error. Again on separate hubs all is OK.

 

Like I said previously I don’t think this is an issue with OpenPNP at all. It’s just a “natural” limit of USB 2.0 with high speed hires cams. And after unsuccessfully trying with VLC I’m doubtful that the native FPS can be overridden at all.

 

> the cameras that are recommended on the OpenPnP site and Wiki

 

A good point. I must have missed that. Or maybe I thought a better model will surely also work J

 

 

> If you'll confirm that this looks like the camera you own I'll buy a set and see how they perform in Windows 10.

 Is this it? https://www.amazon.com/ELP-Camera-Megapixel-Windows-Android/dp/B00KA7WSSU/ref=sr_1_1?ie=UTF8&qid=1543869491&sr=8-1&keywords=amazon+elp+2mp

 

It looks slightly different, but it is also two years ago, when I ordered mine, maybe they’re just an older revision:

 

I suggest we do it the other way around. I will test with my cameras on Windows 10 as soon as I get my hands on one. If it works there, everything is clarified.

 

If it fails on Windows 10, I will order two of the recommended 720p ones. This way I might be able to confirm that it’s actually the HD vs. Full HD bandwidth step-up that prevents sharing the hub.

 

If all this is clarified we can help others by mentioning the caveats on the Wiki. And that’s all I truly wanted. Sorry again.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jx%3DLwWDbtHm3gyQ_uN0cbbFhGtyEK7UiVYs1r-EFhe6tQ%40mail.gmail.com.

[Marek T.]

Jason,

I use ELP cameras:

http://www.elpcctv.com/720p-usb-camera-module-usb20-omnivision-ov9712-color-sensor-support-yuy-and-mjpeg-with-36mm-lens-p-194.html

http://www.elpcctv.com/usb20-5mp-usb-camera-module-ov5640-color-cmos-sensor-36mm-lens-p-216.html (but set as 3Mpx)

Last one is used since died my previous camera on that I had an effect the same:

http://www.elpcctv.com/full-hd-usb-camera-module-1080p-usb20-ov2710-color-sensor-support-mjpeg-with-36mm-lens-p-203.html

Soon I will perform some tests with other software than OBS and tell what configuration works or not.

[Marek T.]

Sorry,  I had "other software than Openpnp" on my mind of course.

[Marius Liebenberg]

Hi Jason

I am using Linux and I have to run on separate hubs using two ELP's as well.

[Jason von Nieda]

Thanks Mark. Why don't you go ahead and try on Windows 10 if you can - but before you buy anything else I may be able to run some further tests with the cameras I own. I have my two 720P ones, and I think I have a 5MP and maybe a 2MP one. I'll try different combinations in Windows 10 and document the outcomes and we can go from there.

One question for you though, did you try this mode? "1024 (H) x 768 (V) pixels MJPEG 30fps"? This should be less bandwidth than my cameras, and I would surely expect it to work.

I think the goal of this will definitely be to update the Wiki with clearer recommendations and perhaps a process for figuring out compatibility. And of course, if we find some bugs, fix those too.

Jason

On Mon, Dec 3, 2018 at 4:37 PM Mark <ma...@makr.zone> wrote:

Hi Jason

 

I am very sorry that these statements caused massive support issues! I will of course try hard to be more careful in the future.

 

> The easiest way to determine if this is a openpnp-capture issue is to see if you can get the correct behavior in another app. OBS (Open Broadcast Studio) is a good app for testing webcams

 

I can confirm I do have the same issue with OBS Studio. One cam OK, both cams not OK. The difference is that OBS won’t even let me activate one cam unless I unplug the other. OpenPNP will at least allow the first one to be activated even if the second one is plugged in.  Likewise OBS will run both cams if on separate hubs. Unfortunately OBS can’t configure the FPS either (or I don’t know how).

 

With VLC the same issues. FPS config does not seem to matter, connecting the second cam will always create an error. Again on separate hubs all is OK.

 

Like I said previously I don’t think this is an issue with OpenPNP at all. It’s just a “natural” limit of USB 2.0 with high speed hires cams. And after unsuccessfully trying with VLC I’m doubtful that the native FPS can be overridden at all.

 

> the cameras that are recommended on the OpenPnP site and Wiki

 

A good point. I must have missed that. Or maybe I thought a better model will surely also work J

 

 

> If you'll confirm that this looks like the camera you own I'll buy a set and see how they perform in Windows 10.

 Is this it? https://www.amazon.com/ELP-Camera-Megapixel-Windows-Android/dp/B00KA7WSSU/ref=sr_1_1?ie=UTF8&qid=1543869491&sr=8-1&keywords=amazon+elp+2mp

 

It looks slightly different, but it is also two years ago, when I ordered mine, maybe they’re just an older revision:

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/04d301d48b58%24b7ee7cf0%2427cb76d0%24%40makr.zone.

[Marek T.]

I don't believe it is problem of the system.
Reading Marius I reminded that on my computers I have tried to use Debian9 with the same effect (lack of effect).
By now, I've never heard that anything works better on W10 than W7. Truly, I personally prefer to work with W7 and ten controllers instead of one W10 with one controller :-).
Finally, when I bring second camera home, do the tests on my W7 then do the same on my son's W10 strong laptop.
I rather would tell it is matter of cameras specific, maybe MB usb host specific not the system.

[Jason von Nieda]

Thanks Marek. I think I own both of those cameras, so I will try them out on Windows 10.

Jason

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/60a339ee-d04f-4180-bab2-11f196d7fb14%40googlegroups.com.

[Marek T.]

Hi Jason,

On the momment following conditions:

- 1920x1080, 30fps, MJPEG

- 640x480, 30fps, YUY2 (this camera doesn't provide MJPEG)

- both on the same controller

- two instances of VMCAP (AMCAP) working without problems. At occasion: total CPU load 5%.

Now Openpnp:

- only 640x480, 30fps, YUY2. CPU load 6-7%

Now Openpnp:

- 1920x1080, 30fps, MJPEG

- 640x480, 30fos, YUY2

CPU load 25%,

I don't have two MJPEG cameras to do better test.

Also this MJPEG is not ELP but some A4Tech HD camera.

But it works in the conditions.

What's interresting ant maybe here is some problem.

When I have added second camera to the system I had black screen like not-working camera.

It got it working when I have turned on and off auto-exposure!

Searching to do the same with two MJPEG.

[Jason von Nieda]

Hi Marek,

A few things:

1. I'm not concerned about CPU usage right now. I know what the problem is and how to fix it, so let's ignore that for now. I'm only interested in "2 cameras on one controller doesn't work".

2. Let's refer to your cameras by their sensor numbers - this will keep things clear. If I understand right, on your machine, you have an OV9712 and OV5640? And you also have an OV2710 but it is dead?

3. I'm confused as to which camera doesn't support MJPEG. If I look at the specs of all three you listed it seems they all support MJPEG? Please tell me (by sensor number) which one doesn't support MJPEG.

Now, from what I am reading about it sounds like both cameras work fine on one controller? Am I mistaken? If this is true, is the only problem you have that there is high CPU usage?

Thanks,

Jason

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f91c432e-f059-465b-a22a-e8925a577dd7%40googlegroups.com.

[Marek T.]

Ok.

1. CPU load I have written only "at occasion", I know it is not what we discuss here and now about.

2. Correct, it is on the system established in my company and working nonstop. I cannot experiment there until Friday.

3. This is my home computer and that two cameras I just have found to test anything. This a4tech camera I have used some time ago at working machine but replaced it with ELP because had bandwidth troubles with it (with ELP occured the same but I didn't revert to a4tech already).

Both computers and systems' versions are identical.

Sorry for confusing. Hope it's clear now.

[Jason von Nieda]

Thanks Marek - mostly clear but still one question: Do you still have a problem, either at home or at company, with "2 cameras don't work on one controller"? Or not? It sounds like you don't have this problem?

Sorry to repeat the question - just want to make sure there's no confusion on either side.

Thanks,

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/07284cf1-d239-45b9-a6bc-3b1c3fde086c%40googlegroups.com.

[Marek T.]

You are not mistaken - these two cameras works on one controller. But they are not both mjpeg but mjpeg+yuy2. And this yuy2 is only 320x640.

To tell it more responsible I must do the same on Friday (I hope) on working machine where have OV9712 and OV5640.

Note here I used 30fps to get the test "harder", normally it's not required for anything, normally I have 15fps (bottom) +10fps (top).

BTW: CPU load grows together with exposure.

W dniu wtorek, 4 grudnia 2018 17:04:39 UTC+1 użytkownik Jason von Nieda napisał:

[Jason von Nieda]

Hi Marius (and Bert),

Please let me know in as much detail as you can:

1. What cameras do you have? Models and URLs if you can.

2. What operating system and version?

3. Are you using "OpenPnpCaptureCamera" and not "OpenCvCamera"?

Thanks,

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c9472cd8-e2f1-4d7b-a17e-b2799b82c15d%40googlegroups.com.

[Marek T.]

Can't see any problem on my home computer, mjpeg+yuy2 (poor resolution) - both on one controller.

In company I have more "heavy" cameras and they work (worked???) only if connected to separated controllers.

[Jason von Nieda]

Thanks Marek, I think I am clear now. There may be some confusion about MJPEG + YUV2. This just means that the camera supports both. It only uses one at a time. The camera can either send MJPEG frames or YUV2 frames, but not both.

So, this is good! A camera that supports both is better than a camera that supports only one. But most importantly, we want cameras that *at least* support MJPEG. If they also support YUV2 that's fine, but we don't care.

Thanks,

Jason

[Marek T.]

I will check 2xMJPEG on Friday I hope then tell you.

Be sure I have tested it many times to the July when stopped with this connecting the cameras to the different controllers.

Is this possible that some update you made could improve anything about this issue? I don't know, newer opencv is somehow related to the issue?

[Jason von Nieda]

No, OpenCV is no longer related to the capture system, if you are using OpenPnpCaptureCamera. I wonder if it was just the auto-exposure problem you mentioned above?

I guess we'll see on Friday :) Thank you for taking the time to check into this!

Jason

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2929cbb4-8826-4da0-b1e3-24f0c816bcbd%40googlegroups.com.

[Marek T.]

This 640x320 is only yuy2, this HD is yuy2 or mjpeg.

I have no choice with this 640x320.

But I have tried this second one: mjpeg 1920x1080/30fps, yuy2 1920x1080/5fps, yuy2 640x480/30fps It works in every combinations (there is no available yuy2 1920x1080/30fps).

[Marek T.]

I have tested only OpenPnpCaptureCamera.

If you click onto VisionProvider in OpenPnpCaptureCamera there is "OpencvVisionProvider........".

No need to thank, it's my buissiness as well to have this working well.

Gratitudes are due only to you :-)

[Jason von Nieda]

Yep, the vision provider is sort of a remnant. I added it as an interface because I thought that some folks might want to use dedicated vision processors, but as OpenPnP grew it became clear that this would be impossible to make generic, so it has kinda fallen out of favor. I think the only thing that uses it anymore is the DragFeeder vision, so once that is converted to a pipeline the vision provider will be removed entirely.

In any case, vision provider is unrelated to capture. It's just a generic property of every camera type.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2544ad7e-0b5a-4c21-bd91-d1419ae61d95%40googlegroups.com.

[bert shivaan]

Right now I am waiting for a new camera. When it gets in I will resume testing.

It is possible I didn't actually have a problem when I started the thread about the blank second camera. You guys pointed me to the wiki about using multiple channels. I switch stuff around and both were working in WIN7. then a few hours later I noticed only the orginal was working, so I figured I likely didn't actually have 2 seperate channels and had gotten lucky.

Some time passed and yesterday I added a PCIE USB card for a second channel. At first I thought the card was not working right as I still had blank screen (even though the puter saw the camera). Then finally I plugged in my other camera and it worked fine. SO.....

The blank screen camera is in the trash while I wait for the new camera.

Here is a link for the camera I have right now

https://www.amazon.com/Plugable-Microscope-Flexible-Observation-Magnification/dp/B00XNYXQHE/ref=sr_1_1?ie=UTF8&qid=1543943196&sr=8-1&keywords=plugable+technologies

I bought it a few years ago, so hard to tell if it is truely the same one. So far it seems to work good as my down looking camera. Maybe I will have issues with the built in light, still to be seen.

-Bert

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jxBh3O4UqAF_HQSOqOSK7iZXuDCPsG9bZVfhfqShQtbVQ%40mail.gmail.com.

[Marek T.]

Clear now!

"Exposure" couldn't be a reason of troubles a half year ago we've seen.

But the fact is that everytime I reconnect this camera from USB (but still on the same port) and run Openpnp, the screen is black until check on an auto-exposure. Then get the vision and can set auto-exposure off - in the moment there is no change on the image brightness, it remains "normal".

Doing the same on vmcap, the vision is also black but not absolutely total - the most bright objects are visible. When I check a-e image gets normal brightness and when check it off the brightness drops down a little (brightness does not mean slider value of course). Maybe it's only this camera specific but Mark could to check it on his setup.

[Marek T.]

Is this something important??

[DBG ] FOURCC = RGB

2018-12-04 18:21:29.742 CameraView DEBUG: Failed to load camera specific reticle
, checking default.
2018-12-04 18:21:29.743 CameraView DEBUG: No reticle preference found.
[DBG ] FOURCC = RGB
2018-12-04 18:21:29.897 CameraView DEBUG: Failed to load camera specific reticle
, checking default.
2018-12-04 18:21:29.898 CameraView DEBUG: No reticle preference found.

[Jason von Nieda]

Hi Marek,

Which camera specifically are you referring to with the exposure issue? If you can use sensor numbers or something in this discussion it will help me keep things clear. I am making a list of cameras and the problems or successes people have with them and this will eventually be used to update the Wiki.

Alternately, you can use the model number of the camera. For instance, on the ELP the model number is shown on the board. Like this one: http://www.elpcctv.com/720p-usb-camera-module-usb20-omnivision-ov9712-color-sensor-support-yuy-and-mjpeg-with-36mm-lens-p-194.html in the picture and in the item description you see the model number USB100W03M.

Thanks,

Jason

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0325bce0-0bc2-4f42-bf95-c8ae3487cec9%40googlegroups.com.

[Jason von Nieda]

The FOURCC message may indicate that that camera supports uncompressed RGB, and I don't think we support that mode in the library. We wouldn't want to use it anyway, it would be very high bandwidth.

The reticle messages are not important.  Just means no reticle preference has been set for that view, so it uses the default.

Jason

[Marek T.]

It's this one but I have replaced a lens with M12.

https://www.a4tech.com/product.aspx?id=37

I have no idea how to find sensor type info.

USB\VID_0AC8&PID_3500&REV_1007 USB\VID_0AC8&PID_3500

[Jason von Nieda]

Thanks, that's good enough for now. Can you send me a screenshot of the formats dropdown in OpenPnP for this camera? I want to see the resolutions, compression and frame rates available.

Thanks,

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/38126d69-59f6-4942-9cc2-1672266619f4%40googlegroups.com.

[Marek T.]

Your welcome.

[Jason von Nieda]

Marek and Mark,

Two things:

1. I updated the camera wiki and the build wiki to include more information, to hopefully steer people towards the cameras that are known to work:

https://github.com/openpnp/openpnp/wiki/OpenPnpCaptureCamera#troubleshooting

https://github.com/openpnp/openpnp/wiki/Build-FAQ#what-should-i-build

2. I just realized that you both had the same ELP-USBFHD01M camera at one point. Marek, you used to use it, but you said it died and you switched to ELP-USB500W02M, and Mark, you have two of these if I understand correctly.

I suspect that this is the camera is that is causing the trouble. I see that the 1280x720 resolution is 60 FPS, but there are lower resolution / FPS combos, so I wonder if one of these would do the trick? I would think 1024x768-MJPEG@30fps should be less bandwidth than the 1280x720-MJPEG@30FPS that I use.

Marek, I would guess that on Friday if you pick resolutions of 1280x720-MJPEG@30 FPS or lower it will work fine.

Mark, could you try with both cameras set to 1024x768-MJPEG@30fps?

Thanks,

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7274f1c9-a045-4de8-a182-867005d5fbd0%40googlegroups.com.

[Marek T.]

I don't remember cameras names.
Originally I had two ELP 720p and 1080p. 1080p died and replaced with 5M set as 1600x1200 but tested earlier for bandwidth at 1280/720 too.
30fps I use only at home to get heavier test conditions.

Mark has two 1080p I guess.

[Marius Liebenberg]

Hi Jason

1: These are the cameras : https://robotdigg.com/product/1140/OpenPnP-USB-Interface-1.0MP-720P-Vision-Camera

2: Debian 9.2 Stretch.

3: OpenPnpCaptureCamera

I can confirm that I cannot get two cameras to work on the same hub at all. Just deleted the lot and tried to install them on the same hub. Only one is seen always.

[Marius Liebenberg]

Jason
Here is the result.

[Mark]

Hi Jason

 

> I suspect that this is the camera is that is causing the trouble. I see that the 1280x720 resolution is 60 FPS, but there are lower resolution / FPS combos, so I wonder if one of these would do the trick? I would think 1024x768-MJPEG@30fps should be less bandwidth than the 1280x720-MJPEG@30FPS that I use.

 

Tested two of my ELP-USBFHD01M with 1024x768-MJPEG@30fps as you suggested. Does not help (believe me, I tried all possible settings back when I setup the machine J). Also tried fiddling with exposure, as Marek hinted, again unsuccessfully. Same for restarting OpenPNP. Tried two different USB hubs.

 

The first cam will work, the second not (black screen, no error). I can get both running individually depending on order of config.

 

I also tried to find a way to measure/compare consumed USB bandwidth. Windows actually has a properties dialog in the Device Manager showing bandwidth usage on USB 2.0 host controllers. I had to go to my old computer, because unfortunately this tab is not available on the USB 3.0 controllers I have in the newer computer.

 

ELP-USBFHD01M with 1024x768-MJPEG@30fps:

 

 

HBV-1517 S1.0 (that’s the newer cam Juha sells with the Liteplacer) at 1280x1024, 7FPS, YUV2:

 

 

Tried other, lower resolutions, they all take 48%, as the FPS is increased to fill up the bandwidth.

 

Also tried the built-in webcam 1280x720@30fps MJPG:

While this is not the ELP model this is a good indicator, that in deed the 30 vs. 60 fps do matter.

 

In conclusion the following facts seem interesting:

1.       It is well established that two YUV2 webcams won’t work on one root hub.

2.       HBV-1517 S1.0  at 1280x1024, 7FPS, YUV2 is reported at 48%.

3.       2 x 48% < 100% so why does it not work?

4.       Guesswork: USB 2.0 is half-duplex (USB 3.0 is full-duplex), so the system might only allocate 50% of the bandwidth for the up-stream. Maybe there is dynamic allocation of the up- vs. down-stream but 2 x 48% is just too close to 100% to be stable, also considering that the reported 48% may be an average over some time. Strangely I found no info on the web.

5.       Seeing that even the smallest ELP-USBFHD01M 1024x768-MJPEG@30fps format results in the same 48% bandwidth use as the YUV2 cam, this explains for me, that likewise one USB root hub will not fit two of those cameras.

6.       The reported 26% use with the built-in webcam 1280x720@30fps MJPG format might be seen as a confirmation for the opposite case. Seeing that the properties dialog reports 1% base load even for unconnected devices and allowing for some rounding errors it does make sense that 2 x 26% - baseload - rounding errors could roughly fit into the 50% half duplex upstream budget.

 

I also checked a Logitech C310 and confirmed that formats are either at 48% bandwidth or at 26% bandwidth for the very low resolution formats:

 

This makes perfect sense to me: a camera will either use ~47% i.e. practically the full upstream bandwidth or ~25% i.e half the upstream bandwidth, allowing one or two cams on one hub.  

 

Jason has already updated the Wiki to suggest to people to buy the recommended 720p models. Perhaps the the Wiki could be more specific, explaining that for two hires cameras to work on the same hub they must be MJPG. However the inverted contraposition (more precisely: “falscher Umkerschluss” in German) is not necessarily true: a hires camera being MJPG does not yet guarantee that you can run two on the same hub. An MJPG camera can still be too fast/too hires!

 

I will still try to get my hands on a Windows 10 system. Perhaps there is still a difference.

 

_Mark

 

P. S. Soon this will all go away with true USB 3 cameras.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jxAdGa%2B%2BQttpHuaV4%2Bhm2sA1fWBc3LM5KJ3%3DvoF5TPa6A%40mail.gmail.com.

[Marek T.]

My two cameras 320x640 YUY2 and 1920x1080 MJPG, both 30fps, shows 47% and 48% on one host.

It is named as "standard extended host controller PCI to USB". It is not any additional PCI card but controller built-into my MB.

BTW: When experimented with USB 3.0 port to use USB2.0 cameras an effect was much worse than using USB2.0 host controller.

[Marek T.]

Look this is 47+48+20, so together it is 115% together and works...

[Jason von Nieda]

Hi Mark,

You might try this tool: https://www.uwe-sieber.de/usbtreeview_e.html

I think this is what Marek used to generate his report yesterday. It seems to show each format along with the minimum bandwidth. Might be interesting to compare. I'm going to try it tonight for all my cameras.

Jason

On Wed, Dec 5, 2018 at 8:28 AM Mark <ma...@makr.zone> wrote:

Hi Jason

 

> I suspect that this is the camera is that is causing the trouble. I see that the 1280x720 resolution is 60 FPS, but there are lower resolution / FPS combos, so I wonder if one of these would do the trick? I would think 1024x768-MJPEG@30fps should be less bandwidth than the 1280x720-MJPEG@30FPS that I use.

 

Tested two of my ELP-USBFHD01M with 1024x768-MJPEG@30fps as you suggested. Does not help (believe me, I tried all possible settings back when I setup the machine J). Also tried fiddling with exposure, as Marek hinted, again unsuccessfully. Same for restarting OpenPNP. Tried two different USB hubs.

 

The first cam will work, the second not (black screen, no error). I can get both running individually depending on order of config.

 

I also tried to find a way to measure/compare consumed USB bandwidth. Windows actually has a properties dialog in the Device Manager showing bandwidth usage on USB 2.0 host controllers. I had to go to my old computer, because unfortunately this tab is not available on the USB 3.0 controllers I have in the newer computer.

 

ELP-USBFHD01M with 1024x768-MJPEG@30fps:

 

 

HBV-1517 S1.0 (that’s the newer cam Juha sells with the Liteplacer) at 1280x1024, 7FPS, YUV2:

 

 

Tried other, lower resolutions, they all take 48%, as the FPS is increased to fill up the bandwidth.

 

Also tried the built-in webcam 1280x720@30fps MJPG:

While this is not the ELP model this is a good indicator, that in deed the 30 vs. 60 fps do matter.

 

In conclusion the following facts seem interesting:

1.       It is well established that two YUV2 webcams won’t work on one root hub.

2.       HBV-1517 S1.0  at 1280x1024, 7FPS, YUV2 is reported at 48%.

3.       2 x 48% < 100% so why does it not work?

4.       Guesswork: USB 2.0 is half-duplex (USB 3.0 is full-duplex), so the system might only allocate 50% of the bandwidth for the up-stream. Maybe there is dynamic allocation of the up- vs. down-stream but 2 x 48% is just too close to 100% to be stable, also considering that the reported 48% may be an average over some time. Strangely I found no info on the web.

5.       Seeing that even the smallest ELP-USBFHD01M 1024x768-MJPEG@30fps format results in the same 48% bandwidth use as the YUV2 cam, this explains for me, that likewise one USB root hub will not fit two of those cameras.

6.       The reported 26% use with the built-in webcam 1280x720@30fps MJPG format might be seen as a confirmation for the opposite case. Seeing that the properties dialog reports 1% base load even for unconnected devices and allowing for some rounding errors it does make sense that 2 x 26% - baseload - rounding errors could roughly fit into the 50% half duplex upstream budget.

 

I also checked a Logitech C310 and confirmed that formats are either at 48% bandwidth or at 26% bandwidth for the very low resolution formats:

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/003d01d48ca6%24d74462f0%2485cd28d0%24%40makr.zone.

[Marek T.]

Yes it was made with usbtreview.

[Mark]

Hi Jason

 

> You might try this tool: https://www.uwe-sieber.de/usbtreeview_e.html

 

Nice tool. Attached the ELP-USBFHD01M usbtreeview report.

 

However: it does not make much sense, clearly USB 2.0 does not support 995’469’360 bps (or 124.4Mbyte/s) as a minimum:

 

        ----- Video Streaming MJPEG Frame Type Descriptor -----

---> This is the Default (optimum) Frame index

bLength                  : 0x1E (30 bytes)

bDescriptorType          : 0x24 (Video Streaming Interface)

bDescriptorSubtype       : 0x07 (MJPEG Frame Type)

bFrameIndex              : 0x01

bmCapabilities           : 0x00

wWidth                   : 0x0780 (1920)

wHeight                  : 0x0438 (1080)

dwMinBitRate             : 0x3B55A830 (995469360 bps -> 124.4 MB/s)

dwMaxBitRate             : 0x3B55A830 (995469360 bps -> 124.4 MB/s)

dwMaxVideoFrameBufferSize: 0x003F4A4D (4147789 bytes)

dwDefaultFrameInterval   : 0x00051615 (33.3333 ms -> 30.000 fps)

bFrameIntervalType       : 0x01 (1 discrete frame interval supported)

adwFrameInterval[1]      : 0x00051615 (33.3333 ms -> 30.000 fps)

 

 

I think the bandwidth that is actually detected by Windows is more reliable.

 

I also made a measurement of the ELP-USBFHD01M  1024x768-MJPEG@30fps stream by using a USB sniffer, summing up the payloads over one second from the captured timestamped log. The net sum is  26'170'704 byte or roughly 44% of the USB 2.0 60’000’000 byte per second gross bandwidth. Allowing for some overhead this corresponds nicely to the reported 48%. And this is the actual data stream, not much room for interpretation.  

 

_Mark

 

 

Von: ope...@googlegroups.com [mailto:ope...@googlegroups.com] Im Auftrag von Jason von Nieda
Gesendet: Mittwoch, 5. Dezember 2018 16:12
An: ope...@googlegroups.com
Betreff: Re: [OpenPnP] Re: openpnp-capture multiple cameras

 

Hi Mark,

[Jason von Nieda]

Hi Marius,

I'm not exactly clear on what I'm seeing here. I see two USB 2.0 Camera but on different USB Host Controllers? Can you give a bit more detail on what you have hooked up, and how? And when you say "Only one is seen", do you mean that Linux doesn't even enumerate the second one, or just that it fails in OpenPnP?

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9cd161f6-2440-4b6b-8fb9-0d2035f177e0%40googlegroups.com.

[SMdude]

Hi Jason,

I remember when I was setting up my cameras I had trouble as well.

I think I was able to get both cameras up in an external program, but every time I tried in openpnp I could only get one cam.

However, when I had openpnp running, I also had smoothie connected into the same usb host as well, which would then overload the usb bandwidth.

This is with win 7. I will try this machine again, but I will only be able to get 2 cameras onto one hub anyway as I rerouted the webcam usb(different host controller) to my other available port, exposing the other usb hostcontroller. I can see if I can find a usb hub and test all 3 on the one hub. I think it is a windows driver/camera problem, not an openpnp problem. The usb bandwidth is determined by the usb drivers?

Once I figured out what was going on I did what I did to fix it and never looked at it again to see if I could get it all working on the one root hub.

I tried all combinations of usb ports on my current pnp laptop(2 hosts 4 usb ports) and couldn't get it to overload the usb ports(this is win 10) And that is still using openCv for vision.

I have to say, so far I have been pretty happy with the win 10 installation. The system seems very fast and responsive(i7 8 gig ram), however, all it gets used for is pnp machine, no internet etc. (I didn't run this machine on win7)

Mick

[Marius Liebenberg]

Hi Jason

UsbView shows the two cameras are installed on separate hubs or host controllers (not sure what is correct)

OpenPnp will show both devices on the dropdown list but only one camera will show content. This is only true if they are both on the same controller or hub.

If the cameras are on separate controllers then OpenPnp will show content on both.

Both cameras are enumerated at all times by the looks of things.

[Jason von Nieda]

Hi Marius,

A few questions:

1. Can you confirm the camera has the model number USB100W03M written on the silk screen?

2. Can you please plug both cameras into a hub or the same USB host, and send the same screenshot as above? I'd expect to see both cameras under the same branch of the tree.

3. With both cameras plugged in, please see if you can select the format 1280x720, 30 FPS, MJPEG for each in OpenPnP. After setting each, and saving the changes, restart OpenPnP and see what happens. Make sure to check the exposure setting and maybe set it to auto.

4. Finally, try OBS ( https://obsproject.com/ ) and see if you can get both cameras to show up when attached to the same USB host. If so, please note the settings you set for each.

Thanks,

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b69064a1-5efd-414b-b43f-cd9f3bf86d44%40googlegroups.com.

[Marius Liebenberg]

Hi Jason
No problem. Results are:

1: Yes the model number is exactly that. USB100W03M
2: Screentshot included above.
3: I can select the format 1280x720, 30 FPS, MJPEG for each. No change. The second camera has no content.
4: OBS does not see both cameras if they are on the same hub.

[Michael G.]

I was always thinking, I can't have two cameras at one port, but now I have tried and can confirm that

2 cameras (https://www.aliexpress.com/item/2mp-2-0-megapixel-1920-x-1080-cctv-camera-board/32263338732.html)

run with openpnp in

MJPG 30fps 1920x1080 mode

on

win 7 64 bit

on one usb 3.0 port

connected via this hub https://www.amazon.de/gp/product/B0773V3LRV/

as soon as I connect a third device (arduino here), only one camera continues to deliver images... (I don't know if it might be because of too much power drawn or its the usb bandwidth)

[Mark]

Thanks, will immediately order and then try this hub.

 

I always thought that the hub being 3.0 does not matter, as it is just marshaling not repackaging data, simply switching the limited USB 2.0 stream/bandwidth through. My USB 3.0 hub (ICY BOX IB-AC6702) does not work.

 

Strange.

 

_Mark

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ac26fa3f-b205-4d6f-832f-a2be92b85cc8%40googlegroups.com.

[Michael G.]

Hehe, good luck with that, no refunds ;)

I think I tried an cheap 2.0 hub one day and it didn't work, so I was surprised by that its working, too...

[Mike Menci]

HI, 

I was testing this USB 3.0 (wanted 3rd camera) but it did not work, I ended up moths ago with USB 2.0 and its working perfectly for months now.

 

Only 1USB cable leading from Open PnP to my Win10 computer now for months.... 

USE USB 2.0 !!

Mike

[Robo]

i was facing same issue, so i found some temporary solution for that.

First I disabled all the unwanted devices from device manager.

Connected all camera and MKS 1.3 to laptop and restarted my laptop.

than started software without connecting any extra devices to laptop. and now both the camera working fine.

[Marek T.]

Hi Jason,

I have tested today working openPNP with mentioned 1Mpx(720p) and 5Mpx, both from ELP. Connected to the same controller they work well. CPU load seems be little higher than if the cameras connected separately but not much.

I have also installed python and soft to measure lattency/lagginess of the cameras. I guess you know this.
I have found this 5Mpx camera is very slow and has very long response time reaching 200ms at 4-5fps if resolution is like 1600x1200. Much faster if 640x480 (40ms and 30fps) but no reason to use the camera like that in this mode. So it's not the camera that should be used for fast vision automated system like we do.

The same about this 1080p A4Tech camera. The same lagginess and slow. Not recommended for those whom the vision speed is important parameter.

Issue with auto-exposure occurring at A4Tech is also existing in ELP 5Mpx.

[Jason von Nieda]

Hi Marek,

That's great news! I'm glad to hear it's working. So that may rule out the Windows 7 issue, and it seems more likely that the issue is specific to the USBFHD01M camera that you have (broken) and Mark has two of.

One thing I have noticed on some cameras is that when the exposure is set high (due to low light) the frame rate drops significantly. Perhaps that could be part of the problem with the 5Mpx camera?

I gathered up all my cameras this weekend and will be running a number of tests tonight and tomorrow night. One thing I found is that I have two USB100W05MT on my machine, not USB100W03M. I'm not sure what the difference is. It may just be a newer version. They have the same sensor and same frame formats.

The cameras I will test are:

* (2) USB100W05MT

* (1) USB500W02M

* (1) USB500W04AF

Thanks,

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/df5eae6d-bf52-4ffa-bf6b-7d650624304a%40googlegroups.com.

[Marek T.]

Summary:

ELP-USB100W03M - quite fast 720p camera, very good for fiducials

ELP-USBFHD01M - quite fast 1080p camera, very good for bottom vision. It's the one that I have broken. 

ELP-USB500W02M - very slow 5Mpx camera with high lagginess and low fps, requires long settle time

(see this test including the tool to test it, got it from CriS tonight: https://makehardware.com/2016/03/29/finding-a-low-latency-webcam/)

A4TECH - slow 1080p camera with high lagginess and poorc fps. Not so bad like this 5Mpx at the same resolution - but still hard to recommend it.

I have checked it with different exposures. It is somehow related as you said I saw the same. But generally this 5Mpx is not good at any settings except 640x480.

[Marek T.]

As I see on their website:

W05MT version has some mysterious Audio Input (maybe to connect some microphone and transfer audio over USB) and IR-cut filter.

W03M still offered with non-filtered sensor (or lens).

W dniu poniedziałek, 10 grudnia 2018 16:17:54 UTC+1 użytkownik Jason von Nieda napisał:

One thing I found is that I have two USB100W05MT on my machine, not USB100W03M. I'm not sure what the difference is. It may just be a newer version. They have the same sensor and same frame formats.

(...)

Jason

[Marek T.]

Hi Jason,

When you will make some test, may I ask you to do and send to me your usbtreeview report file for the port connected to the camera ELP-USBFHD01M (the one I have strange broken)?

I see many errors in its tree and would like to compare this with normally working camera this type.

Thx in adv :-).

Pls also see this good description. Nicely shown the relation between fps and exposure.

https://joancharmant.com/blog/review-of-the-elp-usbfhd01m-camera/

brgds

Marek

W dniu poniedziałek, 10 grudnia 2018 16:17:54 UTC+1 użytkownik Jason von Nieda napisał:

[Jason von Nieda]

Hi Marek,

I finally got a few minutes tonight to grab some info. Unfortunately I don't have the USBFHD01M; I think Mark does. The three models I have are:

1. USB100W05MT (2x)

2. USB500W02M

3. USB500W04AF

The reports for each are attached. I haven't looked too closely yet, but one thing of interest is that all three cameras support the same 1280x720, MJPEG, 30 FPS mode.

Thanks,

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5064c0fe-b2ba-4a3f-b82a-e443f87c3927%40googlegroups.com.

[Marek T.]

@Jason,

Hi Jason,

Thanks for the files! Other cameras than my broken but can't see the errors I have.

This 1280x720/30fps of 5Mpx camera is rather some unreal science fiction, just text in camera config memory not real parameter.

Try this python test in some free time and you will see. Or you have other working firmware than put into my one.

@Mark

Hi Mark

Do you have excatly this USBFHD01M camera maybe?

Could you pls send me port usbtreeview report for it?

[Mark]

> @Mark
> Hi Mark
> Do you have excatly this USBFHD01M camera maybe?
> Could you pls send me port usbtreeview report for it?

Yes, I already reported that and some comments here:
https://groups.google.com/d/msg/openpnp/k7M-Z-P1ivg/ziau5He1DQAJ

_Mark

[Marek T.]

Ah, right, thank you :-)

[Jason von Nieda]

Hi Marek,

Here are the timing tests. I didn't use the same code, but same idea. I just used the Windows Camera and Timer apps.

So, looks like the "recommended" camera has about 2 frames of latency at 30 FPS - about 70ms.

Of interest, the 5MP ones were not much worse. About 100ms.

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4babc135-8777-45a2-a25f-868a833a7c04%40googlegroups.com.

[Marek T.]

@Jason,

Hi Jason,

This is strange. Maybe these 5Mpx cameras are sold with different firmwares that differs about the speed? I have some contact to Eva from ELP so will try to ask her.

I'm not sure how works the python script. But when it is just connected to the camera it shows some fps and times in the console window, running in the rows. It's without pointing camera to the display monitor.

Since you point camera to the monitor the times and fps are getting much shorter/faster in the console.

But it doesn't change too much if you compare this way two cameras and looking on the difference only.

@Mark,

Hi Mark,

Could you pls check again your port report and confirm me whether you really have only two String Descriptors 0 and 1 in the last section "String Descriptors".

I have there 9 of them (0-8) and errors visible in descriptors 6-7-8.

Take your time.

             ------ String Descriptor 8 ------
bLength                  : 0x04 (4 bytes)
bDescriptorType          : 0x03 (String Descriptor)
Language 0x0409          : "°"  *!*ERROR  contains 1 NULL character
Data (HexDump)           : 04 03 00 00

[Jason von Nieda]

Hi Marek,

I think they are just different cameras entirely.

The camera you have is USBFHD01M which has these specs:

- Sensor: OV2710
- Formats:
  - 320X240  QVGA  MJPEG @120fps/  352X288 CIF  MJPEG @120fps
640X480  VGA  MJPEG@120fps/   800X600 SVGA  MJPEG@60fps
1024X768  XGA  MJPEG@30fps/  1280X720  HD   MJPEG@60fps
1280X1024  SXGA MJPEG@30fps/  1920X1080 FHD  MJPEG@30fps

The camera(s) I have and tested are USB500W02M and USB500W04AF, what has these specs:

- Sensor: OV5640
- Formats:
  - 2592x1944@ 15fps MJPEG / 2048x1536@ 15fps MJPEG
1600x1200@ 15fps MJPEG / 1920x1080@ 15fps MJPEG
1280x1024@15fps MJPEG/ 1280x720@ 30fps MJPEG
1024 x 768@ 30fps MJPEG/ 800 x 600@ 30fps MJPEG
640x480@ 30fps MJPEG /  320x240@ 30fps MJPEG

Of note, my camera uses the OV5640 sensor, which is a very good sensor. It was used in the iPhone 4, if I remember correctly.

So, surely they have different firmware, but they also have completely different sensors and are probably not very similar at all.

Also, the link you sent before ( https://makehardware.com/2016/03/29/finding-a-low-latency-webcam/ ) tells you to point the camera at the screen the same way I did. Are you talking about a different one?

Thanks,

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/72ca9815-7846-4d3a-b781-849258d4fb5f%40googlegroups.com.

[Marek T.]

Jason,

I'm telling about two different cameras with you and Mark (assume he's got the same like me), sorry for confusing.

The one where I have errors (broken that I try to fix and compare with Mark's one) is ELP-USBFHD01M.

The slow one which I have working with long settle time requirement is USB500W02M with OV5640!

It's the same like you have. And here I consider wheter they may have different firmwares.

I think the sensor may be very fast but the firmware loaded into the board processor may do bad job.

Yes, I mean the linked software but I'm telling about the information displayed in the python console window not on the camera view screen.

Their speed (in console) depends on the camera is looking onto the monitor or not.

[Jason von Nieda]

Ah, I see! I misunderstood which camera we were talking about. That's very odd!

I will try to use the Python code and see how the results are. It will probably be next week as I'm on holiday the next few days.

Thanks,

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e15b0bd2-fa4e-458e-a68a-e489a857c59c%40googlegroups.com.

[Marek T.]

:-).

Take your time, enjoy the holidays... Maybe in the meantime I will get some answer from Eva.

I'm also surprised how is possible that some camera (this A4TECH) set as 1280/720 and 30fps may allow me to make a move of the hand over the sensor and on the screen there is only small momentary brightness lowering.

I can't see any hand there on the screen at all, while I don't think I can do this in time shorter than 30ms.

It is using VMCAP software not Openpnp.

This OV5640 camera we discuss is a bit faster but not much. It is still not looking to me like set 30fps.

[bert shivaan]

Now just hold on a bit!!!

Jason you should know there is no holiday for you. We have not seen the request in the group for the main volenteer to go away. Who will teach me Java? Who will help with all the other things we need you for?

of course I am just kidding :)

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/74e3122a-5e0c-4d09-b5b5-8cd146fa17f2%40googlegroups.com.

[Jason von Nieda]

Sorry Bert, you'll just have to get on for a couple days :) Although... I'll still be answering emails and probably even doing some programming :)

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNyXrHJVGjDtFJTi8XrHpNyqhgSq0QVvcDgMu3tGCQ8TTw%40mail.gmail.com.

[bert shivaan]

I won't hi-jack this thread past this post, but I prolly do need a break actually. Went to bed around 11 last night after fighting with trying to get JFileCHooser to maintain last used directory - and failed. Woke back up at 3 and played with it for another hour and a half. Still failed.

I think I will go back to fileDialog, I really enjoy the filter but can't stand clicking through directorys every time.

Have fun on vacation :)

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jz%3DpFmkrvLRFz5PbMYt1LqQD%3Do6CiwaoiEiY%2B79Kyhmhw%40mail.gmail.com.

[ma...@makr.zone]

I got the hub but (as I originally expected) it does not help. Two USBFHD01M won't work.

The hub appears as a "USB2.0-MTT-Hub" (whatever MTT stands for) with the cameras sharing it.

Only true 3.0 devices such as the mass storage device (also shown below), appear under a separate 3.0 hub. I guess Windows handles them like "superimposed" hubs.

Michael G.'s cameras are obviously different. I bet they would work under a normal USB 2.0 Hub too.

_Mark

On Friday, December 7, 2018 at 12:00:25 PM UTC+1, ma...@makr.zone wrote:

Thanks, will immediately order and then try this hub.

 

I always thought that the hub being 3.0 does not matter, as it is just marshaling not repackaging data, simply switching the limited USB 2.0 stream/bandwidth through. My USB 3.0 hub (ICY BOX IB-AC6702) does not work.

 

Strange.

 

_Mark

 

Micheal G.> I was always thinking, I can't have two cameras at one port, but now I have tried and can confirm that

[Marek T.]

Have you seen this Mark?

Not urgent...

https://groups.google.com/d/msg/openpnp/k7M-Z-P1ivg/eV1zqcf9DwAJ

[Marius Liebenberg]

Thats not much of a holiday if you are still working. Forget about us for a couple of days and just have a holiday. We will still be here when you return :)

[ma...@makr.zone]

@Mark,

Hi Mark,

Could you pls check again your port report and confirm me whether you really have only two String Descriptors 0 and 1 in the last section "String Descriptors".

I have there 9 of them (0-8) and errors visible in descriptors 6-7-8.

Take your time.

             ------ String Descriptor 8 ------
bLength                  : 0x04 (4 bytes)
bDescriptorType          : 0x03 (String Descriptor)
Language 0x0409          : "°"  *!*ERROR  contains 1 NULL character
Data (HexDump)           : 04 03 00 00

@Marek T., sorry I've overlooked that question.

It reports errors too, not sure what these mean or what you are looking for...

I posted my ELP-USBFHD01M usbtreeview report here a while ago:

https://groups.google.com/d/msg/openpnp/k7M-Z-P1ivg/ziau5He1DQAJ

_Mark

[Marek T.]

Yes I saw it but there are no errors in "String Descriptors" section of your file. I also don't know is it important or not at all.

My camera rapidly stopped working while some settings changing. USB works but returns some strange values and these errors in the tree, and no vision.

It looks like some configuration settings destroyed. I'm trying to find what it could be and to fix it, maybe reprogram eeprom externally if find the source. Just as hobby play:-)

[Mark]

> Yes I saw it but there are no errors in "String Descriptors" section of your file.

 

There is another one:

 

bInterfaceCount          : 0x01

*!*ERROR  bInterfaceCount must be greater than 1

 

 

Are your errors reproducible, each time the same errors? Have you checked cabling? These ELP cables are very thin at the PCB end and not strain relieved, the connectors tiny. Easy to break these and get what in German is aptly called a “Wackelkontakt”  (~“wiggle contact” = intermittent contact).

 

_Mark

 

[Marek T.]

My errors are always in the same parts of the readings.

One error the in "Device Qualifier Descriptor" and three in String Descriptors (which all together I have 9 while you have two).

Attached.

Wiring is ok. It was already exchanged with another camera cable to check  it :-)

[Marek T.]

Hi Jason,

I have contacted to Eva of ELP.

She said there is an only one firmware for USB500W02M camera. Nothing was improved about the speed or latency.

So probably we have the same working cameras but other measurement conditions.

She pointed the volume of the lightening. The same that we found, as darker environment and more exposure required as lower speed of the camera.

Definitely at the same 1920x1080 resolution the USBFHD01M is twice faster than USB500W02M (30 instead of 15fps).

It's about fps only. I'm still trying to get info about the difference in latencies for an images.

brgds

Marek

[Jason von Nieda]

Thanks Marek, this is good to know. Lighting definitely plays a part as I've noticed this while setting up pipelines.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/203b79eb-f293-47cf-a313-ab4e460ad295%40googlegroups.com.

[Mark]

Hi

 

> Jason wrote:

> As I mentioned, I suspect Windows 7 to be an issue. Microsoft broke MJPEG on at least one occasion so I wouldn't be surprised if they broke it in Windows 7 and then decided not to fix it since that OS is no longer supported.

 

To exclude the Windows Version as one possible reason, I just tried on a Windows 10 box:

·         2 x USB ELP-USBFHD01M.

·         On the same, brand new USB 3.0 hub.

·         Latest OpenPNP x64 download (of today), fresh and virgin install.

·         Default setup, added the two cameras with FullHD 30fps, deleted the virtual cameras.

·         Tried several thing, like restarting OpenPNP etc.

 

The same result as with Windows 7.

 

Just one camera at a time works.

 

Like I said that’s fine with me. It just confirms that MJPEG alone is not a silver bullet in terms of bandwidth limits on USB 2.0

 

People should either buy the 720p and NOT the 1080p ELP camera as recommended by the OpenPNP Wiki …

 

… or live with two USB connections to the computer and benefit from better resolution and/or fps à shorter settle times.

 

_Mark

[Marek T.]

Openpnp/java should work with two high speed high resolution cameras on one usb as Windows can...

[Mark]

Multiple other programs suffer from the same problem with these cameras. See my reports in this thread.

Maybe it is still a camera model specific problem. But I no longer consider it a Windows 7 specific problem.

_Mark

-----Ursprüngliche Nachricht-----
Von: ope...@googlegroups.com [mailto:ope...@googlegroups.com] Im Auftrag von Marek T.
Gesendet: Dienstag, 8. Januar 2019 10:57
An: OpenPnP
Betreff: AW: [OpenPnP] openpnp-capture multiple cameras

Openpnp/java should work with two high speed high resolution cameras on one usb as Windows can...

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a5f794fe-9653-4762-acea-69acd4927454%40googlegroups.com.

[Marek T.]

I've never said or suspected it's a W7 problem.
I only told that few cameras on the same hub works on Windows/Linux without problem and with very low cpu load, at 1080/30fps. But it causes some problems for someone when ran under openPNP.
But must admit actually that works for me the setup of ELP 720+1080 or 720+1200 on the same hub. But I prefer have them on different hubs for any case...

[Marius Liebenberg]

Marek I use Linux and ELP 720's and they do not work on the same hub at all.

[Marek T.]

I had no occasion to connect 2x720. I have tried 720+1200 (my actual setup going to be changed into 720+1080) and it worked, also 2x1080 but not bith ELP.
Interesting is that It didn't work for me still 3 months ago but did ok when I tested it again near 2 weeks ago. While I did not do anything with my computer, no system or java updates, no hardware change. It's like started work better since moment when Jason updated opencv (ok, I remember Jason said it's not connected, but just coincidence).

[Jason von Nieda]

@Mark et al: I agree - not a Windows 7 issue. Really just a bandwidth issue, I think. I just noticed that you said you tried "FullHD 30fps" and from looking at the camera formats (reproduced below) this would be 1920x1080. I think this is just too much for a single channel.

Here are the formats I have listed for this camera:

320X240  QVGA  MJPEG @120fps/  352X288 CIF  MJPEG @120fps
640X480  VGA  MJPEG@120fps/   800X600 SVGA  MJPEG@60fps
1024X768  XGA  MJPEG@30fps/  1280X720  HD   MJPEG@60fps
1280X1024  SXGA MJPEG@30fps/  1920X1080 FHD  MJPEG@30fps

Could you possibly try "1024X768  XGA  MJPEG@30fps"? This *should be* slightly less bandwidth than the 1280x720@30 FPS that I have done all my testing with, and I would expect it to work. It will at least confirm this theory.

Thanks,

Jason

On Tue, Jan 8, 2019 at 8:38 AM Marek T. <marek.tw...@gmail.com> wrote:

I had no occasion to connect 2x720. I have tried 720+1200 (my actual setup going to be changed into 720+1080) and it worked, also 2x1080 but not bith ELP.
Interesting is that It didn't work for me still 3 months ago but did ok when I tested it again near 2 weeks ago. While I did not do anything with my computer, no system or java updates, no hardware change. It's like started work better since moment when Jason updated opencv (ok, I remember Jason said it's not connected, but just coincidence).

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7d2498cd-7529-42a9-a287-4da04164460f%40googlegroups.com.

[Mark]

Hi Jason

 

I was kinda „hijacking“ someone’s Windows 10 computer, so my time was limited and I just tried one format, as I already established earlier  that all the formats use the same bandwidth, including the 1024X768  XGA  MJPEG@30fps you suggested to try (then and now) as documented here:

 

https://groups.google.com/d/msg/openpnp/k7M-Z-P1ivg/b_sPT0WuDQAJ

 

This makes sense as (M)JPEG compression can also be parametrized. In return the 1024X768  XGA  MJPEG format will probably show higher quality/fewer compression artefacts. I assume the camera just consumes the same fixed bandwidth budget (bitrate) in all modes.

 

A bit like the

 

ffmpeg –b:v

 

option.

 

I would do it this way if I were to implement a camera :-)

 

It greatly simplifies the implementation/testing etc., as the transport stream is always the same, even if the user were to switch the format on the fly.

 

_Mark

[Jason von Nieda]

Thanks Mark, I had forgotten that you had tested this before. So I guess this camera is just problematic - case closed :)

The Wiki has been updated to specify which camera is known to work well, and I think we now know what to look for when people are having problems. Success, in my book.

Jason

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/053701d4a774%246f82b930%244e882b90%24%40makr.zone.

[Mark]

> Success, in my book.

 

Agree 100%

 

Von: ope...@googlegroups.com [mailto:ope...@googlegroups.com] Im Auftrag von Jason von Nieda
Gesendet: Dienstag, 8. Januar 2019 18:10
An: ope...@googlegroups.com
Betreff: Re: [OpenPnP] openpnp-capture multiple cameras

 

Thanks Mark, I had forgotten that you had tested this before. So I guess this camera is just problematic - case closed :)

[tf38385656]

Hi  Jason von Nieda 

I use a expensive camera(USB3.0) and found it fourcc use RGB , NOT openpnp support YUV and Mjpeg.

How could i  change the source code ?

Because that camera could work in java (webcam-capture-  sarxos) and  java call python .

Wang 

Jason von Nieda 在 2018年12月5日 星期三凌晨1:27:04 [UTC+8] 的信中寫道：

The FOURCC message may indicate that that camera supports uncompressed RGB, and I don't think we support that mode in the library. We wouldn't want to use it anyway, it would be very high bandwidth.

The reticle messages are not important.  Just means no reticle preference has been set for that view, so it uses the default.

Jason

On Tue, Dec 4, 2018 at 11:25 AM Jason von Nieda <ja...@vonnieda.org> wrote:

Hi Marek,

Which camera specifically are you referring to with the exposure issue? If you can use sensor numbers or something in this discussion it will help me keep things clear. I am making a list of cameras and the problems or successes people have with them and this will eventually be used to update the Wiki.

Alternately, you can use the model number of the camera. For instance, on the ELP the model number is shown on the board. Like this one: http://www.elpcctv.com/720p-usb-camera-module-usb20-omnivision-ov9712-color-sensor-support-yuy-and-mjpeg-with-36mm-lens-p-194.html in the picture and in the item description you see the model number USB100W03M.

Thanks,

Jason

On Tue, Dec 4, 2018 at 11:15 AM Marek T. <marek.tw...@gmail.com> wrote:

Clear now!

"Exposure" couldn't be a reason of troubles a half year ago we've seen.

But the fact is that everytime I reconnect this camera from USB (but still on the same port) and run Openpnp, the screen is black until check on an auto-exposure. Then get the vision and can set auto-exposure off - in the moment there is no change on the image brightness, it remains "normal".

Doing the same on vmcap, the vision is also black but not absolutely total - the most bright objects are visible. When I check a-e image gets normal brightness and when check it off the brightness drops down a little (brightness does not mean slider value of course). Maybe it's only this camera specific but Mark could to check it on his setup.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0325bce0-0bc2-4f42-bf95-c8ae3487cec9%40googlegroups.com.