On Sun, Nov 13, 2016 at 9:27 PM, Ulrich Pegelow <[email protected]> wrote: > Just a thought. We have encountered problems with the lens module when it > comes to tiling. Root cause are issues with the modify_roi_in() function in > lens.c. Tiling doesn't play a role here but the size of buffer that > modify_roi_in() calculates has a direct effect on processing time. > > I haven't digged into all details then but I assume that this part could be > relevant: > > // LensFun can return NAN coords, so we need to handle them carefully. > if(!isfinite(xm) || !(0 <= xm && xm < orig_w)) xm = 0; > if(!isfinite(xM) || !(1 <= xM && xM < orig_w)) xM = orig_w; > if(!isfinite(ym) || !(0 <= ym && ym < orig_h)) ym = 0; > if(!isfinite(yM) || !(1 <= yM && yM < orig_h)) yM = orig_h; > > So in effect we request the whole image buffer for input if a NAN is > detected. This is a safe fallback but it will lead to a longer processing > time. Please also note that the section > > xm = MIN(xm, bufptr[k + 0]); > xM = MAX(xM, bufptr[k + 0]); > ym = MIN(ym, bufptr[k + 1]); > yM = MAX(yM, bufptr[k + 1]); > > is not robust when it comes to NAN. If there is a NAN found in bufptr the > final output is implementation dependant. fminf() and fmaxf() would be > better alternatives.
..because we depend on the glib macros here. i would prefer our own with a well-defined ternary operator. much faster than fminf/fmaxf and the order of the arguments will determine what happens if one of them is NaN (propagate it or use the other value). nevertheless i think this is a very plausible explanation for what may be happening here.. -jo > > As a quick check the TO could check if PR #1338 has effects on the timing. > > Ulrich > > > Am 12.11.2016 um 23:01 schrieb [email protected]: >> >> >> >> On Sat, Nov 12, 2016, at 03:52, Roman Lebedev wrote: >> >>> Please try adding 2 following lines: >>> fprintf(stderr, "%s roi in %d %d %d %d\n", self->name(), roi_in->x, >>> roi_in->y, roi_in->width, roi_in->height); >>> fprintf(stderr, "%s roi out %d %d %d %d\n", self->name(), roi_out->x, >>> roi_out->y, roi_out->width, roi_out->height); >>> >>> For 2.0.x, here: >>> >>> https://github.com/darktable-org/darktable/blob/darktable-2.0.x/src/iop/denoiseprofile.c#L1384 >>> >>> And for master, here >>> >>> https://github.com/darktable-org/darktable/blob/master/src/iop/denoiseprofile.c#L1789 >>> AND here >>> https://github.com/darktable-org/darktable/blob/master/src/iop/denoiseprofile.c#L1800 >>> >>> And repeat that -d perf, zoom to 1:1 and move around. >> >> >> Logfiles attached. I just patched 2.0.7 and the release candidate, if I >> need to actually pull from current master, let me know, but it might not >> happen until after the weekend. >> > > ____________________________________________________________________________ > darktable user mailing list > to unsubscribe send a mail to [email protected] > ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
