CKMY craziness...

[Casper Boemann]

> 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?

I'm still here, with a very guilty consience. I'm unable to commit anything
as I don't have commit access so no need looking for that. I havn't done any
work either

> 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.

sorry I don't get it

Are you saying one internal represensation (say XYZ) and then converting for
display, compositing and painting etc. So when painting we convert the
affected pixel's XYZ value to say CMYK. Do a composit. Convert back to XYZ
and store. Then the display'er takes the XYZ. Converts it to RGB and puts it
on screen.

What I'm saying is as many internal representations as needed. However for
98% of the application it should be treated like a generic pixel, and then
only the the colorstrategy should know what is actually stored. That way
only when displaying we would need to convert from generic to RGB.

With one internal representation XYZ is the only choice to avoid gamut
problems, but you still won't be able to have exsotic colormodels where
wetness and texture of the paint is represented in the pixel. You would
loose the opputunity for that, unless you extend with these information
always (ie add it to the internal rep once and for all).


> > 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.

Hey no argument except memory consumption. A price I don't think many users
are prepared to pay.

In fact I don't want pointers like an array and indexing.

Pointers are a normal c++ tool (it is just a reference to an object)

All I want is a generic pixel. I call it class Pixel and you call it class
vector.

the colorstrategy would then handle it like a subclass say cmykPixel

The only difference is that you would add a couple of bytes to each pixel to
gain vector housekeeping.

best regards
casper

ps: will be unavailable for the the next 24 hours or more