This is a working document. It list the places where pixels are mangled and requested functions to do it in an colorstrategy independent way

The purpose is to find out which functions an API in colorstrategy must have to support pixelmangling in a colorstretegy independent manner.

====================
Requested functions:

a function that take X number of pixels and associated weights and produce a weighted average.



====================
Usecases:

plugins/convolutionfilters:
---------------------
The plugin creates matrices for each of the color channels. That would
be wrong.  A single matrix would be enough telling how to mix the colors.
Another matrix telling how to mix the alpha is ok though.

core/kis_convolution_painter.cc:
---------------------
The convolution painter assume that we know how to mix several colors into one. That won't hold for hsv and lab, and is slightly inaccurate for the other colorstrategies as well.


core/builder/kis_image_magick_builder.cc:
---------------------
(this file will be moved to a plugin soon)
The builder is hardcoded to rgba because it needs to convert between ImageMagick
pixel packets and Krita pixels. Currently the code is like:

	KisHLineIteratorPixel hiter = layer -> createHLineIterator(0, y, image->columns, true);
	while(! hiter.isDone())
	{
		Q_UINT8 *ptr= hiter.rawData();
		// XXX: not colorstrategy and bitdepth independent
		*(ptr++) = pp->blue;
		*(ptr++) = pp->green;
		*(ptr++) = pp->red;
		*(ptr++) = OPACITY_OPAQUE - pp->opacity;

		pp++;
		hiter++;
	}

The traditional way of solving in Krita would be to add a toImageMagickImage
and fromImageMagick method analogous to the toQImage and fromQImage methods,
or to add nativeColor and toPixelPacket methods -- but this is not extensible,
for instance when we want to support openExr.




====================
Requested function:

a function that take 2 colours, and calculates the 'distance' or 'difference' between it.


====================
Usecases:

core/kis_fill_painter.cc:
---------------------

The fill painter needs to know if a pixel doesn't vary too much from the seed pixel.
Currently it calculates this in an RGB-only way, by taking the difference of the channels
of the 2 points.

------------------------------
It is quite often necessary to blank a pixel The color strategy should have a function
to return a blank pixel. Ditto with a default pixel.
