75 fps no such option
seewanhwg opened this issue · comments
Anyone know the register command to send to get 75 fps the code only have up to 60fps
The PS3 Eye only supports a max FPS of 60 FPS when running at 640x480. If you want 75 FPS, you'll have to drop back to 320x240 (max FPS of 205).
The CL-Eye driver is able to do 75 fps:
CLEYE_VGA - 15, 30, 40, 50, 60, 75. (Taken from here: https://codelaboratories.com/research/view/cl-eye-muticamera-api)
Mmmh... I have these drivers, but not tried with 75 fps. However I switch to Code Laboratories drivers because unfortunately the inspirit one doesn't works properly with multiple cameras on my system (the second camera slow down to 5 fps, there is like some interference between the cameras). With codr laboratories it works so I don't think is a problem of my usb controller. I can give a try with 75 fps later.
Inviato da Yahoo Mail su Android
Il lun, 1 feb, 2016 alle 23:35, Charles Dotynotifications@github.com ha scritto:
The CL-Eye driver is able to do 75 fps:
CLEYE_VGA - 15, 30, 40, 50, 60, 75. (Taken from here: https://codelaboratories.com/research/view/cl-eye-muticamera-api)
—
Reply to this email directly or view it on GitHub.
The CL-Eye driver is able to do 75 fps:
CLEYE_VGA - 15, 30, 40, 50, 60, 75. (Taken from here: >https://codelaboratories.com/research/view/cl-eye-muticamera-api)
While the comments might say that, I'm not sure it's actually true. Have you tried it (and does it work)? The datasheet for the sensor in the PS3 Eye Camera states:
Max Image Transfer Rate: 60 fps for VGA
However I switch to Code Laboratories drivers because unfortunately the inspirit one doesn't works properly with multiple cameras on my system (the second camera slow down to 5 fps, there is like some interference between the cameras)
I also had the same problem with PS3EYEDriver. That's why I made this pull request: #21
For me, that fixed the problems with multi-camera performance. The pull request has been accepted last night, so if you're interested, you could try out the latest version of PS3EYEDriver to see if it fixes the performance problems you were seeing with multiple cameras (it did for me).
Thanks for this advice, but I have bought the license for 8 cameras and for now I will use it (it seems work well).
Inviato da Yahoo Mail su Android
Il mar, 2 feb, 2016 alle 11:55, Ritesh Oedayrajsingh Varmanotifications@github.com ha scritto:
The CL-Eye driver is able to do 75 fps:
CLEYE_VGA - 15, 30, 40, 50, 60, 75. (Taken from here: >https://codelaboratories.com/research/view/cl-eye-muticamera-api)
While the comments might say that, I'm not sure it's actually true. Have you tried it (and does it work)? The datasheet for the sensor in the PS3 Eye Camera states:
Max Image Transfer Rate: 60 fps for VGA
However I switch to Code Laboratories drivers because unfortunately the inspirit one doesn't works properly with multiple cameras on my system (the second camera slow down to 5 fps, there is like some interference between the cameras)
I also had the same problem with PS3EYEDriver. That's why I made this pull request: #21
For me, that fixed the problems with multi-camera performance. The pull request has been accepted last night, so if you're interested, you could try out the latest version of PS3EYEDriver to see if it fixes the performance problems you were seeing with multiple cameras (it did for me).
—
Reply to this email directly or view it on GitHub.
The PS Eye supports 640x480@75fps by using the raw Bayer mode instead of YUYV.
From https://codelaboratories.com/forums/viewthread/168/ :
640 * 480 * 16(bits per pixel) * 60(fps) = 294912000(bits per second) or approx 281(Mb per second)
This is still high for USB2.0 but practically doable. Now you wonder how do we get 75fps is this is pushing the USB2.0 protocol so much.
Fortunately there is another format and that is the native sensor data format. The main difference between color and monochrome CMOS sensor is that the color one has a special color filter array applied on top of the sensor pixels. This filters the light so that appropriate pixels of the sensor receive appropriate color information. Contrary to the popular believe the color sensor does not have any more physical pixels than monochrome one. Meaning, the color CMOS sensor in PS3Eye has total of 640x480 pixels each of which carry different color information according to the Bayer filter mosaic pattern (see attached image). Because of this, if we were to transmit this raw sensor data, the bandwidth requirement for 640x480 @ 60fps would be:
640 * 480 * 8(bits per pixel) * 60(fps) = 147456000(bits per second) or approx 140(Mb per second)
Thanks Frederic
How do we access the bayer traw sensor data and how do we convert into RGB ? or even monochrome for processing . thanks
If you go to the datasheet @rovarma linked above, page 13, the row for HEX12 - COM7, it says how the output format can be changed. For this to work, PS3EYEDriver would have to expose setting this register bit, AND it would have to support reading the data stream correctly.
I'm also interested in seeing this work, if the format still allows for accurate colour filtering.
I'd also like to see RGB output with B/R swapped (see HEX0C/COM3). As it is now, the first thing I do with every YUV frame is convert to BGR, because that's what OpenCV uses.
Some additional details:
If one wants to then convert Bayer to another format, this can be done with OpenCV.
OpenCV3's cvtColor can do this. Here are the possible conversions, including COLOR_BayerXX2YYY where XX can be BG, GB, RG or GR, and YYY can be BGR or GRAY. One can also append _VNG or _EA for smarter edge detection.
See #30
Thanks for bringing this to my attention @cboulay.
I actually started looking at Bayer support a few weeks ago, but had to drop it for a while due to E3 deadline madness. Now that that's over, I can start back on this; hopefully it shouldn't be too much work.
Though I think it makes the most sense to do the conversion to RGB/BGR inside the library, rather than just exposing raw Bayer to users.
Though I think it makes the most sense to do the conversion to RGB/BGR inside the library, rather than just exposing raw Bayer to users.
I think you're right that it would be tremendously helpful to have a conversion to BGR/RGB in PS3EYEDriver, one that doesn't depend on behemoth OpenCV.
That being said, it might be nice to get access to the raw Bayer stream too so we can test different algorithms for colour interpolation; this might benefit PSMove tracking.
Ideal scenario, we'll have a bunch of output options:
- Bayer
- Up to 75 fps @ 640 x 480
- YUV
- Up to 60 fps @ 640 x 480
- Same as current
-
60 fps @ 640 x 480 from Bayer
- Up to 60 fps @ 640 x 480
- RGB
- Up to 60 fps @ 640 x 480
- Any reason to not use 565?
- Requires conversion from source range (4,5, or 6 bits) to 8-bit range
-
60 fps @ 640 x 480 from Bayer
- Up to 60 fps @ 640 x 480
- BGR
- Same as above (<= 60 fps) with extra settings to swap R and B
-
60 fps @ 640 x 480 from Bayer
Yep, I think that makes sense.
Just had a quick test with switching the camera to Bayer and it seems it will be a bit more work than I thought; the camera appears to be streaming data just fine, but it looks like the output is no longer a UVC stream. At least, it never sees an "end of frame" during packet processing so just hangs indefinitely.
Will need to do some debugging to figure out what's causing it (not very familiar with UVC).
The author of CL Eye posted another comment related to Bayer mode somewhere, he said that switching to this mode was pretty involved and needed registers tweaking and timing IIRC.
EDIT: found the thread : https://codelaboratories.com/forums/viewthread/301/
Well, to paraphrase what he said:
"It's pretty hard. You should probably buy my software (even though my software is Windows-only and you're using Linux)".
I'm sorry if I don't trust that he was being entirely forthcoming.
While I would normally share your skepticism, in this case he is probably right. I've spent the last few evenings (and train journeys) looking into enabling Bayer mode and it's definitely not trivial. I've made some progress, but am still quite a ways off from having something working.
Unfortunately, I don't currently have the time to fully dedicate myself to this, so I'll put this on hold from my end for now. I'll probably investigate this further at a later point since Bayer mode solves a lot of the performance problems with the current driver, but it won't be in the next few days.
@rovarma Can you make a public branch of your work so far? I doubt I'm going to work on it but I would like to see your approach.
@cboulay @HipsterSloth Sent you guys a mail about this.
Support for this (both Bayer and 75 FPS) is now in through #33