[CREATE] Lens correction database

[Andrew Zabolotny]

From Sun, 13 Jan 2008 20:16:20 +0100
Pablo d'Angelo <pablo.dangelo at web.de> wrote:

> > I've finished the draft UI and now I'm implementing a system where
> > arbitrary filters can be inserted into the de-bayering chain. I'd
> > say, 50% complete.
> Sounds good. So we can correct TCA before debayering in the future?
I'm not sure, I was going to insert all correction filters after
de-bayer. The reason is that de-bayering algorithms all rely on fixed
positions of the R/G/B pixels, and shifting them, especially with
non-integer amounts, will break them completely.

I'm a little unclean here, I'll try to explain a little more. Suppose
you have some bayer image:

R11 G21 R31 G41
G12 B22 G32 B42

One possible approach for doing TCA correction is this: suppose we
should move R11 value from (0,0) to (0.5,0.3). The de-bayering algorithm
cannot work with such things, it always relies on the fixed R-G-G-B
matrix. It is (roughly speaking) something like (absolutely random
formula, but gives the idea):

G11 = (R11+B22)/4+(G21+G12)/2.66
B11 = ...

Or, if put other way around, at, say, position B22 (1,1) you need to
put the blue value from, say, (1.4, 0.6). How I can interpolate it? This
will need some top-class debayering algorithm that can operate with
arbitrary fractional coordinates, and I never heard of any such.
However, this approach seems to me more appropiate for real
implementation than the former. Perhaps one day in the future I will
come with my own debayer algorithm which can compute any color
component at arbitrary coordinates, but so far I'll just implement TCA
correction post-debayer using the second approach.

-- 
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/20080114/3a728752/attachment.pgp