[IPOL discuss] OpenCV and IPOL

Pascal Getreuer getreuer at cmla.ens-cachan.fr
Thu Aug 29 14:48:18 CEST 2013


I am sorry, I am not in favor of either OpenCV and Boost for IPOL.
Having used them both extensively, I know well that these are very
useful and expertly designed libraries, but their goals are
incompatible with IPOL's.

# OpenCV

OpenCV is a collection of image-processing-related libraries, with
functions particularly for reading/writing images and videos,
morphology and other low-level image processing, key points extraction
(SIFT, SURF, ORB, etc.), and linear algebra---all of which is aimed at
easy prototyping of computer vision research. It was started by Intel,
growing out of the IPL library, and the core image routines are very
well optimized.

Like Nicolas said, OpenCV's API isn't that stable, it changed in v2.4
(http://upstream-tracker.org/versions/opencv.html). It is worth noting
that much of OpenCV is actually done via other libraries, e.g., FFTs
are performed with libfftw, linear algebra is done with Lapack,
HighGui uses libpng to open PNG and video I/O is with FFmpeg (on
Linux) or VFW (on Windows). So for those operations, we might as well
use those libraries directly. Also, OpenCV is much too large to
reasonably include it as submission support code.

In my experience, OpenCV's video I/O is the low-point of the library.
OpenCV doesn't use FFmpeg quite right, the seek and related functions
are imprecise, and OpenCV crashes easily if there are errors in the
video data. Using FFmpeg directly is much more robust. Furthermore,
because of the two different backends, these sorts of problems are
platform dependent.

For video, I would recommend to consider FFmpeg, but unfortunately
FFmpeg's API is also undergoing a lot of change. So instead, I suggest
that video on IPOL is done as a directory of images or with the
PNM-like "QNM" format.


# Boost

Boost has a deliberately unstable API. This is kind of the point,
since the Boost libraries are used as testing ground for future the
standard C++ libraries. Boost is too large to reasonably include the
libraries' source as support code with the submission. I do not think
this is compatible with IPOL.

Please note that Boost is a collection of libraries, not a single
library, and some being very practical while others are more like
experiments of contorting the C++ language. If Boost is considered in
any way (e.g. with BCP), it may be more useful to discuss these
libraries in detail.


Just my two cents.

Best,
Pascal


On Wed, Aug 28, 2013 at 4:15 AM, Nicolas Limare
<nicolas.limare at cmla.ens-cachan.fr> wrote:
> Hi,
>
>> Thanks to all for the replies, I would like to ask if OpenCV could be
>> proposed as an accepted dependency by IPOL, since it is a widely used
>> library in the field of image processing.
>
> First, I am not an OpenCV user, so everything I write may be wrong and
> could need to be corrected (and I'd be glad to be corrected).
>
> The problem with OpenCV is the API stability. Version 1 was released
> in 2006, version 2 in 2009, and code written for OpenCV 1.x could not
> be compiled with OpenCV 2.x. Since OpenCV i.x is not maintained
> anymore, not even distributed, if IPOL had accepted code depending on
> OpenCV in 2009 it would be broken today and this would defeat the
> purposes of IPOL (if the code is broken, you can't verify, reuse
> and/or compare it).
>
> The OpenCV project management has changed in 2009 and again in 2012,
> and I find nowhere on the project website a statement that they value
> to have some API stability. In these conditions it seems risky to
> accept in IPOL some code using OpenCV and expecting the library to be
> availavble on the system.
>
>> The code to be submitted also depends on GSL and BOOST, but these can be
>> included on the package to be submitted.
>
> Why couldn't you include the OpenCV code as well?
>
> PS: All that is in the context of the current IPOL software
> restrictions. A relaxed policy has been proposed at the Treilles
> meeting, but I think we are not yet at the point where this can become
> the main IPOL policy.
>
> --
> Nicolas LIMARE
> http://nicolas.limare.net/                         pgp:0xFA423F4F
>
> --
> IPOL - Image Processing On Line   - http://ipol.im/
>
> contact     edit at ipol.im          - http://www.ipol.im/meta/contact/
> news+feeds  twitter @IPOL_journal - http://www.ipol.im/meta/feeds/
> announces   announce at list.ipol.im - http://tools.ipol.im/mm/announce/
> discussions discuss at list.ipol.im  - http://tools.ipol.im/mm/discuss/
>



-- 
Pascal Getreuer
CMLA, ENS Cachan
getreuer at cmla.ens-cachan.fr
www.getreuer.info


More information about the discuss mailing list