KisIterator, quantum and pixels
boud at valdyas.org
Mon Jul 5 10:19:59 CEST 2004
On Monday 05 July 2004 08:38, Casper Boemann wrote:
I'm currently at work so I cannot give you a detailed answer about iterators
and so on, but please take time to read up on the previous discussion on this
topic on the mailing list. Personally, I'm very fond of Dr. Koethe's Vigra
library (http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/) -- and
especially his papers:
The current iterator design needs some work, true, but I first want to define
the requirements and the design a bit more before we start an implementation.
For instance, handling bit depths > 8 bit by concatenating bytes won't cut
it; there are image formats we want to support that need floats and doubles.
Assymetric pixel types are best handled by leaving some precision unused, I
feel. And then there are more complex pixel types that I really would like to
support, like those described in:
http://gamma.cs.unc.edu/impasto/Baxter-IMPaSTo_Web-NPAR04.pdf or in
http://www.levien.com/gimp/wetdream.html (readable C source).
Another requirements for a redesign of the way Krita accesses image data is to
have as small an interface as possible. I wouldn't mind having an abstract
pixel class that can be implemented for different pixel types and an
interface to the image data that's not much more than setPixel() and
getPixel() to start with. Efficiency can come later.
I would like to be able to swap backends -- the tile manager is fine for large
images and images that need to store undo information, but something simpler
would be helpful for temporary layers, paste buffers etc.
And in the end, it's the image data manager needs to support lazy loading of
But as for the iterators: it would be useful to have a set of iterators that
provide access by:
I am currently not satisfied by the lack of separation between the tile
manager and the rest of Krita.
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi
More information about the kimageshop