|
Boost : |
From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-06-25 12:32:13
>- the iterators seem somewhat restrictive. There is no way to iterate
>over lines or colums of an image (which is useful eg for filtering).
You can iterate over the rows (VIEW::x_iterator), over the columns
(VIEW::y_iterator), or over all pixels in the image (VIEW::iterator).
You can also navigate in 2D over the image (VIEW::xy_locator)
>Also, I'm not sure what would be the efficiency of implementing eg
image
>differences using iterators (for that you need to iterate over two
>similar images)...
GIL's constructs are very lightweight. For example, the x_iterator for a
simple interleaved image is a raw C pointer. It is not even wrapped in a
class, so it has zero abstraction penalty. The y_iterator consists of a
raw pointer plus an integer step - 8 bytes.
>- I'm not sure that the interleaving/alignment/structure really belongs
>in an image class. For me, it's often more an implementation detail
>related to storage.
And storage/ownership is exactly what GIL's image class is designed to
do.
The preferred way to access the pixels of an image is through an image
view (which you can get from an image). Image views don't deal with
interleaving, alignment and concrete memory structure.
>A plugin system would be great but this is certainly beyond GIL goals.
GIL extensions are the closest to what you call a "plugin system". These
are modules (such as I/O) that focus on specific domains.
Lubomir
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk