[CREATE] Lens correction database

[Andrew Zabolotny]

From Fri, 7 Sep 2007 21:37:00 +0200
Cyrille Berger <cberger at cberger.net> wrote:

> There are two reasons why the black box wouldn't work for Krita:
>  - the blackbox works only with RGB images, that doesn't fit in Krita
> design of having filters working in the current colorspace of the
> image
Aha, good point. But maybe just the blackbox' API should be expanded to
cover these formats as well? The currently published API is just a
draft without implementation yet, so it will get expanded much.

In any case, I have exposed the internals of the models already.

>  - pixels are not stored in a big memory chunk, but in tiles (or
> possibely even more sophisticated structures), while copying from
> thoses structures to a big memory chunk is possible, it's defeating
> one of the point of having those structures
Sure, one of the things I want to avoid is imposing some specific
image-in-memory layout to client applications.

For now I mean processing image pixel by pixel, e.g. for example the
method:

void Apply (uint8 *rgb);

is meant to be called for every pixel. I see why this is quite an
expensive approach, maybe there are better ideas on a more optimal
image processing? Of course, this could be even a generic:

void Apply (float &r, float &g, float &b);

and your application would just convert the pixel back and forth
between float and native pixel format. However, I decided it would be
better to have just one pointer to three consecutive values of their
native types for performance reasons.

In any case, how would Krita apply, say, TCA correction or CCI
correction on a CMYK image? Will it convert CMYK to RGB, then apply the
channel shift/colour correction, then back to CMYK or how? Point is, all
existing lens models deals with red, green and blue, I haven't seen
lens models for other color spaces. So if there will be a back and
forth conversion, maybe a generic method like above will help.

> So I think that your blackbox covers 99% of applications out there,
> but unfortunately to please the remaining 1%, you will need to expose
> some more functions in the public API.
I want to try hard to make the library optimal for all
kinds of applications. But of course, you still can implement the
filters manually, I'll make this possible as well.

-- 
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/create/attachments/20070908/34aa25e3/attachment.pgp