Difference between revisions of "Publications/duret.00.gcse"
From LRDE
| Line 9: | Line 9: | ||
| project = Olena |
| project = Olena |
||
| urllrde = 200010-NetObjectDays |
| urllrde = 200010-NetObjectDays |
||
| − | | abstract = This paper presents Olena, a toolkit for programming and designing image processing chains in which each processing is a component. But since there exist many image types (different structures such as 2D images, 3D images or graphs, as well as different value types) the platform has been designed with genericity and reusability in mind: each component is written as a generic C++ procedure, à la STL. Other libraries, such as Khoros |
+ | | abstract = This paper presents Olena, a toolkit for programming and designing image processing chains in which each processing is a component. But since there exist many image types (different structures such as 2D images, 3D images or graphs, as well as different value types) the platform has been designed with genericity and reusability in mind: each component is written as a generic C++ procedure, à la STL. Other libraries, such as Khoros have a different approach where a processing component contains an implementation for each type supported by the library. This makes code maintenance hard and prevents easy addition of new image types. Still, Olena is not only a generic component library, it shall contain additional tools such as a visual programming environment (VPE). Those tools may be programmed in a classical object-oriented fashion (using operation and inclusion polymorphism) which may seems antagonist with the generic programming paradigm used in the library. Section 2 outlines the architecture of Olena and elaborates more on the design problems resulting from the use of generic components. Section 3 presents the solution chosen to address these problems. |
| lrdeprojects = Olena |
| lrdeprojects = Olena |
||
| type = inproceedings |
| type = inproceedings |
||
| Line 36: | Line 36: | ||
been designed with genericity and reusability in mind: each |
been designed with genericity and reusability in mind: each |
||
component is written as a generic C++ procedure, \`a la |
component is written as a generic C++ procedure, \`a la |
||
| − | STL. Other libraries, such as Khoros |
+ | STL. Other libraries, such as Khoros have a different |
| − | + | approach where a processing component contains an |
|
implementation for each type supported by the library. This |
implementation for each type supported by the library. This |
||
makes code maintenance hard and prevents easy addition of |
makes code maintenance hard and prevents easy addition of |
||
new image types. Still, Olena is not only a generic |
new image types. Still, Olena is not only a generic |
||
| − | component library |
+ | component library, it shall contain additional tools such |
| − | + | as a visual programming environment (VPE). Those tools may |
|
| − | + | be programmed in a classical object-oriented fashion (using |
|
| − | + | operation and inclusion polymorphism) which may seems |
|
| − | + | antagonist with the generic programming paradigm used in |
|
| − | + | the library. Section 2 outlines the architecture of Olena |
|
| − | + | and elaborates more on the design problems resulting from |
|
| − | + | the use of generic components. Section 3 presents the |
|
solution chosen to address these problems.<nowiki>}</nowiki> |
solution chosen to address these problems.<nowiki>}</nowiki> |
||
<nowiki>}</nowiki> |
<nowiki>}</nowiki> |
||
Revision as of 10:01, 17 December 2014
- Authors
- Alexandre Duret-Lutz
- Where
- Proceedings of the 2nd International Symposium on Generative and Component-Based Software Engineering (GCSE)---Young Researchers Workshop; published in ``Net.ObjectDays2000
- Place
- Erfurt, Germany
- Type
- inproceedings
- Projects
- Olena
- Date
- 2000-10-01
Abstract
This paper presents Olena, a toolkit for programming and designing image processing chains in which each processing is a component. But since there exist many image types (different structures such as 2D images, 3D images or graphs, as well as different value types) the platform has been designed with genericity and reusability in mind: each component is written as a generic C++ procedure, à la STL. Other libraries, such as Khoros have a different approach where a processing component contains an implementation for each type supported by the library. This makes code maintenance hard and prevents easy addition of new image types. Still, Olena is not only a generic component library, it shall contain additional tools such as a visual programming environment (VPE). Those tools may be programmed in a classical object-oriented fashion (using operation and inclusion polymorphism) which may seems antagonist with the generic programming paradigm used in the library. Section 2 outlines the architecture of Olena and elaborates more on the design problems resulting from the use of generic components. Section 3 presents the solution chosen to address these problems.
Bibtex (lrde.bib)
@InProceedings{ duret.00.gcse,
author = {Alexandre Duret-Lutz},
title = {Olena: a component-based platform for image processing,
mixing generic, generative and {OO} programming},
booktitle = {Proceedings of the 2nd International Symposium on
Generative and Component-Based Software Engineering
(GCSE)---Young Researchers Workshop; published in
``Net.ObjectDays2000''},
pages = {653--659},
year = 2000,
address = {Erfurt, Germany},
month = oct,
isbn = {3-89683-932-2},
project = {Olena},
abstract = {This paper presents Olena, a toolkit for programming and
designing image processing chains in which each processing
is a component. But since there exist many image types
(different structures such as 2D images, 3D images or
graphs, as well as different value types) the platform has
been designed with genericity and reusability in mind: each
component is written as a generic C++ procedure, \`a la
STL. Other libraries, such as Khoros have a different
approach where a processing component contains an
implementation for each type supported by the library. This
makes code maintenance hard and prevents easy addition of
new image types. Still, Olena is not only a generic
component library, it shall contain additional tools such
as a visual programming environment (VPE). Those tools may
be programmed in a classical object-oriented fashion (using
operation and inclusion polymorphism) which may seems
antagonist with the generic programming paradigm used in
the library. Section 2 outlines the architecture of Olena
and elaborates more on the design problems resulting from
the use of generic components. Section 3 presents the
solution chosen to address these problems.}
}