CKMY craziness...

[Boudewijn Rempt]

On Saturday 20 November 2004 04:10, Saem Ghani wrote:

> I presume you mean the CLUT (Colour look up table that's in with all the
> CMYK business?).  If that's the case, that seemed unused enough.  Though, I
> might have missed it.

Oh, I might already have disabled before; it's not a bad idea, because it 
should save a lot of time, but it never completely worked. I did the cmyk 
color space to 'get into' Krita hacking. At that time, Patrick Julien had 
factored out the colour strategies but there was only one implementation of 
the interface, and find the best way to get into a codebase is to implement 
interfaces (and refactor existing code).


> I've been giving the entire thing a lot of thought.  AFAICS, this is how it
> breaks down.  There is a display format (RGB), an intermediate format (Our
> own, RGB, HLS...) and storage/user formats (RGB, RGBA, CMYK, et al).  The
> user ones are basically out of our control and so is the display.  The only
> thing left for us to figure out is the intermediate.  Being as that is the
> case, we can either have it completely different (one that serves our needs
> and that alone) or match it with either the display or the storage/user
> format.  An elegant design might state that we have our own memory based
> representation so it simplifies a lot of things, for instance, writing
> plugins and stuff is much easier since everything is written for our
> internal format.  Mind you, this thinking process has been completely
> removed of the realities of Krita.

That's the way Photoshop works: everything is internally stored as 8 or 16 bit 
sRGB. It's not a suitable strategy for Krita because I want to have more fun 
with colour models -- there are ways of working with pixels that don't easily 
map onto any colour model but need information about other physical 
properties like wetness, thickness or pigment composition.

My first goal with Krita is to have the basis up and running: a working 
application with all the conveniences (layers, tools, cut & paste, interface 
stuff done. Then, I want to build on that to go more in the direction of an 
application like Corel Painter (which is in its IX version really good if 
crashy), because that's what interests me. For that, we need more flexibility 
than you'd need if you were working on a photoshop clone.

> As for using bytes and having them repinterpretted, that doesn't make sense
> to me, at least.  Why not simply define a pixel as a collection of channels
> for an internal representation, work in there and only do translations to
> other formats on an as needed basis?
>
> Then again, maybe I'm missing something vital.

The basic point is that the colour model doesn't store the pixels; it 
interprets them. There is one component that stores the data for all colour 
models -- the paint device with the underlying tiles. This is, conceptually, 
a raster of pixels, where a pixel is defined by the number of bytes a colour 
model needs to represent a pixel.

> Now, if we don't go with one internal data representation, then we make a
> pixel interface and have cmykPixel, rgbPixel... inherit from it, if you get
> what I'm saying.

Not completely, I think. In many use-cases, filter code doesn't need to know 
which channel is what, just the number of channels, and then iterate through 
the channels of a pixel. For that, you don't need a pixel class, just 
information the colour strategy can provide.

> One internal data representation affords us a fair number of avenues for
> performance optimizations, this being one of them.

There is one internal datarepresention, hidden by the paint device class 
(which needs a cleanup and overhaul -- it still exposes the internal data 
structure, the tile manager to the outside world, and worse, that's necessary 
in some cases). The actual data is interpreted by the colour models. This 
model looks a little like Java2D's architecture, but is a little less 
complicated and overdesigned.

> Yup, because AFAICS, this means some serious changes and there is no point
> in wasting this opportunity and short changing ourselves.

In the meantime, we need to get Krita feature-complete and stable for 
inclusion in KOffice 1.4, so all experimental work can go on the autolayers 
branch (although I should probably recreate that branch because nothing 
happened on it, and Krita has improved quite noticably since I created it.

-- 
Boudewijn Rempt | "Geef mij maar zuurtjes."
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20041120/2e2effae/attachment.pgp