[CREATE] Lens correction database

[Øyvind Kolås]

On 9/9/07, Andrew Zabolotny <zap at homelink.ru> wrote:
> That's why I have a per-pixel function. It returns you the distorted
> coordinates and you do with them what you need.
>
> The coordinate transform itself is not a easy task (especially for the
> PTLens distortion model) so I expect the cost of the computations to be
> much higher than the overhead of the call.

I think it would make sense to be able to compute horizontal and
vertical floating point displacement maps for tiles/entire buffers.
For multiple images in a set the displacement buffers could be reused.
The only issue I see with this is that for some very severe
distortions
the center of the displaced coordinates is not enough if the resulting
transformation involves
significant downscaling, this is probably not a concern for most uses though.

> Sure, this could be set up as a complex process with callbacks like
> "get me the pixel from there" and so on, but I think this is way too
> complex to be universal and effective.

If you want to support all kinds of pixel formats, including alpha,
you need to take premultipled / non premultiplied alpha into account
as well, since treating each component
the same on non-premultiplied (normal) RGBA data, leads to color
mixing artifacts.

> Also, what formats Krita uses? uint8, uint16, maybe float? I would like
> to cover all possible pixel formats.

To speak for GEGL, it currently uses the following data types for
storing pixel data through
the use of babl (http://gegl.org/babl/), the list is currently
exhaustive but babl is dynamically
extendable with more formats.

64bit float, 32bit float, u8 (normal 8bit), u8-luma (used in some
YCbCr formats, differing from normal RGB 8bit), u8-chroma (used for
CbCr in YCbCr/YUV formats), u16, u32, CIE u8 L (CIE Lab's own version
of 8bit, for the luminance), CIE u8 ab (CIE Lab's own version of 8bit
for the chroma components), CIE u16 L (for 16bit,..), CIE u16 ab.

I think it makes sense to provide the coordinate
transformation/displacement map methods for generic use. As well as
some convenience functionality for linear buffers of 8bit/16bit/32bit
floating point RGB.

/Øyvind K.
-- 
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/