Hallöchen! I don't know whether you read the list, so I CC'ed you.
Stéphane Gimenez writes: > Hi, > >>> [...] Unfortunately the corrections that are computed by >>> lensfun contain "fuzziness" (they are kind of non-continuous due >>> to big rounding errors), [...] >> >> Could you elaborate on that? What is the source of those >> rounding errors? > > Here is an example of the distorsion values that are returned from > lensfun (without TCA) for contiguous pixels: > > x,y=0,3271 pr=78.314850,3219.129150 pg=78.314850,3219.085693 > x,y=0,3272 pr=78.114517,3220.230225 pg=78.114517,3220.135010 > x,y=0,3273 pr=77.991783,3221.279785 pg=77.991783,3221.235840 > x,y=0,3274 pr=78.102600,3222.174561 pg=78.102600,3222.130615 > x,y=0,3275 pr=78.213219,3223.069336 pg=78.213219,3223.180176 > x,y=0,3276 pr=78.324234,3223.963867 pg=78.324234,3224.074707 > x,y=0,3277 pr=78.201881,3225.013672 pg=78.201881,3224.969482 > x,y=0,3278 pr=78.079147,3226.063477 pg=78.079147,3226.019043 > x,y=0,3279 pr=78.189957,3226.958008 pg=78.189957,3226.913574 > > They indicate where to pick up red and green values in the input > for an output pixel (x,y). The x component should be > almost-constant or at least monotone so the rounding error is > about 0.3. Dunno where it comes from yet. You have to set the "component roles" of the pixels properly, see http://lensfun.sourceforge.net/manual/group__Correction.html#gaf7c5a3f809c2245211b9f50797b718b3 In your configuration, Lensfun assumes R,G,B tripletts, thus you see discontinuities after every three values. If the image is already demosaiced, this makes sense, because then, Lensfun assumes the same x,y coordinates for every colour component. But in your case, you have to set the component roles to something more simple, maybe LF_CR_1(LF_CR_INTENSITY). But I've never used that, so you have to figure out the details yourself. > They use Newton's method but I already tried to increase the > iteration count. Newton's method is only used for the reverse (i.e. *creating* TCA). For the correction of TCA, Lensfun simply computes a polynomial. > >> > [...] >> > >> > The general idea for the fitting hasn't changed, but you should >> > notice improvements because the method for the evaluation of color >> > shifts has changed. The fitting is now computed based on better >> > estimations, with proper weighting. For example, a large >> > pseudo-uniform blue sky does not have a bad influence on shift >> > estimations. >> >> Does this mean you could use your method to create an improved >> stand-alone tca_correct? > > I'm working on that now. Assuming the shifts are radial is a > probably a reasonable assumption in many cases. Nice! I don'tlike tca_correct very much. However, it should be possible -- at least as an option -- to use Lensfun't model for the fitting, see <http://lensfun.sourceforge.net/calibration-tutorial/lens-tca.html>. >>> About the fitting itself, the applied red and blue color shift >>> are resolved as 2-dimensional polynomials of degree 4 >>> (hard-coded but can be modified in the source). That is, a sum >>> of x^n*y^m components with n + m <= 4. >> >> Is it really necessary to take non-radial components into >> account? From my experience with distortion, I can hardly >> imagine this. > > I think correcting small motion trails (including camera's > shaking) or variations in scene's depth may require non-radial > components. For the camera, motion blur or a static colour gradient are indistinguishable. Only after entering the lens, TCA is produced. So, motion blur does not affect TCA, not even the perceived TCA. > Some pictures taken with perfectly standard lenses seem to need > it. Do you have model names for me? Or maybe upload a RAW at <http://wilson.bronger.org/calibration>? >> Me too. I hope that I convince the devs some day to reduce the >> two TCA sliders to one. > > How would you determine the ratio between the two then, if you > don't rely on automatic methods? Profile based? I would set the ratio to one. In my experience with approx. 50 lenses (multiplied by 5 zoom settings), this is reasonable. But there will always be someone crying about a feature taken away from them, so I have little hope. ;-) Tschö, Torsten. -- Torsten Bronger Jabber ID: [email protected] or http://bronger-jmp.appspot.com ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ darktable-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-devel
