From kde-kimageshop  Sat Oct 18 14:50:55 2003
From: Boudewijn Rempt <boud () valdyas ! org>
Date: Sat, 18 Oct 2003 14:50:55 +0000
To: kde-kimageshop
Subject: Re: nativeColor and endianness
X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=106648875115170
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============2093524755=="


--===============2093524755==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	micalg=pgp-sha1; boundary="Boundary-02=_SNVk/oP9YuB7Djz";
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


--Boundary-02=_SNVk/oP9YuB7Djz
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

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=20
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 model=
s:=20
rgb(a), cmyk, xyz. This is useful, because people seem to want to work on=20
just the red channel, or the black channel, or because it's easier to mix=20
some colours in one model than in another. (Note: there is no other model=20
implemented than native rgba, and everything connected with channels doesn'=
t=20
work, not even with rgba.)

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

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

Only when using the rgba model internally no conversion is needed, and Krit=
a=20
is fast. If the rgba result of a particular cmyk tuple were precomputed, we=
=20
could use a LUT and that would speed things up, but there's no way around=20
looping through the entire image/visible portion/changed rect to render the=
=20
cmyk image to rgba. (Note: all those conversion formulas are at=20
http://www.easyrgb.com/. Note 2: there appears to be a cmyk-based JPEG file=
=20
format, too. Note 3: I should check cmyk with my old copy of photoshop for=
=20
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 da=
ta=20
to big-endian display, for instance on my old powerbook. Which is a slow=20
beast and couldn't take the strain, perhaps. (But I should test that, perha=
ps=20
it's not so bad. No real conversion formula's needed, just byte-swapping, a=
nd=20
that's from Kernighan & Ritchie.)

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

=46or the moment, I'm more concerned with correctness of display on both ix=
86=20
and powerpc -- but I will probably need, if I ever get to that point, a way=
=20
of handling colour that works like pigments in paint. And I wonder whether=
=20
the system of storing image data and rendering that to the screen could be=
=20
extended by having extra data, like wetness, amount of material and height =
of=20
surface for that pixel.
=2D-=20
Boudewijn Rempt | http://www.valdyas.org/index2.html

--Boundary-02=_SNVk/oP9YuB7Djz
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQA/kVNSdaCcgCmN5d8RAhCpAKCGdI7SYafQQV6hqLHYXnusw74tYgCfX1Ph
x8jo7QXRvOXqfRYd9A9bkOA=
=IX2X
-----END PGP SIGNATURE-----

--Boundary-02=_SNVk/oP9YuB7Djz--


--===============2093524755==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
kimageshop mailing list
kimageshop@mail.kde.org
http://mail.kde.org/mailman/listinfo/kimageshop

--===============2093524755==--