CKMY craziness...

[Saem Ghani]

Thanks for the forward

> Date: Wed, 17 Nov 2004 20:34:49 +0100
> From: Boudewijn Rempt <boud at valdyas.org>
> Subject: Re: CKMY craziness...
> To: "For developers of Krayon \(previously known as KImageShop\)"
> 	<kimageshop at kde.org>
> Message-ID: <200411172034.52576.boud at valdyas.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Wednesday 17 November 2004 20:32, Saem Ghani wrote:
> > I've been hacking away at the code, trying to figure out why CKMY is
> > borked. I'm still basically no where with it, but I think I have some
> > idea where some of the issues might be comming from.  But they're hard to
> > track down, thanks to QUANTUM*.  I'm fairly certain that there is spill
> > over and the wrong values are being effected.
>
> Quite probably; another source of problems might be my old caching
> conversion table.

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.

> > So I'm voting for a refactoring of QUANTUM* to std::vector<QUANTUM>.  I'm
> > going for the STL version instead of QVector, simply because the STL
> > version supports arithmetic and a few other features which will reduce
> > the amount of work for this particularly refactoring job.
>
> Moving to vector is not something simple to do: Krita uses those pointers
> to quantums everywhere. There was some discussion about using vectors vs.
> using pointers to quantums some time ago; the more-or-less decision was to
> go on using pointers to bytes, where in the future a single channel could
> occupy one or more bytes and would be interpreted by the colour channel.

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.

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.

> Casper Boemann was going to experiment with that idea and I setup a cvs
> branch for him, but I haven't heard anything about it since then.
>

Well if he doesn't reply to this thread, could you see the commit statistics 
to see if there has been any work done?

> If you want to convert all use of QUANTUM* to vector<QUANTUM> you need to
> take the following into consideration:
>
> * Do your vectors contain just the channels for one pixel, or do they
> contain the channels for all pixels one might feed to a colour strategy.

I'm wondering if we should be bothering with formats internally in terms of 
editting -- my personal opinion at this time is no.  Yes, there are some 
obvious performance hits that I can see, but at the same time, i think they 
might be worth it.  Besides, that's what math libraries and profilers are 
there for.

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.

> * How does this integrated with the iterators Cyrille is working on?

Honestly, I'm ignorant here.

> * Can you still efficiently copy whole blocks of pixels, or are we going to
> always work with one pixel at a time?

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

> And probably lots more things; I'm not against using vectors instead of
> pointers (as I said in previous discussions -- I dislike pointers with all
> the vehemence of a Python hacker), but if we use vectors I think we should
> take the opportunity to get rid of the QUANTUM definition and move to a
> situation where a channel can be one or more bytes, with the colour
> strategy interpreting the bytes as integers, bytes or even floats.

I agree whole heartedly.  Floats provide some interesting opportunities for 
wide ranges and potential speed improvements, thanks to SSE, SSE II and 
3DNow!, assuming the math libraries are present.

> In short -- this calls for a moment of reflection, design & a patch we can
> discuss :-).

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

> > Additionally, I was
> > really surprised at the lack of refactoring features in KDevelop, but
> > refactoring in C++ is a PAIN!
>
> As far as I know there is no good C++ refactoring tool available (there's
> one that integrates with (X)Emacs, but its commercial in the first place,
> and not that powerful in the second place). Not even Eclipse has decent
> refactoring support. I believe that refactoring C++ is considered a hard
> problem...

Yes, C++'s loose nature lends to that.