boud at valdyas.org
Tue Mar 16 20:08:31 CET 2004
On Tuesday 16 March 2004 18:47, Adrian Page wrote:
> That sounds like a reasonable idea. The alternative is to use the tile
> manager's read/WritePixelData to move the data around, which would be a big
> improvement too. The overheads involved with setting one pixel at a time is
> what's really killing computeDab.
Whichever would be easier & faster... I'm betting on a simple data structure
for small bits of images, but perhaps we need to explore both alternatives,
and then choose whichever is best.
> I see that as a good thing, because it's clear we can improve that a great
> deal with relatively little effort. Those are the best kind of
> bottlenecks. :-)
Hah, yes -- but it also means that I messed up when I coded this bit of
glacial code up first...
> It's quite a simple change, especially if we're going to turn CMYK into
> RGBA before compositing, as mentioned in the alpha plan. Exactly how alpha
> interacts with non-RGB colour spaces and compositing is a bit unclear, or
> at least, requires some thought.
It was meant to elicit some discussion. The advantages of rendering each layer
to rgba before layer compositing are clear: it means you can basically
combine anything with anything, if needs be even, eventually, karbon layers
or whatever. The disadvantage is that I'm not sure what combining, say, cmyk,
in rgba space is going to compared to combining as cmyk.
> However, once we're in RGBA land, it's
> easy going. I don't see any problem with doing this before the alpha, and I
> would suggest it be done before any more of the compositing functions are
> fixed, as they're simpler in premultiplied form. I'll happily volunteer to
> do this. :-)
Ah -- then there's not much choice, is there -- whoever codes the code gets to
call the tune.
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi
More information about the kimageshop