From kde-kimageshop  Sat Oct 22 18:47:23 2005
From: Boudewijn Rempt <boud () valdyas ! org>
Date: Sat, 22 Oct 2005 18:47:23 +0000
To: kde-kimageshop
Subject: Re: How to achive colorspace independence
Message-Id: <200510222047.23944.boud () valdyas ! org>
X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=113000684523854
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============0122004330=="

--===============0122004330==
Content-Type: multipart/signed;
  boundary="nextPart1192476.Wz6I5faVXd";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1192476.Wz6I5faVXd
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 21 October 2005 21:58, Casper Boemann wrote:

> 1) Single pixel adjustments, like changing brightness. Each pixel can be
> modified on each own. The best way here is to let the cs do the work. I
> have made a framework wher you allocate an KisAdjustment from the
> colorspace, and the method that applies that adjustment to a range of
> pixels. Plain and simple and by allocating first we reuse some data
> avoiding overhead.

This sounds like a generic way of doing things, but this also demands that =
the=20
colorspace has a function that knows how to create the basic adjustment and=
=20
knows what to do with the adjustment, and the filter must know how to fill=
=20
the adjustment with parameters -- i.e, all of the filter except for the=20
iterator is in the colorspace -- right?

> 2) Scaling and other things where each resulting pixel is the weigthed
> mixture of a number of pixels. The mixColors function in the cs does this
> rather well.

I never thought of scaling as a filter, but it's true, of course. Is mixCol=
ors=20
natively implemented in all cs's -- or do we have fallback to 16 bit lab or=
=20
xyz? Should check...

No, we're still falling back on QColor here. This is one thing we will need=
=20
to fix before the release, since it means that a simple scaling will transf=
orm=20
a 16 bit image to essentially an 8 bit image.

> 3) Drawing kind. Simply copying the pixels or using the composite ops to
> merge them

Yes, that works very nicely, and uses Adrian's scheme to tell the outside=20
world which kinds of compositing the cs supports; we may want to copy this=
=20
for the other type functions that may not be completely implemented in all=
=20
colorspaces.

> 4) Complex filter. If the filter needs to modify the channels and need
> access to more than one pixel at a time, then it's best to convert to XYZ
> since it's the biggest gamut cs we have and most algos that work on rgb
> would work on xyz too. There is however a large overhead in converting to
> and from so please make sure it is needed.

Note that it should be 16 bit XYZ: that colorspace is easily accessible fro=
m=20
the colorspacefactory registry.

> NO-NOs are using the data like it is a color component (say like red).
> Apart from the fact that you don't know if it is 8bit, 16bit or float or
> whatever, you also don't know if it is a color component or a polar coord
> like hue, or something even weirder.

Another no-no (except for very decorative filters, like dropshadow or=20
oilpaint) is silently converting the pixels to rgb, applying the algorithm=
=20
and then converting back.

> In short : don't do anything to the data: let the colorspace do it - OR
> transform to XYZ or Lab and do the work there

Yes.

=2D-=20
Boudewijn Rempt=20
http://www.valdyas.org/fading/index.cgi

--nextPart1192476.Wz6I5faVXd
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDWok7daCcgCmN5d8RAgiJAKDU50sn+4YH/UHkWtcpE5HZhkLOCgCguR4l
vyfElkTBFJucxijUnYa0h5c=
=7LxN
-----END PGP SIGNATURE-----

--nextPart1192476.Wz6I5faVXd--

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

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

--===============0122004330==--