There are many contributors to this project.

The current team is:

A full list, including people who worked on this project, is available here.

We also host:


1999: Starting point of this project

The main objectives for an image processing library were defined: being generic and efficient at the same time. Practically we wanted to be able to run an algorithm on different image structures, with different kinds of data (pixel values). Furthermore, we imagined that it could be possible for every algorithm to selectively process parts of image data. For instance, one component of an image containing vectors or a region of interest in an image. The key issue was how not to duplicate an algorithm implementation while dealing with those different cases.

2000–2001: First experimentations

At that time, the genericity techniques in C++ (use of the template keyword in C++ and related software engineering considerations) were rather new to us. Our first experimentations were the opportunity to learn a lot about the generic programming paradigm in the context of an object-oriented language. We also sketched the way we still use of manipulating images: having points, point sets, writing ima(p) to access a pixel value, for_all(p) to browse points, etc.

2001–2004: Towards a first workable library

During three years we worked on the first draft of an actual library. There were values types (quantized gray-level types, color types, etc.), different image structures (1D, 2D, and 3D), a collection of algorithms, and many auxiliary tools (traits and so on). Most of all, it really looked like a library and it was fully effective (we used it to develop image solutions for industrial companies). Unfortunately we were stuck to a design that did not allow to get all the power that genericity can offer. At that point, we realized that we needed the notions of "morphers" and of "properties".

2004–2007: Finding an acceptable solution

To meet our expectations, we started a prototype using a paradigm mixing the benefits of classical object-oriented programming and generic programming. Yet there was too much sophisticated code (meta-programs) and it then became a heavy burden: compilation times were way too long and maintaining the image hierarchy design was too complicated. Nevertheless we also brought to the fore many useful solutions during those years that are integrated in the current version of the library.

2007–2009: The current version

Mid-2007 we decided to swap to a very light programming paradigm. First the library core was written and features of the former versions have been progressively re-incorporated. Since then, we find the new design fully satisfactory (so there is no reason to change it again nor to make it evolve). The library got stable mid-2008 and a beta version was released in December 2008.


At this time, the Olena platform is involved in the SCRIBO project of the Free Software Thematic Group, part of the "System@tic Paris-Région Cluster" (France). This project is partially funded by the French Government, its economic development agencies, and by the Paris-Région institutions.


Olena is Free Software released under the GNU General Public License (GPL) version 2.

Olena's headers start with the following notice:

This file is part of Olena.

Olena is free software: you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation, version 2 of the License.

Olena is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
General Public License for more details.

You should have received a copy of the GNU General Public License
along with Olena.  If not, see <http://www.gnu.org/licenses/>.

Most Milena and Swilena headers have the following additional clause:

As a special exception, you may use this file as part of a free
software project without restriction.  Specifically, if other files
instantiate templates or use macros or inline functions from this
file, or you compile this file and link it with other files to produce
an executable, this file does not by itself cause the resulting
executable to be covered by the GNU General Public License.  This
exception does not however invalidate any other reasons why the
executable file might be covered by the GNU General Public License.


(C) 2007­-­2014 EPITA Research and Development Laboratory (LRDE)