nativeColor and endianness

[Boudewijn Rempt]

On Saturday 18 October 2003 16:23, Patrick Julien wrote:

> Yes, that was the point, but the thing is, unless you've got those values
> pre-multiplied, rendering even a small image is going to be slow.  This is
> basically what I was explaining on this list before.

I think I didn't get it then -- and perhaps I don't get it now, either. Let's 
see how far my understanding reaches by jotting down what I _think_ I know:

Krita is supposed to be able to handle natively images in many colour models: 
rgb(a), cmyk, xyz. This is useful, because people seem to want to work on 
just the red channel, or the black channel, or because it's easier to mix 
some colours in one model than in another. (Note: there is no other model 
implemented than native rgba, and everything connected with channels doesn't 
work, not even with rgba.)

Then there is the display side, which is decoupled from the way the data is 
actually stored: here the cmyk/rgba/xyz are rendered in an rgba model which 
can be displayed. Powerbooks want the bytes ordered abgr, ix86 rgba. 

The definitions of PIXEL_RED etc. are used both by the colour models and the 
operations on the internal Krita data, and by the system that renders the 
image for display.

Only when using the rgba model internally no conversion is needed, and Krita 
is fast. If the rgba result of a particular cmyk tuple were precomputed, we 
could use a LUT and that would speed things up, but there's no way around 
looping through the entire image/visible portion/changed rect to render the 
cmyk image to rgba. (Note: all those conversion formulas are at 
http://www.easyrgb.com/. Note 2: there appears to be a cmyk-based JPEG file 
format, too. Note 3: I should check cmyk with my old copy of photoshop for 
the powerpc. See what it does, and whether it's slower than rgba.)

This looping would also be needed to convert from little-endian internal data 
to big-endian display, for instance on my old powerbook. Which is a slow 
beast and couldn't take the strain, perhaps. (But I should test that, perhaps 
it's not so bad. No real conversion formula's needed, just byte-swapping, and 
that's from Kernighan & Ritchie.)

On a side-note: it works quite well, after all, to set PIXEL_RED etc. to the 
byteorder of the current machine. Images imported and exported with Krita on 
a powerbook are usable on ix86; however, Krita files show up with the wrong 
endianness. A simple, but perhaps wrong, solution would be to add an 
endianness flag to krita's fileformat and check that when reading a file, and 
to add a compile-time flag that checks for endianness in kis_global, to 
select the right rgba byteorder. Note: investigate whether autoconf already 
sets such a flag.

For the moment, I'm more concerned with correctness of display on both ix86 
and powerpc -- but I will probably need, if I ever get to that point, a way 
of handling colour that works like pigments in paint. And I wonder whether 
the system of storing image data and rendering that to the screen could be 
extended by having extra data, like wetness, amount of material and height of 
surface for that pixel.
-- 
Boudewijn Rempt | http://www.valdyas.org/index2.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20031018/30f930f3/attachment.bin