Image/Paint libraries (OpenEXR)

[Boudewijn Rempt]

On Tuesday 25 May 2004 18:23, Cyrille Berger wrote:

> yes but that mean we have to have find a common way to represent the image
> data. And I believe it will mean a big work in the core library, which mean
> it would be nearly impossible to release an alpha version in septembre.

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.

>
> I have understand that there are different base types (integer & float),
> whiche mean we will have to use templates.
>

Yes -- and those of different sizes, too. Curiously enough,  Photoshop doesn't 
support painting operations on 16 bit/channel images -- indicating it was an 
afterthought for them, too. And then there's colour spaces, even though not 
all colour spaces are regularly used with all bit depths. 64 bit/channel is 
mostly used for film, and then it's always rgba. Add to that special types of 
image that have to simulate wet paint, and you get a nice matrix:

channeldepth	type	colour space (no of channels)
1		float	bitmap (1)
8		uint	gray (1)
16			grayA(2)
24			rgb (3)
32			rgbA (4)
64			cmyk (4)
			cmykA (5)
			l*a*b* (3)
			XYZ (3)
			L*u*v* (3)
			duotone (?)
			indexed (?)
			multichannel (?)

(My (legal!) copy of Photoshop 5.5 currently supports 8 and 16 bits, and 
bitmap, gray, index, rgb(a), cmyk and lab. PhotoGenics 
(http://www.idruna.com/) supports 32 bits max. -- the demo is an interesting 
download, by the way.)

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.

> But first, I think we should have a close look at all the different image
> type, and then we should search for the common point between all the
> different types, and then rework the core.

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:

	- Break up images in memory chunks so the OS can swap as needed (don't see 
the need to write a swap algorithm myself if Linux has already done his best 
on one).
	- Keep undo data (but the actual history should be in another layer: this is 
just the associated image data)	
	- 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.

The memory manager should offer an efficient and easy to use way to access 
individual pixels, kernel (for convolution ops) and larger chunks of data 
(for copy, select, composite, rendering), but no actual algorithms. We should 
have a way to extend the memory manager with plugins -- that's why I'm 
currently beefing up on Adobe's plugin architecture, PICA.

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 second layer should have that knowledge, and implement the algorithms for 
painting, compositing and filtering in an extensible way. No way KisPainter 
should have to know anything about tiles...

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.
-- 
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi