Image/Paint libraries (OpenEXR)

[Cyrille Berger]

> I'm afraid so, too, and I really want that release.  On the other hand, the
> temptation is very great. I've been out of the loop for a month or two, and
> on coming back I find myself brimming with programming fury.
And it will be really stupid to force ourself to produce an alpha release if 
we are to make a major core modification after. I think we could set 
september as an objective for the modification of the core, and set the alpha 
release for november.

> Still, I think templates _are_ the way go, even if I'm an old Python hand
> and still have a hard time wrapping my mind around the necessity for static
> typing.
that's the reason templates exist ;)

> I think we should split the core into two layers. One a memory handler that
> is common for all images -- the current tile manager, but reworked to
> support any image format. This manager should:
There is no need to rework the tile manager : KisTileManager is not link to 
any data type.
We just have to replace every instance of QUANTUM by a template, and when we 
want to add a new color space with a certain size, we just type KisTyle<uint> 
or KisType<double> and so on.
If we use iterators, the trick is done, we can access to the pixel data of an 
image doing something like :
IteratorPixel iP = image->getIterator()

So I think that we should have something like that :
 - a KisSizeStrategy that provide a KisTile and an iterator
 - a KisColorStrategy doing the conversion stuff : toQPixmap() and fromBrush() 
(or fromPattern()...)

Example of the KisSizeStrategy architecture :
Base classes :
class KisTile
{
	public:
		uint x, y;
};
class KisSizeStrategy
{
	public:
	virtual KisTile* createNewTile() =0;
	virtual IteratorLine createIteratorLine() =0;
};
A uchar KisSizeStrategy :
class KisTileUChar : public KisTile
{
	public:
		uchar* data;
};
class KisSizeStrategyUChar
{
	public:
	virtual KisTile* createNewTile()
	{
		return new KisTileUChar();
	};
	virtual IteratorLine createIteratorLine()  { /* some implementation */ };
};

This way the KisTileMgr and all the memory manager and undo manager know only 
a KisTile !



> 	- Perhaps implement lazy loading of large images. Krita will currently
> load any image completely into the tile manager, leading to slow load times
> and high memory usage -- some image types offer data already in rectangular
> chunks.


> I don't think the memory manager needs to have knowledge of colour models,
> and it should expose the smallest possible interface for accessing data.
The current memory manager don't care about the color models, so we can keep 
it.

> And so on... But first we need to fix our tools, perhaps replace
> ImageMagick imp/exp with kimgio, push the tools into a toolbox a la Karbon,
> remove remnants of previous bright ideas that are no longer used, and all
> that. Gradients. Patterns. Selections. Having done all that, I guess we'll
> have learned enough to dive head-first into the second-system effect.
Hum, maybe I haven't well understand, but gradients, patterns, selections 
should come after we have stabilize the core.

-- 
--- Cyrille Berger ---