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@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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list