[Rock-dev] Cleaning up camera stack

[Alexander Duda]

Am 02.03.2015 um 21:43 schrieb Sylvain Joyeux <bir.sylvain at gmail.com>:

> On Mon, Mar 2, 2015 at 11:38 AM, Alexander Duda <Alexander.Duda at dfki.de> wrote:
>>> drivers/camera_ids
>>> drivers/camera_firewire
>>> drivers/camera_unicap
>> 
>> All basic camera access can be done with opencv. If you are looking for
>> more advanced cameras you should use cameras supporting GeniCam.
> 
> The idea of having a GeniCam orogen component is awesome, given that
> GeniCam really seems to become the standard API for industrial
> cameras. But this does not have to be a either-or, just a "and". I
> don't see a problem with keeping the orogen components for the cameras
> that are not supported by genicam. Stop supporting them personally if
> you want, and someone else (Matthias ?) can decide to become their
> maintainer if he wishes to. I see *NO* need whatsoever to have a
> common camera interface for all cameras on the earth. As you mention
> it yourself in the shortcomings of the current approach, that leads to
> a lot of layering and complexity.
I would leave camera_interface for backward compatibility but wouldn’t use it in any newer projects. It is just not worth the effort.

> 
> Which leads to the following remarks (based on the wiki):
> 
>   -  implement new orogen/camera_base
> 
> Why ? Why not only orogen/camera_genicam ? You start again with some
> kind of an "interface“ !
Yes, the interface is for maintain the same properties and port names for the very basic features usual cameras do understand 
 * fps
 * gain
 * color format
Furthermore, I would put everything into orogen/cameras and use the CMake infrastructure to decide which camera should be build. 
 * GENICAM ON OFF
 * OPENCV ON OFF 

> 
>   - string based setter and getter for camera features
> 
> I assume that you mean "operation" ? Why not properties instead ?
> Operations are not logged and cannot be set in configuration files
> (and you can change properties dynamically nowadays if you wishes to)

If you want to use properties you would have to open the camera before you configure it to ask for its xml configuration file. Then, all the properties have to be generated dynamically. This is adding a lot of overhead especially if you only want to load a configuration directly stored on the device. Therefore, I would add operations and a property with a std::vector of string pairs to allow a configuration from yaml files (Keep it stupid and simple ;-). To generate the configuration file a tool can be used displaying all available features and values for the current camera in a graphical interface.

Alex


--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center

Hauptgeschäftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 1
28359 Bremen, Germany

Tel.:     +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail:   Alexander.Duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20150303/f8c825f9/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://www.dfki.de/pipermail/rock-dev/attachments/20150303/f8c825f9/attachment.pgp