nativeColor and endianness

[Patrick Julien]

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

I believed this to be bgra on big endian.

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

That is correct, however, pre-multiplied is important to avoid arithmetic 
operations that will slow things down when converting or when working with 
alpha channels.  Although not the case with cmyk, it's still important to use 
pre-multiplied values since pre-multiplying helps correctness, i.e. round off 
errors are eliminated.  Let's face it, if the user is continuously operating 
on his images, round off errors will add up to a lot at the end of the day.

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

Well, again, it depends on how the byte swapping is done... but if that is the 
direction you are taking, bitwise operators are the way to go, don't use a 
third 'tmp' variable, like so.

// Don't
tmp = a;
a = b;
b = tmp;

// Do
a ^= b;
b ^= a;
a ^= b;

Much faster, but still nothing compared to the speed gains offered by 
pre-multiplied values 

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

Even simpler solution would be to consider all Krita files to be little 
endian, no flags, no nothing.

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

Yes, you can, but that discussion can wait if, like you stated, ever reach 
that point.