OpenCV Calibration Wrapping - Some questions

[SirVer]

Hi,

> I see you looked a the C-library loading routines.  If possible, we
> should try and re-use
>
> numpy.ctypeslib.load_library
Afaik the loading of the library is only to check if the library
really is there. Nevertheless,
on MacOS X it is needed to probe many paths for the library, since
there is no ldconfig or
similar. replacing ctypes.CDLL throuhg ctypeslib.load_library is not a
problem.

> > Some questions remain for me though:
> > 1) Where do convenience wrappers go?
> > The OpenCv is terrible to use. I'd like to offer a more Pythonic
> > interface to the stuff I am currently wrapping. An Example would be an
> > ImageUndistorter class that would offer a single interface to
> > undistort multiple Images in a Row. Where should this go? obviously
> > into the opencv module, but how should this module be sorted?
>
> We have to be careful with the scope of the scikit, which is to
> implement basic tools needed for image processing.  For example, the
> above result may be obtained by combining
> scikits.image.io.ImageCollection with the opencv wrapper, instead of
> writing a custom class.  It's worth answering the question: what is
> the fundamental set of tools users would need to obtain results/do
> research.
Year, what is it? My scope is naturally a bit wider here I guess: I'd
like
to have as many tools for image processing available to me as
possible. This would
even contain image acquisition (Actually, I have a quite healthy
ctypes wrapper
around libdc1394 2.0 which you can find on launchpad. This + ctypes
can do fun
stuff: http://www.youtube.com/watch?gl=DE&hl=de&v=5O4FrRujlII) and GUI
Stuff.

But (intrinsic) camera calibration is (for me) fundamental: All Images
come from
one camera or another and (intrinsic) calibration is needed for all
kind of
measuring applications with images.

> > 2) Utility scripts
> > I'd like to contribute my camcalib script which I wrote for intrinsic
> > calibration of monoscopic cameras. I wrapped the opencv with Ctypes
> > for that; obviously I will first add the needed functions to the
> > current opencv wrapper. The first question here is were do those
> > scripts live so that the user can easily start them as soon as the
> > scikit is installed?
>
> Does camera calibration fall under the umbrella of image processing?
> The reason I ask is because we're trying to get another project off
> the ground with Andrew Straw:
>
> https://launchpad.net/pinpoint
I am not so much into stereo. I only need intrinsic calibration; I
feel this
is fundamental.

>
> > 3) GUI dependency.
> > I use Pyqt for all my image processing tools because it is very fast
> > (200 fps is no problem to display) and because it is very convenient.
> > I feel that a image scikit should provide some GUI functionality (what
> > good is image processing without seeing images?) and I would urge to
> > investigate PyQt. With this question, I just want to get the ball
> > rolling; I feel the discussing of wether GUI tools are wanted or not
> > and which toolkit to use or not might be crucial for the evolution of
> > the image scikit.
>
> A while ago we discussed implementing a plugin system for image IO.
I haven't followed this discussion. What is the reason to not depend
on PIL?
Every Image Processor I know whos using python has PIL installed; even
scipy
uses it via misc.scipy.pilutil.

> We may want to do something similar for image display.  At the moment,
> I mostly use matplotlib do display images, but for faster displaying a
> QT-based GUI may be worth it.  I want us to keep dependencies at a
> minimum, so we could follow a similar route to the new opencv module:
> compile wrappers, but only load those once the library becomes
> available.
So we could add support for a set of GUI functions that are just not
available
when pyqt (or in a very near future pyside) is not available. Good for
me,
that's the python way to do things anyway.

Cheers,
Holger