Re: [boost] Review of Generic Image Library (GIL) begins today, Oct5, 2006

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-10-15 22:30:56

Stefan,

Thanks for your support! 

Stefan Seefeld wrote:
> 
> I vote for GIL to be accepted into boost.
> 
> Design
> ======
> 
> * It should be possible to create row-major, as well as 
> column-major images, to
>   speed up column-based algorithms. As pixels have 'channels' 
> as well as 'semantic channels',
>   images may have 'rows' as well as 'semantic rows'.

Can't you just use transposed_view ? 

> 
> * It may be worthwhile generalizing some of the API in 
> parametrizing dimensions
>   (for example to have a 'size(axis)' method instead of 
> 'width()' / 'height()', or having

"get_dimensions(view)[n]"   returns the size along n-th dimension

If your dimensions have different types, you could use:
get_dimensions(view).template axis_value<N>();

>   a stride(axis) method returning the step size along rows 
> and columns...

The step in bytes is only applicable to memory-based image views.
For those, you could say:

"view.pixels().row_bytes()" for byte-step in y
"view.pixels().pix_bytestep()" for byte-step in x

For a generic N-dimensional memory-based image you could use the more
generic accessors:

"byte_step(view.template axis_iterator<N>())"

> 
> 
> Implementation
> ==============
> 
> I think the implementation is very clean. I have only some 
> minor points:
> 
> * The io extensions should use iostream instead of stdio 
> (i.e. std::iostreams instead of FILE *)

Good point.

> * Variable names should not start with an underscore, as such 
> names are reserved.

We will change this if there is a strong consensus. But there are other
boost libraries that do that.

> I think it would be very helpful to add sections to the 
> tutorial that describe how to introduce custom pixel and 
> image (well, locator) types. That would demonstrate the 
> reasoning behind lots of the chosen concepts.

Doesn't the Mandelbrot set example show how to introduce new
locator/image types?

As for custom pixels, perhaps even better is to make packed pixels part
of GIL. Once this is done, making custom pixel types would be needed
very rarely if at all...

> The library should contain example programs to demonstrate 
> all the individual aspects of the library.

You mean code snippets?

Thanks for your review!
Lubomir