There are many contributors to this project.
The current team is:
- permanent staff:
- Ph.D. Students:
- Nicolas Boutry
- Edwin Carlinet
- CSI students:
- Antony Seure
- Nicolas Allain
- Antoine Lecubin
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'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 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 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)