I would like to propose / inquire about the availability of multi-cam PS3 Eye access and control in LabVIEW. Explanation:

- LabVIEW uses IMAQdx for USB cameras, which is DirectShow ported and dependent (PS3 Eye multi-cam not supported)
- using the SDK DLLs is particularly trouble some, can only be done via the Call Library Node, or a deicated driver
- Porting the above requires hard-coding some work that normally a compiler does, and a wrapper has to be implemented
- There is no function pointer equivalent in LabVIEW, making this even worse

Is there any chance that a multi-cam DirectShow component is / will be available at least in the commercial Platform Packs, if not the free SDK? Many LabVIEW users would gladly buy your Platform Packs, including myself, if it provided multi-cam LabVIEW support. Alternatively, I believe a lot of us would be happy to purchase a dedicated LabVIEW multi-cam driver (even if for the same price as the 2-4-8-16 cam Platform Packs are sold), so in either case, codelaboratories would all of a sudden open towards programming lanfguage particularly popular in the image processing / machine vision community.

The latest driver (5.1.1.0177) works fine even from VisionExpress, with all the speeds supported, this is of great benefit for a fixed frame rate camera, although output format is “RGB” only (which seems a packed 16bit YUYV), therefore additional to the absolutely critical multi-cam DirectShow support, a 8bit grayscale Y800 chip-level output would be highly beneficial (improving bandwidth usage and limitations, as well as noise at higher frame rates).

Although LabVIEW is a programming language, so support via SDK would be ideal (especially in case of a language of such relevance to vision development), do the new 2012 Platform Packs support multi-cam DirectShow ported access? If so, please let us know, and customers will arise en masse. If not, when could this feature be available, if at all?

Found an alternative driver / software, supporting recording from up to 6 cameras, freeware. VERY similar driver implementation, same coinstaller resources, however, this driver doesn’t show a single camera in LabVIEW (at least the CL Driver 5.1.1.0177 shows up ONE in VisionExpress). Accidentally supporting the XBOX brick-sized camera, too.

It is possible to generate a VISA driver using the NI VISA Driver Wizard for USB devices, I get a BLength field incorrect for USB_Endpoint_Descriptor error (1073807175) straight away, but VISA Driver generation seems smooth. I note here that M$ WebCam Live! has been confirmed to be fine for VISA Driver generation using this method. However, I can’t test the resultant INF and PNF, since I have no licence for Measurement and Automation Explorer, where that could be done with ease. You can access a guide to doing this (using an M$ WebCam Live! successfully) here:

http://www.ni.com/white-paper/4478/en

Alternative drivers and rudimentary reecording software (up to 6 cams):

http://wiki.ipisoft.com/User_Guide_for_Multiple_PlayStation_Eye_Cameras_Configuration#iPi_Recorder

Along the lines of DirectShow porting for driver programmers (some are unix, can be ported to windose, example above):

http://directshownet.sourceforge.net/
http://www.openni.org/Downloads.aspx
http://www.ffmpeg.org/download.html

LabVIEW solution still not found, any suggestions? Codelaboratories people perhaps?

Hello? I really would like to discuss any possibility that may be seen as feasible by Codelabs for multiple (at least 2) PS3 Eyes to be used within LabVIEW VisionExpress please, commercial or otherwise.

Tried installing the trial version of the CLStudio, the following happens:

- unfavourably not an offline installer, downloads cvredist (lame visual studio component) and quicktime
- PUP positive installer exe (allowed, ignored)
- CLAgent.dll trojan positive by AVG (allowed, ignored)
- CLStudio still does not recognise any of the 2 cameras, lol
- uninstalling the software leaves “CLStudio Devices” in DShow enum list
- you’ll need to keep the file clstudioaxfilter.ax, and unregister it manually (console command regsv32 /u <filepath>, can put a copy anywehre to unreg)

Looking at DShow porting, it does offer a DShow enumeration of 2 devices recognised as “CLStudio device 1/2” within LabVIEW VisionExpress. Of course, these won’t work. Tried manually registering clstudioaxfilter.ax (that’s the “Proxy”), still can’t get a video stream, even at the exclusive 640x480 @ 30fps option available. “CL Proxy cannot be found”, or something like that.

I have also tried various driver inf, cat, and dll manipulations to no avail so far.

However, since I see now that DShow porting for multiple cameras can be done with ease, is there ANY solution, at least in your commercial CL Platform Packs, to get it working under LabVIEW using VisionExpress?

Anyone from CodeLabs perhaps? Please?

Metrologue - 01 July 2012 08:20 AM

I would like to propose / inquire about the availability of multi-cam PS3 Eye access and control in LabVIEW. Explanation:

- LabVIEW uses IMAQdx for USB cameras, which is DirectShow ported and dependent (PS3 Eye multi-cam not supported)
- using the SDK DLLs is particularly trouble some, can only be done via the Call Library Node, or a deicated driver
- Porting the above requires hard-coding some work that normally a compiler does, and a wrapper has to be implemented
- There is no function pointer equivalent in LabVIEW, making this even worse

Is there any chance that a multi-cam DirectShow component is / will be available at least in the commercial Platform Packs, if not the free SDK? Many LabVIEW users would gladly buy your Platform Packs, including myself, if it provided multi-cam LabVIEW support. Alternatively, I believe a lot of us would be happy to purchase a dedicated LabVIEW multi-cam driver (even if for the same price as the 2-4-8-16 cam Platform Packs are sold), so in either case, codelaboratories would all of a sudden open towards programming lanfguage particularly popular in the image processing / machine vision community.

The latest driver (5.1.1.0177) works fine even from VisionExpress, with all the speeds supported, this is of great benefit for a fixed frame rate camera, although output format is “RGB” only (which seems a packed 16bit YUYV), therefore additional to the absolutely critical multi-cam DirectShow support, a 8bit grayscale Y800 chip-level output would be highly beneficial (improving bandwidth usage and limitations, as well as noise at higher frame rates).

Although LabVIEW is a programming language, so support via SDK would be ideal (especially in case of a language of such relevance to vision development), do the new 2012 Platform Packs support multi-cam DirectShow ported access? If so, please let us know, and customers will arise en masse. If not, when could this feature be available, if at all?

We are currently working on a commercial version of the driver that will (among other improvements) add support for multiple PS3Eye cameras and expose them via DirectShow. We will release a beta version of this driver as soon as we finalize development and testing.
We are very happy to be able to support the LabVIEW users in the near future.

The output format of the DirectShow source filter is RGB32, however this does not mean that the camera is sending the data formatted in the same way via USB bus. The USB bandwidth is already optimized by configuring the camera to send only minimal amount of data necessary. Adding the Y800 mode is possible and will be considered to be included in our next version of the driver.

As a temporary solution, please take a look at the CL Eye SDK. It may be possible to extend the LabVIEW by adding PS3Eye multi-camera support using the SDK (it seems that LabVIEW already supports calling external dlls).

Thanks for your attention in this matter.

Will the beta version be free, say, for 2 cameras, like the SDK? Perhaps having the excellent up to 16 cam option available commercially?

I see about the DShow filter RGB32, I wasn’t aware of this, thanks. If the USB bandwidth is already optimised, I think a 8bit grayscale DShow filter output option would be even more productive and meaningful, especially for non-standard PC based LabVIEW compiled software deployment, HIL, and higher camera numbers, eliminating the computational load excess to convert each RGB32 stream to 8bit grayscale when colour is not needed (also eliminating some colour compression related noise if only the intensity element is captured, if I am correct).

I have looked at both the excellent SDK, and briefly also looked into calling the dll from LabVIEW. As it surely contains functions called with / for complex data, I understand that coding a separate wrapper is required (?). I am unsure whether I am skilled enough in C/C++ to do this, although I might try. Am I right to assume that I should see parameter data and return types automatically via the Call Library Function Node in LabVIEW, and hence to assume that the SDK dll has been compiled with a Type Library? Sorry if the question is trivial, I have never touched dlls before.

However, I’d rather focus on vision development, as well as I also understand the the SDK dll supports 2 cameras only, so my surely amateur camera control solution, even if successful, would be for some initial trials only. Modifying a DSHow filter to capture in grayscale directly would also be beyond my reach I am afraid, so in any case, the new beta is very much awaited, not to mention the 4+ camera commercials after!

Regards,
Metrologue