<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>Am 02.03.2015 um 21:43 schrieb Sylvain Joyeux <<a href="mailto:bir.sylvain@gmail.com">bir.sylvain@gmail.com</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Mon, Mar 2, 2015 at 11:38 AM, Alexander Duda <<a href="mailto:Alexander.Duda@dfki.de">Alexander.Duda@dfki.de</a>> wrote:<br><blockquote type="cite"><blockquote type="cite">drivers/camera_ids<br>drivers/camera_firewire<br>drivers/camera_unicap<br></blockquote><br>All basic camera access can be done with opencv. If you are looking for<br>more advanced cameras you should use cameras supporting GeniCam.<br></blockquote><br>The idea of having a GeniCam orogen component is awesome, given that<br>GeniCam really seems to become the standard API for industrial<br>cameras. But this does not have to be a either-or, just a "and". I<br>don't see a problem with keeping the orogen components for the cameras<br>that are not supported by genicam. Stop supporting them personally if<br>you want, and someone else (Matthias ?) can decide to become their<br>maintainer if he wishes to. I see *NO* need whatsoever to have a<br>common camera interface for all cameras on the earth. As you mention<br>it yourself in the shortcomings of the current approach, that leads to<br>a lot of layering and complexity.</blockquote>I would leave camera_interface for backward compatibility but wouldn’t use it in any newer projects. It is just not worth the effort.</div><div><div><br></div><blockquote type="cite"><br>Which leads to the following remarks (based on the wiki):<br><br> - implement new orogen/camera_base<br><br>Why ? Why not only orogen/camera_genicam ? You start again with some<br>kind of an "interface“ !<br></blockquote><div>Yes, the interface is for maintain the same properties and port names for the very basic features usual cameras do understand </div><div> * fps</div><div> * gain</div><div> * color format</div><div>Furthermore, I would put everything into orogen/cameras and use the CMake infrastructure to decide which camera should be build. </div><div> * GENICAM ON OFF</div><div> * OPENCV ON OFF </div><br><blockquote type="cite"><br> - string based setter and getter for camera features<br><br>I assume that you mean "operation" ? Why not properties instead ?<br>Operations are not logged and cannot be set in configuration files<br>(and you can change properties dynamically nowadays if you wishes to)<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Alex</div><div><br></div></div><div>
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline">--</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Dipl.-Ing. Alexander Duda<br>Unterwasserrobotik<br>Robotics Innovation Center<br><br>Hauptgeschäftsstelle Standort Bremen:<br>DFKI GmbH<br>Robotics Innovation Center<br>Robert-Hooke-Straße 1<br>28359 Bremen, Germany<br><br>Tel.: +49 421 178 45-6620<br>Zentrale: +49 421 178 45-0<br>Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)<br>E-Mail: <a href="mailto:Alexander.Duda@dfki.de">Alexander.Duda@dfki.de</a><br><br>Weitere Informationen: <a href="http://www.dfki.de/robotik">http://www.dfki.de/robotik</a><br>-----------------------------------------------------------------------<br>Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH<br>Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern<br>Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster<br>(Vorsitzender) Dr. Walter Olthoff<br>Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes<br>Amtsgericht Kaiserslautern, HRB 2313<br>Sitz der Gesellschaft: Kaiserslautern (HRB 2313)<br>USt-Id.Nr.: DE 148646973<br>Steuernummer: 19/673/0060/3</div></div></div>
</div>
<br></body></html>