heya,
if lf returns this magic error value sometimes, maybe it's just a matter of
fixing the branch that results in this special treatment? i think it should
be lf's responsibility not to randomly return inf/nan/special value.
creating nan from sqrt(-1) situations sounds like badly written code and
results in frustrating error handling workarounds in all client code..
of course we still need to fix the implicit conversion from the overlarge
value. so either that could be a simple branch on our side, testing for the
one error value, or we could use something obviously out of the domain of
definition of the input image, like -1 or width+1?
cheers,
jo
On Tue, Sep 23, 2014 at 6:55 AM, Torsten Bronger <
bron...@physik.rwth-aachen.de> wrote:
> Hallöchen!
>
> If DT wants to convert a rectilinear image to fisheye, it uses
> Lensfun's lf_modifier_apply_subpixel_geometry_distortion function.
> It generates an array of float pixel coordinates (0.0, 0.0), (1.0,
> 0.0) ... (width - 1.0, height - 1.0), and transforms them according
> to the mathematics of the projection transform.
>
> Then, DT uses dt_interpolation_compute_sample to make an
> interpolated lookup in the original sensor image -- at least I
> understand it this way.
>
> Quite often, the transformation leads to invalid values. For
> example, things like arcsin(1.5) may occur. Sometimes -- but not
> always -- Lensfun catches these cases and returns 1.6e16. (Don't
> ask me where *this* value comes from.) DT's interpolation function
> casts this into an int. Due to an implementation detail of the GCC,
> this becomes a MAXINT -- but according to the C standard, the value
> is actually undefined.
>
> By the way, the GCC converts a NaN into 0. But I can cause DT to
> segfault with NaNs, so DT doesn't handle the NaN value reliably.
>
> DT's interpolation function simply seems to clip/ignore too large
> values, which is correct behaviour. So, the whole thing mostly
> works because:
>
> 1. Mostly, LF returns 1.6e16 for invalid values.
> 2. DT converts this unchecked to int, which the GCC luckily(!)
> converts into MAXINT.
> 3. DT clips such pixel coordinates.
>
> I want to make all this
> inf-nan-zero-1.6e16-clip-implemenation-detail mess well-defined.
> How do I do this? Possibilities may be:
>
> * Check everything in LF and return a very large (but not too large)
> float value if invalid.
> * Do the maths in LF completely unchecked and let the caller (aka
> DT) check.
>
> Note that *somewhere* we *have* to check. So some sort of
> performance impact is unavoidable AFAICS.
>
> Tschö,
> Torsten.
>
> --
> Torsten Bronger Jabber ID: torsten.bron...@jabber.rwth-aachen.de
> or http://bronger-jmp.appspot.com
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> darktable-devel mailing list
> darktable-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/darktable-devel
>
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
darktable-devel mailing list
darktable-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/darktable-devel
