[boost] GIL remarks from boost-users

From: David Abrahams (dave_at_[hidden])
Date: 2006-10-09 10:02:56

I'm just forwarding these here.  I've told Johan he should post on
this list if he wants his remarks seen.


Subject: Topics
MIME-Version: 1.0

Topics:
   Re: [boost] Review of Generic Image Library (GIL)
   Re: [boost] Review of Generic Image Library (GIL)

Date: Sat, 7 Oct 2006 17:43:09 +0200
From: "Johan Oudinet" <johan.oudinet_at_[hidden]>
Subject: Re: [boost] Review of Generic Image Library (GIL)
        begins today, Oct5, 2006
Message-ID: <25a18d050610070843t2d63ab1dxa1955c66695ddc4b_at_[hidden]>
References: <F92E45E2-31F4-43A3-A0A0-79AB6E9292D9_at_[hidden]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 10/5/06, Tom Brinkman <reportbase_at_[hidden]> wrote:
> The review of Generic Image Library (GIL) begins today,
> October 5, 2006, and continues through October 15, 2006.
>
> Please download the library at: http://opensource.adobe.com/gil.
> Minor change are being made regularly (daily), so check the site
> often for
> updates.
>
> I highly recommend viewing the 55 minute Breeze
> presentation describing the library at:
> http://opensource.adobe.com/gil/presentation/index.htm
>
> A tutorial is available at:
> http://opensource.adobe.com/gil/gil_tutorial.pdf
>
> A design guide is availage at:
> http://opensource.adobe.com/gil/gil_design_guide.pdf
>
> Description:
>
> The Generic Image Library (GIL) is a C++ library that abstracts
> the image representation from operations on images. It allows
> for writing the image processing algorithm once and having it
> work for images in any color space, channel depth and pixel
> organization, or even synthetic images, without compromising
> the performance. GIL has an extension mechanism that allows
> for adding extra functionality. Two extensions are currently
> provided =E2=80=93 one for image I/O and one for handling images
> whose properties are specified at run-time.
>

I think you might look at the Olena project:
http://olena.lrde.epita.fr

*** Overview of the Olena library ***

The Olena project aims at building a scientific computation platform
oriented towards image processing, image recognition, and artificial
vision. This environment is composed of a high performance generic
library, a set of tools for shell scripts, together with, in the more
distant future, an interpreter (a la Octave, MatLab etc.) and a visual
programming environment.

Each step includes its own difficulties and requires the invention of
new solutions. For instance, the library --the low level service set
on top of which is built the whole project-- shall be both fast and
generic. These objectives are quite antagonist in programming.
Fortunately, the scientific computation field recently realized that
genericity, as found in object oriented languages, is no longer a tool
useful to implement auxiliary classes, but constitutes a new
programming paradigm in its own right. Contrary to the usual oject
oriented modelizations with inheritance and dynamic polymorphism,
(static) genericity enables the generation of performant and reusable
code. The Olena library is written using this paradigm.

We have already found effective solutions to delicate problems, such
as the wide variety of data types and data structures expected to be
offered by such a library. In addition, we have generalized these
solutions as design patterns to be reused in similar conditions.

Olena is also effective for us to perform research on image processing.

*** Library features ***

The C++ library provides:

    * Generic basic image types (1-D, 2-D, 3-D images, etc.)
    * Mophers: generic, composable and lighweight objects built on one
or several images, that can be used as
          o mixins: a morpher can add extra data (e.g. a neighborhood)
or operations (e.g., an ordering on the values) to an image;
          o adaptors: e.g., a slice morpher can be used to view a
slice of a 3-D image (spacemap) as a 2-D image (bitmap);
          o modifiers: a morpher can add a mask to an image, to
restrict its (iterable) domain;
          o lazy function applications: a morpher can present a image
seen through a function, either bijective or not;
          o etc.
    * Generic image processing algorithms
    * Auxiliary tools, necessary to write generic algorithms:
          o topologies;
          o points, delta-points;
          o neighborhoods;
          o etc.

Regards,
--=20
Johan

Date: Mon, 9 Oct 2006 01:17:21 +0000 (UTC)
From: Thorsten Behrens <th.behrens_at_[hidden]>
Subject: Re: [boost] Review of Generic Image Library (GIL)
        begins today, Oct5, 2006
Message-ID: <loom.20061009T020259-668_at_[hidden]>
References: <F92E45E2-31F4-43A3-A0A0-79AB6E9292D9_at_[hidden]>
        <25a18d050610070843t2d63ab1dxa1955c66695ddc4b_at_[hidden]>
MIME-Version: 1.0

Johan Oudinet <johan.oudinet <at> gmail.com> writes:

> On 10/5/06, Tom Brinkman <reportbase <at> gmail.com> wrote:
> > The review of Generic Image Library (GIL) begins today,
> > October 5, 2006, and continues through October 15, 2006.
> >
> > Please download the library at: http://opensource.adobe.com/gil.
> > Minor change are being made regularly (daily), so check the site
> > often for
> > updates.
> >
> > [snip]
> 
> I think you might look at the Olena project:
> http://olena.lrde.epita.fr
> 
Right. And maybe also Vigra's
(http://kogs-www.informatik.uni-hamburg.de/koethe/vigra) accessor concept and
type promotion traits might deserve a second glance.

Pixel accessors make explicit what's worked-around by GIL's
PixelDereferenceAdaptor, namely that getting to the place where the pixel is
stored and operating on the content of that in-memory representation are
orthogonal concepts. Vigra algorithms take a pair of pixel iterators and
accessors for source and destination. Thus, to be able to work on a 565 packed
RGB pixel type, one can reuse the int16 pixel iterator, and provide a 565 pixel
accessor. Very easy, very clean.

When it comes to image processing algorithms (I know that this is currently kind
of a weak spot for GIL - but ultimately, of how much use is this lib without at
least some basic processing functionality), I'd love to see promotion traits
used. Otherwise, supporting mixed types (float and int, etc) for color channels
generically would become rather hard...

Cheers,

-- Thorsten


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com