[Motmot] libcamiface

[Andrew Straw]

John Pye wrote:
> Hi Andrew
>
> Thanks for your help, hopefully I'll be up and running soon...
>   
Thank you for your detailed emails. Your feedback is valuable in making
motmot more user/developer friendly.
> Andrew Straw wrote:
>   
>> (I'm CCing your email to the motmot email list -- please join if you
>> remain interested in this.)  
>>     
>
> I couldn't join; I used the signup page but have received no
> confirmation email.
>   
OK, I'll investigate and see what's going on. In the meantime, I hope
you don't mind if I keep CCing the list. Curiously, I didn't get the CC
I sent in reply to your first email. So maybe there's something wrong
with the configuration there. Perhaps I should just get a google group
or something.
> About CMake, yes, I have heard that it makes things nice on Windows, and
> I guess that a large set of 'recipes' is helpful, but I still find
> myself preferring the concept of a build system based on proper
> language, not something new and bespoke. This means that I have done
> battle more with SCons than perhaps is wise!
>   
Well, AFAIK, SCons cannot automatically build binary installers with
about 5-10 lines of boilerplate. I personally wouldn't know how to start
building such installers, but with CMake, I get it virtually for free.
That's a huge win, I think. Of secondary importance to me, but perhaps
critical to potential libcamiface developers, is that CMake will also
emit XCode and Visual Studio projects instead of makefiles if asked. But
again, I initially chose it because I liked it better on linux than
scons or autotools. (And to be clear, I don't feel like I had to learn
much at all to make the CMake files. It just works.)

>>> Do you think camiface is at a stage where I should be trying to use it,
>>> or do you think I'd be better to wait a few months and come back when
>>> the API is more stable, or whatever?
>>>     
>>>       
>> It is definitely stable if you're on Linux and use libdc1394. Prosilica
>> GigE is also pretty good, but their PvApi software has been very, very
>> annoying to me over the years. Specifically, it uses signals for ITC
>> (inter-thread-communication), which results in often mysterious errors
>> that crop up in other parts of you application that may not handle EINTR
>> properly. Therefore, I shudder to recommend it to anyone, but I have
>> several camera setups for which there's no good alternative, so I'm
>> stuck dealing with the Prosilica SDK. To this day it causes me
>> mysterious crashes.
>>     
>
> Well, our camera is a Prosilica one, hopefully it won't be too
> problematic. The only issue I have noticed is that it doesn't cope well
> with the network dropping out, eg when the cable is unplugged (our
> camera seems to have a wobbly plug, what's worse). Perhaps this is
> something that could be addressed in the camiface interface, not sure
> how easy that would be.
>   
I'm glad you're having success with your setup. I'd love to find out
that I've been something wrong (and what that thing is, exactly) with
the Prosilica GigE library all these years. Do you miss many frames
(when your plug is not falling out)? What's going on with the rest of
your process? (Do you do heavy image processing or anything else?) What
data rates are you using? Do you have multiple threads (for GUI and/or
other)? Those are the things that caused problems for me -- not usually
just simple grabbing images. Also, the issues tended to be hard to
reproduce, such as only after 1 hour or more of streaming.
> Maybe the solution for the signal problem is to run the prosilica
> data-gathering stuff in a subprocess?
>   
I had that idea, too. The issue is that you need to get the image data
to process, save or display it. So, I created a "sharedmem" libcamiface
component to do this. It is complicated and brittle and lately it's
fallen into disrepair from lack of use. (There was nice period of
stability where it seemed like PvAPI 1.16 well behaved and we didn't
need the sharedmem module. Now we've had trouble while using 1.18, but
there are too many uncontrolled variables that it's difficult to assign
blame. I haven't tried 1.20 yet, but Prosilica's release notes don't
really mention anything that would suggest anything improved.) Anyhow,
the worst thing is that it's not really Prosilica's code that's buggy
per se -- it just reveals bugs (unhandled EINTRs) in everyone else's
code. So, any new library that makes system calls (what doesn't?) is a
potential source of conflict.
> FWIW in place of source packages you might consider my little tool
> 'dtar'...
>   
It looks interesting. I'll compare it with checkinstall, stow, and
debhelper 7 to see how it might fit into my toolchain or to offer any
comments.
>>> I also contacted Prosilica to ask their view on its possible (binary)
>>> redistribution, waiting to hear back.
>>>     
>>>       
>> They gave me permission to redistribute binaries. So I can't see why
>> they'd have a problem with you doing it...
>>
>> I think the ideal thing would be for them to open source their library.
>> A binary redistribution that would gather only few users would be
>> unlikely to be worth the effort of trying to get into Debian non-free or
>> Ubuntu multi-verse, I think...  
>>     
> Should be possible to distribute the .diff.gz in any case?
>   
Actually, upon closer inspection, I see that I do have these online:

for hardy:
http://debs.astraw.com/hardy/prosilica-gige_1.18-0ads1.dsc
http://debs.astraw.com/hardy/prosilica-gige_1.16-0ads3.dsc

for jaunty:
http://debs.astraw.com/jaunty/prosilica-gige_1.18-0ads2.dsc

>>> I think saw some crufty 'debian' folders nested within some or your
>>> code... is it possible to build camiface and pycamiface packages for
>>> Ubuntu 9.04?
>>>       
>> Yes, I am working on packages after I get libcamiface 0.5.3 out. But the
>> "debian" git branch of libcamiface should already more-or-less work
>> perfectly. pycamiface goes pretty cleanly with stdeb.
>>     
Also, I double checked and I have libcamiface and pycamiface binaries
for 9.04 online at http://debs.astraw.com/jaunty . I haven't tested
these too much -- I'd be happy to receive any feedback before
considering any moves of lab rigs around here to 9.04.
>
> As above, would be good if the debian/* files were including within the
> main tarball. Will then be obvious to Ubuntu/Deb people and irrelevant
> to others.
>   
I disagree -- I like having the debian/ directory totally in the
.diff.gz. Also, if a real Debian packaging genious wants to package my
code according to 100% debian spec, I'm happy to let him/her do so, and
undesirable contents in the debian/ directory is just going to
complicate their life. But, finally, if you checkout the "debian" branch
from the git repo, this is exactly what you get (merge the master in to
it with "git merge master" to get the latest).
>> And from your other email:
>>   
>>     
>>> I got libcamiface 0.5.2 built and I installed it to /usr/local using
>>> 'make install', and the simple-unity example seems to work OK.\
>>>
>>> However, using pycamiface 0.4.4 from PyPI, I get an error when
>>> attempting the basic install. I exported LD_LIBRARY_PATH=/usr/local/lib
>>> before attempting the following.
>>>
>>> Am I supposed to move the libcamiface stuff into the PYTHONPATH?
>>>
>>>     
>>>       
>> This is exactly the kind of thing I hope to deal with better using the
>> new CMake system... But, in the meantime, you can set the various
>> environment variables to see and fix what's going on:
>>
>> export UNITY_BACKEND_DEBUG=1
>> export UNITY_BACKEND_DIR=/usr/local/lib
>>   
>>     
>
> I tried this, it seems to change what happens with libcam_iface but
> doesn't in any way affect pycamiface or the building of pycamiface as
> far as I can see.
I wouldn't expect any change with the build. (Which shouldn't depend on
any installed libraries except the sharedmem module, which you'd do just
as well to disable for now.) As far as running pycamiface, you may have
to modify cam_iface_ctypes.py and see what directory it's trying to load
the .so file from and adjust as necessary. Again, I hope to clean this
up as part of the CMake-ification.

> I still get the same bug with simple.py (although the
> C example, simple-unity, now gives some debug output).
>
> What is the difference between running "simple-unity" and
> "simple-prosilica_gige"? Is it just the fact that unity is making use of
> the dlopen mechanism to load the appropriate driver, whereas the
> prosilica one only gives (direct) access to prosilica camera types?
>   
That's it. The unity backend allows runtime selection of the real backend.
> Still no idea how to make the pycamiface stuff work. Looks like it's
> trying to fetch something out of a zipfile that's not there... surely
> the libcam_iface_unity.so file should be assumed to have been already
> installed in /usr/lib or /usr/local/lib?
>   
IIRC it will guess /usr/lib by default. I'm not sure what's going on
with this zipfile business. Is setuptools installing pycamiface as a zip
file for you (momot.cam_iface-0.something.egg)? Add "zip_safe=False" in
the setup.py setup() call. Also, try "import pkg_resources" at the top
of your demo script.
> Wonder if perchance you have any demo code for GTK+ that displays
> pycamiface images in a window?
>   
Not GTK+, but pyglet. I imagine it's not hard to shove a pyglet OpenGL
window into GTK+. motmot.wxglvideo does it with wx. I just wrote
"fmf_tail" to show the last frame of an .fmf file to pyglet image. Given
that an .fmf file is a raw dump of the camera pixels, it should be
pretty simple to fuse it with very_simple.py from the pycamiface demo
directory:

http://github.com/motmot/flymovieformat/blob/master/motmot/FlyMovieFormat/fmf_tail.py
http://github.com/motmot/pycamiface/blob/master/demo/very_simple.py

Also, I wrote a pure C glut viewer for libcamiface:
http://github.com/motmot/libcamiface/blob/master/demo/liveview-glut.c

Most (all?) of these haven't made their way into releases yet. (I'm
still trying to bang libcamiface into better shape before a CMake based
release.)

> Curious about whether you considered starting with V4L or GStreamer when
> developing your camera interface? Or maybe these are too
> platform-specific? I'm new to all this, so not sure what the pros/cons
> of different video streaming tools might be.
>   
I'd love to implement a gstreamer source for libcamiface cameras. It
simply has never gone to the top of the priority list. Streaming live
video to OpenGL via pygarrayimage works pretty well with low overhead
most of the time, but when the inevitable graphics driver issues creep
up, they're all mine to deal with. Presumably, using the gstreamer
interface would mean that a lot of people would care about, and
consequently fix, bugs. Furthermore, all the color conversion stuff in
motmot is in dire need of serious cleanup and a test suite... and all of
which has been invented a million times over on each platform. But
there's not one API for them all, as far as I know.
> I note that the 'make install' of libcamiface seems not to install its
> header file anywhere. Perhaps you missed this in the CMake rewrite?
>   
Ahh, yes, I noticed that today, too. I'll have to fix that...

-- 
Andrew D. Straw, Ph.D.
California Institute of Technology
http://www.its.caltech.edu/~astraw/