Difference between revisions of "Publications/duret.00.gcse"

From LRDE

 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{{Publication
 
{{Publication
  +
| published = true
 
| date = 2000-10-01
 
| date = 2000-10-01
 
| authors = Alexandre Duret-Lutz
 
| authors = Alexandre Duret-Lutz
 
| title = Olena: a component-based platform for image processingmixing generic, generative and OO programming
 
| title = Olena: a component-based platform for image processingmixing 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''
+
| booktitle = Proceedings of the 2nd International Symposium on Generative and Component-Based Software Engineering (GCSE)—Young Researchers Workshop; published in “Net.ObjectDays2000”
 
| pages = 653 to 659
 
| pages = 653 to 659
 
| address = Erfurt, Germany
 
| address = Erfurt, Germany
| project = Olena
 
| 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 [Kon94] 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 [Jaz95], 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
 
| 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.
 
| type = inproceedings
 
| type = inproceedings
 
| id = duret.00.gcse
 
| id = duret.00.gcse
Line 27: Line 26:
 
month = oct,
 
month = oct,
 
isbn = <nowiki>{</nowiki>3-89683-932-2<nowiki>}</nowiki>,
 
isbn = <nowiki>{</nowiki>3-89683-932-2<nowiki>}</nowiki>,
project = <nowiki>{</nowiki>Olena<nowiki>}</nowiki>,
 
 
abstract = <nowiki>{</nowiki>This paper presents Olena, a toolkit for programming and
 
abstract = <nowiki>{</nowiki>This paper presents Olena, a toolkit for programming and
 
designing image processing chains in which each processing
 
designing image processing chains in which each processing
Line 35: Line 33:
 
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 [Kon94] have a
+
STL. Other libraries, such as Khoros have a different
different approach where a processing component contains an
+
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 [Jaz95], it shall contain additional
+
component library, it shall contain additional tools such
tools such as a visual programming environment (VPE). Those
+
as a visual programming environment (VPE). Those tools may
tools may be programmed in a classical object-oriented
+
be programmed in a classical object-oriented fashion (using
fashion (using operation and inclusion polymorphism) which
+
operation and inclusion polymorphism) which may seems
may seems antagonist with the generic programming paradigm
+
antagonist with the generic programming paradigm used in
used in the library. Section 2 outlines the architecture of
+
the library. Section 2 outlines the architecture of Olena
Olena and elaborates more on the design problems resulting
+
and elaborates more on the design problems resulting from
from the use of generic components. Section 3 presents the
+
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>
lrdeprojects = <nowiki>{</nowiki>Olena<nowiki>}</nowiki>
 
 
<nowiki>}</nowiki>
 
<nowiki>}</nowiki>
   

Latest revision as of 16:21, 5 January 2018

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},
  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.}
}