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>())"
>> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk