We have a problem in the LensFun project that also affects Hugin. The coordinate system used for distortion and TCA correction is poorly designed, namely, r=1 is half-height. By contrast for vignetting, r=1 is half-diagonal. This is much better.
Why? Because the crop factor also refers to the diagonal. This way, the aspect ratio of the image doesn't matter. Contrete example of the problem: Sigma produces a given lens for different mounts. LensFun contains calibration data, which somebody created on their FT camera (Panasonic, Olympus). So, aspect ratio of the calibration pictures was 4:3. Now, somebody with a Nikon owns this Sigma lens, too. Aspect ratio 3:2. LensFun scales the coordinates by the ratio of the crop factors. But this only works if the aspect ratios are the same! If this is not the case, the error in the scaling is sqrt((ar1^2 + 1)/(ar2^2 + 1)). ar1,2 are the two aspect ratios. There are many ways to solve this in LensFun. 1. Leave it this way. After all, the error should occur seldomly, and most cameras have 3:2. Moreover, we would not have to crawl through all compact cameras to find out which use 4:3. Maybe 4:3 will become exinct some day anyway. 2. Convert all crop factors to an effective crop factor of a 3:2 sensor with the same height. However, crop factors in LensFun are also used to determine which calibrations are eligible. For 4:3 images, this means that the part of the image circle that they cover would be over-estimated (because they would appear to be wider than they actually were). The new crop factors would be simply wrong (although calibration would work). 3. Introduce a new <aspect-ratio> tag in LensFun. 4. Convert the a, b, c coefficients for non-3:2 data to be correct for 3:2 images. For polynomial models, this conversion is lossless except for rounding errors. What would this mean for Hugin? 1. Using calibration data for an image with different aspect ratio would not work. Well, it does not work currently either. 2. Hugin would have to adjust the crop factor for non-3:2 images and pass this effective crop factor to LensFun's routines. 3. Hugin would have to make use of the AspectRatio attribute and the aspect ratio of the image to scale the r values. 4. Hugin would have to use the aspect ratio of the image to scale the r values. For 3:2 images, the scaling factor would be 1. What do you think, what is the way to go? I personally prefer (4) because it has the least impact on LensFun and its using programs, while delivering correct results in all cases. In particular for 3:2 images with 3:2 calibration data, nothing would change (the by far most frequent case). -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/90fbf3ff-ac4a-4a00-9ffc-ddd9f622f60f%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
