Boost logo

Boost :

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


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


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


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at