[Motmot] libcamiface

[Andrew Straw]

(I'm CCing your email to the motmot email list -- please join if you
remain interested in this.)

John Pye wrote:
> Hi Andrew

G'day John! (I lived in Adelaide for a few years and developed a
fondness for Australia... really I'm a Yank.)

> I have been having a little look at your camiface code with a view to
> using it for some solar energy reflector characterisation work here at
> ANU. Looks like you have written some pretty useful software here that
> should allow us to build our little system in a camera-agnostic way to
> some extent.

That's the idea!

> It looks like your code is undegoing some fairly rapid change at the
> moment though... 

Yes and no... see below. The bottom line is that the libcamiface API has
changed very, very little (and it would be a royal pain for me to change
it much) in the last year or more. Most of what you see is
infrastructure improvements (hopefully) that will allow the library to
be better tested, more robust, more cross-platform, and hopefully to
attract some more users and developers.

since last week, it seems that you have migrated from
> subversion to git,

True. (Publically, at least. I had been using git-svn to interact with
the motmot repository for a lot longer.)

 and from SCons to CMake.

True

 Is that correct, or was I on
> an old version of your website, or somesuch? (You appear to be a
> commited Python user -- I'd be curious why you gave up on SCons, if what
> I say is true -- has it been a big improvement for you?)

I'm in the process of making libcamiface more Mac- and Windows-friendly,
and CMake has been fantastic for that -- with its CPack it is possible
to build Mac .dmg/.pkg installers and Windows NSIS installers all from
the same source code. (Not to mention CMake will build platform specific
"makefiles", such as XCode projects for Mac and Visual

Although CMake is yet another syntax, it's simplicity and pre-existing
recipes are very nice and have let me do things in a standard way that
SCons just doesn't. I looked at a whole bunch of debian/rules files for
scons and cmake based projects when evaluating this. From these data, it
appeared every Debian scons project had more-or-less project specific
build instructions, whereas cmake projects were much more formulaic.
Actually, I also tried autotools before trying CMake. It made me run
screaming in fear. Mixing bash, m4 and makefile syntax?? Ahhh! And then
I considered Windows with that -- no way. CMake has been quite smooth
going across all 3 of the platforms I've tested.

> 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.

> Also, BTW, I have built a Debian package of the Prosilica SDK; I can
> send you the build code for it if that's interesting to you.

So do I. You can see my Prosilica packages at debs.astraw.com/hardy, for
example. It appears I haven't uploaded the source packages, though...
I'm not sure why but can investigate and upload if it wasn't some legal
reason.

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...

> 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.

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

-Andrew

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