From Tue, 11 Sep 2007 14:59:28 +0200 "Øyvind Kolås" <[EMAIL PROTECTED]> wrote:
> I think it would make sense to be able to compute horizontal and > vertical floating point displacement maps for tiles/entire buffers. Good idea. I'll change the interface a little to support computing distortion in large chunks as well as applying RGB corrections over them. > 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. Can't understand this. Do you mean there are lenses that have several centers of distortions? > 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. Ugh, wouldn't it be enough if the library would be able to skip the alpha channel data? Do you want to say that every plugin for gimp 3.x will have to deal with all this stuff independently? > > 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/) So basically I see here RGB8, RGB16, RGB32, RGB-FP32 and RGB-FP64. The chroma, luma, lab and all kinds of funny color spaces are not of particular interest to lensfun because all lens models deal with RGB colors, as I stated earlier. -- Andrew
signature.asc
Description: PGP signature
_______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
