Am 2015-02-25 21:37, schrieb Torsten Bronger: > Currently, Lensfun returns a very big float for undefined values,
Lensfun should not just simply return a very big float for any undefined values. For example y=1/x should return MAX_FLT for x -> 0, but y = tan(x)/x should return 1 for x -> 0. So these are two completely different cases and both are mathematically well defined and should be handled accordingly. > which happens to be mapped in Darktable and DigiKam (and possibly > also in other programms) to (int)MAX_FLT, which is undefined > according to the C/C++ standard and mapped to MAXINT by the GCC. > This is then clipped by the interpolation routine. > > Thus, this approach is fragile, albeit Lensfun is not the only to be > blamed. Still, Lensfun should return something that can be safely 1. Indeed, if someone casts a float to an integer without range checking this is not the fault of lensfun. The API doc clearly defines that we return float values and it is common knowledge that it is not guaranteed that you can safely cast a float to int. 2. The calling application has to interpolate the returned float coordinate to a regular pixel grid. And afterwards its has to clip all coordinates to the maximum image dimensions. This has to be done anyway, so it does not make sense to clip a float to a huge integer in lensfun and then clip again to the image dimensions in e.g. Darktable. That's my point of view :) Sebastian ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Lensfun-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lensfun-users
