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

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2006-10-15 22:49:37

Lubomir,

Lubomir Bourdev wrote:

> Stefan Seefeld wrote:

>> * 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 ? 

As you point out in your presentation, an y-gradient can be
implemented by combining a transpose with an x-gradient.
However, due to all the cache misses performance will
suffer terribly. Therefor, if I know that I'm going to
run a number of column-wise operations (FFT's come to mind),
I may want to corner-turn my image first.
I know I can do this explicitely, but sometimes it is
good to push this into the type, and the transpose into
the type-conversion. This has better potential for optimization.

>> * 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>();

I see. Sorry I missed that !

>>   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>())"

OK.

> 
>>
>> Implementation
>> ==============

[...]

>> 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?

Right. That's very useful ! But I think there should be more
such examples, notably to show how to bind existing code / types
to GIL 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...

Right, and I agree packed pixels should become part of GIL core.
However, this argument isn't what I'm arguing for. :-)
My point is that showing how to write custom pixel types is an excellent
device to explain the design. I think I understand the relevant part of GIL
much better now simply because I was interested into how to write a (5,6,5)
Pixel type to be binary-compatible with IPP. (I could have picked an arbitrary
other type, this was really just a way to get my feed wet.)

>> The library should contain example programs to demonstrate 
>> all the individual aspects of the library.
> 
> You mean code snippets?

Code snippets would be good, but complete minimal programs would be even
better. What a better way to demonstrate an algorithm than by showing
how it transforms an input image into an output image.

Thanks,
                Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...