[PD] Gem: Looking for suggestions for camera / capture setup

Antoine Villeret antoine.villeret at gmail.com
Wed Mar 10 09:40:44 CET 2021


Hi,

Usually the USB3 industrial cameras use iIDC protocol which comes from
legacy Firewire cameras.
IIDC is also implemented on some USB2 cameras (like Point Grey Chameleon in
its first version).
And IIDC is supported in Gem through the libdc1394 plugin.
Some vendors implement special features available only through their own
SDK but I never need to go that route.

Concerning the GigE protocol, there is an open source implementation with
Aravis which is not directly integrated into Gem afaik.
Put there is a Pylon plugin which is vendor specific and you might also
access GigE camera with Gstreamer.
So at least you should be able to write a pipeline to forward GigE frames
to Gem via v4l2loopback on Linux.
But I never did that and to be honest if I have to work with GigE camera in
Gem, I'd probably write a new plugin if needed instead of trying to
setup Gstreamer.
The main advantage of GigE over IIDC is the cable length. With USB and
Firewire it's hard to work with cable more than 10m long, especially if you
target high framerate / resolution (which means high bandwidth).
GigE pushes this limitation to hundreds meters (depending on the cable
quality and RF environment).

Concerning triggering the Gem render pipeline with the camera itself, I'm
not sure it is possible out of the box. Most of the video plugin uses
polling to get frames : a thread runs in the background to retrieve frames
from the camera and then when the [pix_video] receives a gemstate from a
gemhead it checks if there is a new frame and copy it to the Gem thread to
use it.
So if you want to trigger the gem render pipeline with a camera frame you
probably need to write a custom external that waits for a new frame (and
thus blocks the whole Pd instance).
Another solution is to do the reverse : trigger the camera upon Gem's
refresh. Most of industrial camera have a trigger input to release the
(electronic) shutter.
With some hardware hack you would be able to take an image with the camera
when you need it.
But then you might need to wait for the shutter to close and then for the
image to be processed and sent by the camera. That's not tricky.

Syncing the image processing pipeline on a camera frame is not that easy in
any case. Even if you write all the code from scratch in C++ for example
(which I did).

Hope that helps

Cheers

Antoine

Le mer. 10 mars 2021 à 00:07, Max <abonnements at revolwear.com> a écrit :

> On 09.03.21 11:39, Csaba Láng wrote:
> > Hi All,
> >
> > I have made an interactive squash system with Pd based on Basler's high
> > speed cameras for machine vision. I use mainly above 200fps of 5 USB-3
> > cameras each of them on a separate USB bus.
> Very cool.
>
> Do you know which model?
> https://www.baslerweb.com/en/products/cameras/area-scan-cameras/
>
> I see USB3 vision is the standard. That works out of the box with Gem?
> What I read here sounds promising:
> https://en.wikipedia.org/wiki/USB3_Vision
>
> I remember GigE which was terribly hampered and one could download an
> SDK after signing an NDA, but even with that SDK I wasn't able to get it
> into Gem.
>
> Would something like this work equally:
>
> https://www.alliedvision.com/en/products/embedded-vision-cameras/detail/Alvium%201800%20U/-240.html
>
> Also I think I have this frame grabber here in a different machine:
>
> https://www.baslerweb.com/de/produkte/framegrabber-portfolio/framegrabber/microenable-5-ironman-aq8-cxp6d/
>
> How big are my chances that I can get images from Gem with that card on
> Linux?
>
> Max
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210310/f90c4937/attachment-0001.htm>


More information about the Pd-list mailing list