oddkiva / sara

Easy-to-Use C++ Computer Vision Library

Sara: C++ Computer Vision Library

Sara (सार) is a Sanskrit word meaning essence.

Sara tries to focus on:

1. having an easy-to-use and simple API;
2. having easy-to-understand and efficient implementations of computer vision algorithms;

Sara is licensed with the Mozilla Public License version 2.0.

Documentation

You can find the API documentation here.

I also compile my personal notes here where I write down my understanding regarding the mathematical details to explain how I implement some algorithms.

In any case, you are always better off consulting the examples folder and the test folder.

Why yet another library?

Like a few people out there, I never really liked OpenCV. I use it out of necessity but I don't really like it.

The two aspects below are always in my mind everytime I write code for this library:

1. as a computer vision scientist, understanding as many algorithms as possible and as deeply as possible is one of my responsibilities .
2. I also try to write clear and efficient code.

This is a library made out of love and I try to reflect this mindset as honestly as possible.

Build the libraries

Please have a look at the CI scripts like .gitlab-ci.yml or .github/workflows/ci.yml.

If something does not work, help me and try fixing it? =P

sara's Issues

MAINT: continue adding tests for `Geometry` module.

Code coverage decreased significantly as there is a lot of code in this module.

[MAINT] Test `Geometry` module

Focus is on 2D geometry only.

Urgent TODO list:

• Restructure unit tests.
• [ ] Debug ellipse intersections (investigate numerical accuracy issue): WON'T FIX: no time. I still have not figured out how to solve it...
• Ramer-Peucker-Douglas
• Generate documentation even if incomplete
• More rigorous unit tests

[MAINT] Create unit and functional tests for `Graphics` module.

This is a big and nontrivial task:

• unit tests for PaintingWindow.
• unit tests for OpenGLWindow.
  • partial (only keyboard events) because not trivial.
• unit tests for GraphicsView.
  • partial (only keyboard events), ticket #63 are following up from this.
• unit tests for keyboard/mouse events.
• functional tests for keyboard/mouse input events.
• functional tests for drawing commands.

Remaining tasks are:

• [ ] unit tests for UserThread.
• [ ] unit tests for GraphicsApplication.
• functional tests for graphics view.
• [ ] functional tests for 3D viewing.

MAINT: test `FeatureDescription` module.

[FIX] Fixed main issues regarding CI with Travis.

TODO list:

• Needs to solve dependencies with Qt5 in .travis.yml
• Update documentation by showing Travis build status

[BUG] Hessian function

I was wondering if division by "4" is really required here:
https://github.com/DO-CV/DO-CV/blob/master/src/DO/ImageProcessing/Differential.hpp#L215

in SIFT paper for example they do not divide XX/YY by "4"

[ENH] Set up code coverage.

Warning: this works in Linux and not for Mac OS X and Windows.

• Set adequate compilation flags for code coverage (only in Debug mode)
• Setup coverage report generation.
• [ ] lcov (not needed.)
• [ ] integration with coveralls.io (Postponed.)

[MAINT] Write unit tests for `DO::GraphicsView`.

As the title says.

[MAINT] `Timer` unit test is not portable.

It works fine under windows but with *nix systems, in particular when Travis runs unit test.

[MAINT] Write unit tests for `DO::OpenGLWindow`.

As the title says.

[MAINT] Reorganize project source tree

Longer description: TODO

[MAINT] Add unit tests for functions in "Subimage.hpp"

As the title says. This issue arises from PR #102.

[MAINT] Separate image I/O from drawing functionalities

This concerns the reorganization of folder src/DO/ImageDrawing.

[MAINT] Write more robust unit tests for `Color.hpp`

As the title says.

[MAINT] Test Features module.

Because there is a lot of changes. Adding unit tests and fixing compilation issues become necessary.

[ENH] Implement packed pixel data structure.

Yes, there is boost.gil but f*ck it. The library is a hassle to use.

MAINT: test `FeatureMatching` module.

[MAINT] Test `KDTree` module.

As the title says.

[MAINT] Resolve compiler warnings due to deprecated GLU functions in Mac OS X.

As the title says.

MAINT: test `FeatureDetection` module.

TODO: (en vrac)

• Make more rigorous unit tests,
• Double-check the affine shape adaptation algorithm,
• Double-check the automatic scale selection of detected features based on the Laplacian operator.

Restructure the list of tasks.

[MAINT] Reorganize the 'Core' module.

This issue has arisen from PR #102.

Break down the header files in the 'Core' module into smaller header files. The header files are quite monolithic as most of the time, many template classes are defined in a header file.

For example, break down the following header files:

• UseDOCore.cmake: simplify the implementation, cf PR #102.
• Image.hpp: WIP cf. PR #109
• MultiArray.hpp: cf. PR #107
• ArrayIterators.hpp: cf. PR #111

[MAINT] Separate benchmarks and unit tests in `ImageProcessing`.

As the title says.

• Unit tests are taken care by issue #127.
• Benchmarks can be done more thoroughly later. For now let us just clean the existing source code.

[ENH] Make clear distinction between sample programs and unit tests

This it particularly true for the DO.Graphics module.

[ENH] Setup coverage report with Coveralls.io?

How easy is to do that?

[MAINT] Add and clean unit tests for `ImageProcessing`.

Tests are needed for:

• Deriche: cf. PR #123
• Determinant: WIP cf. PR #130
• Differential: cf. PR #129
• Gaussian pyramid: cf. PR #145 but better unit tests are needed.
• Extremum localization: cf PR #131.
• ImagePyramid: cf. PR #133
• Interpolation: cf. PR #123
• Linear Filtering: WIP cf. PR #124
• Local extrema: cf. PR #131
• Norm: cf. PR #135
• Orientation cf. PR #136
• Scaling: cf PR #144
• Second moment matrix: cf. PR #137
• Warp: cf PR. #146

[MAINT] Unit tests for `DO.Core.Tree`.

As the title says.

[MAINT] Add testing for mouse-based navigation in `OpenGLWindow`

TODO:

• Tests for the trackball.
• Tests for mouse move events.
• Tests for mouse wheel events.

[MAINT] Write functional tests for painting commands.

As the title says.

[MAINT] Add testing for interactivity in `GraphicsView`.

Tasks to be described later.

[ENH] More color space conversion

Add color space conversion:

• CIE Lab
• CIE XYZ

[DESIGN] Simple and lightweight geometry kernel

Questions are:

• Would it be relevant to add a simple geometry kernel?
• If yes, logical design?
• Design Cartesian and homogeneous kernels?

[FIX] C++ 11 compilation

My compilation error is the following :
I think it is due to a not complete installation of c++ 4.8 and gcc 4.8

[ 98%] Building CXX object test/MatchPropagation/src/CMakeFiles/DO_Region.dir/Region.cpp.o
In file included from /usr/include/c++/4.7/chrono:35:0,
                 from /home/yohann/Documents/GitRepo/DO-CV/src/DO/Core/Timer.hpp:18,
                 from /home/yohann/Documents/GitRepo/DO-CV/src/DO/Core.hpp:37,
                 from /home/yohann/Documents/GitRepo/DO-CV/src/DO/Features.hpp:17,
                 from /home/yohann/Documents/GitRepo/DO-CV/src/DO/Match.hpp:15,
                 from /home/yohann/Documents/GitRepo/DO-CV/test/MatchPropagation/src/Region.hpp:14,
                 from /home/yohann/Documents/GitRepo/DO-CV/test/MatchPropagation/src/Region.cpp:11:
/usr/include/c++/4.7/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
In file included from /home/yohann/Documents/GitRepo/DO-CV/src/DO/Core.hpp:37:0,
                 from /home/yohann/Documents/GitRepo/DO-CV/src/DO/Features.hpp:17,
                 from /home/yohann/Documents/GitRepo/DO-CV/src/DO/Match.hpp:15,
                 from /home/yohann/Documents/GitRepo/DO-CV/test/MatchPropagation/src/Region.hpp:14,
                 from /home/yohann/Documents/GitRepo/DO-CV/test/MatchPropagation/src/Region.cpp:11:
/home/yohann/Documents/GitRepo/DO-CV/src/DO/Core/Timer.hpp:39:5: error: ‘chrono’ in namespace ‘std’ does not name a type
/home/yohann/Documents/GitRepo/DO-CV/src/DO/Core/Timer.hpp:41:5: error: ‘chrono’ in namespace ‘std’ does not name a type
make[2]: *** [test/MatchPropagation/src/CMakeFiles/DO_Region.dir/Region.cpp.o] Error 1
make[1]: *** [test/MatchPropagation/src/CMakeFiles/DO_Region.dir/all] Error 2
make: *** [all] Error 2

[MAINT] Moving code to C++11

This issue is about looking DO-CV's future.

Recent compilers are getting more and more C++11-compliant. Very soon, C++11 will be supported widely. Thus, the question is to alleviate existing parts of the code by using some C++11 features at the expense of much more limited backward compatibility with older compilers.

Supported compilers would be only:

• VC 10.0 and above (shipped in Visual Studio 2010 and above) in recent MS Windows platforms,
• Clang 5.0 (shipped with Xcode) in Mac OS X 10.9 and recent Linux distributions,
• GCC 4.8 available in recent Linux distributions.
  However, they are easily available and widespread in the public domain.

The benefits are that the code would be:

• more readable, more elegant and easier-to-maintain (in particular lambda functions, auto feature, smart pointers like std::unique_ptr)
• increased performance (move semantics)
• reduces the need of adding dependencies with third-party libraries (TinyThread++ and Boost (for shared_pointer)
• less self-cooked template meta-programming classes (static_assert)
• optimized and well-implemented random number generation
  And so on.

Use subtrees for third-party libraries

git submodule: die, die, die!!!

[MAINT] Write functional tests for keyboard/mouse events.

As the title says.

[MAINT] Improve unit testing of Gaussian pyramid computation.

See if we can clean the code as well.

[FIX] set correct compilation flags for Release, Debug.

The generated programs are running very slow in *nix based system if we try to build them via command line.

(@ySalaun: basically the idea would be to do something like in: https://github.com/pablofdezalc/akaze/blob/master/src/CMakeLists.txt#L21)

Not all compilation flags are relevant and we probably want to do something like:
SET(CMAKE_CXX_FLAGS_RELEASE "-O3 -Wall -fPIC -ffast-math")

As a starting point, I would put this line in the file https://github.com/DO-CV/DO-CV/blob/master/CMakeLists.txt.

Then run:
cmake -DCMAKE_BUILD_TYPE=Release ..

[ENH] Improve performance of the assignment operator of the 'MultiArray' class

The current implementation may not be optimal. Investigate.

[MAINT] Revamp Pixel class?

The template class DO::Color is not satisfactory. It needs review and needs to be a bit more generic:

• Rename DO::Color class as DO::Pixel
• [ ] Decouple the pixel order and the color layout
• Think about designing about easy to use Pixel class for every pixel format (packed pixel with different number of bits in each channel)

Some color conversion are not available from some source color space and to target color space.

[MAINT] Write unit tests for `DO::PaintingWindow`.

As the title says.

[MAINT] Check implementation of feature detectors.

• Make more rigorous unit tests,
• Double-check the affine shape adaptation algorithm,
• Double-check the automatic scale selection of detected features based on the Laplacian operator.

MAINT: Multi-OS CI with travis.

Travis seems to support multi-OS CI (Linux and Mac OS X).

[MAINT] Unit tests for `Core/Subimage.hpp`

As the title says.

[MAINT] Remove gmock from third-party software.

It turns out google-mock is not really needed to test the Graphics module. It is unfortunate that the history will be a bit bloated...

[MAINT] Write more robust unit tests for N-D iterators of `MultiArray`.

As the title says.

[MAINT] Create and use the develop branch.

Since the library is undergoing some breaking changes in the master branch, we now need to having a develop branch, which should give much more freedom when we do important structural changes in the codebase.

Every PR must now be made out of the develop branch. Once the develop branch has reached a milestone, changes in the develop branch will be merged into the master branch.

[DOC] Update documentation and more explicit source code examples

Missing documentation in the following modules:

• Features
• FeatureDetectors
• Match
• FeatureMatching

Source code examples are needed in each module: unit tests should not be source code examples.

• Graphics

[MAINT] CI with AppVeyor for Windows platfoms.

Investigate. See if chocolatey package manager makes it easy.

[MAINT] Minimize the use of template files in CMake files.

For one thing the template file FindDO.cmake.in is becoming annoying and may hinder the continuous integration.

[MAINT] Disable compiler warnings in third-party software.

As the title says.