On Fri, 2007-06-01 at 08:57 +0200, Michael Scholles wrote:
> on 1.6.2007 08:00 Damien Douxchamps wrote:
> > On Thu, 2007-05-31 at 11:35 -0500, Jon Schewe wrote:
> >> I know this list is for 1394 cameras, but some people here might be able
> >> to point me at some information on this.
> >> I've recently started working with Prosilica's Gigabit Ethernet cameras.
> >> Does anyone know of an open-source driver for these? I've got a binary
> >> only library from Prosilica I can use, but I'd rather have source if
> >> possible.
> > I don't know any implementation. AFAIK the reason is simple: GigE does
> > not define exact register implementation; it mearly defines the lower
> > transport layers. Therefor every manufacturer has its own home-brew
> > "IIDC".
> > If I'm wrong let me know: I'd be happy to start a libgige ;)
> to my knowledge, you're right. That's basically the reason for the GenICam effort.
> what about a libgenicam???
The last IIDC meeting in Tokyo at Toshiba-Teli went a bit over my head:
it was 100% Japanese ;) But with a bit of translation and a couple of
English slides this is what I understand of Genicam...
Genicam will offer a common description language (XML-based) to
enumerate the capabilities of the camera (features, values, types,
ranges, etc etc). This description file will depend on the brand/model
and will be provided by the manufacturer. The specs for this are
Below that level, the functions to control the camera (for IIDC, write
to registers) will remain proprietary, as will all capture related code.
The API is standardised by an intermediate layer that loads the
lower-level drivers, but this lower-level code is closed and provided as
a DLL by the manufacturer (I used DLL here because I don't think we'll
have a lot of .so ...)
So basically you have an XML description file sitting on top of a
linking layer (API - low level drivers) sitting on a pile of proprietary
code. What's the advantage for us? I don't have a clue. We won't know
what's going on at the lower levels, so we can't make an open source
driver. Maybe the manufacturer will provide a Linux control library, but
it's up to him. The only thing we could do would do is to code the API
that loads vendor drivers. But the API/loader is already available as
Why is Linux mentioned in Genicam then? Well, because they would like to
use Linux, but keep things locked. Example: you can have access to a
reference implementation of the XML parser and the standard API library
(which links the lower level proprietary code to the higher levels).
Very nice, but 1) it's only available to Genicam members
(individuals/groups not accepted, you have to be a company) and 2) even
though you have access to the sources you can't spread them (you can
only distribute binaries).
For me, this leads to two conclusion: 1) there's nothing we can do for
genicam, and 2) I doubt that the genicam group is expecting anything
from us. Game over.
All this does not mean that Genicam is useless, of course. For people
selling software that should be camera independent, Genicam will be a
real heaven (1394? GigE? CameraLink? No problem!) But there's no place
for open-source in that framework, IMHO.
This is roughly what I understand from Genicam. I may be wrong, please
correct me ;)
_ Damien 高原 Douxchamps
('- Assistant Professor
//\ Image Processing Laboratory, NAIST