- 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