Re: [darktable-user] darktable 2.2.0 rc0 released
On Sun, Nov 13, 2016 at 11:27 AM, Ulrich Pegelow 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. This is plausible, but i made those changes in e20f6f1389ff28445255249ee8f051527cd99f1a and that commit exists in 2.0.x too, so this is not the reason as to why master is slower than 2.0.x > 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 junkyardspar...@yepmail.net: >> >> >> >> 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 darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] darktable 2.2.0 rc0 released
On Sun, Nov 13, 2016 at 9:27 PM, Ulrich Pegelow 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 junkyardspar...@yepmail.net: >> >> >> >> 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 darktable-user+unsubscr...@lists.darktable.org > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] darktable 2.2.0 rc0 released
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. 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 junkyardspar...@yepmail.net: 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 darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] darktable 2.2.0 rc0 released
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. -- jys darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org[dev] took 0.401 secs (0.390 CPU) to load the image. [dev] took 0.396 secs (0.385 CPU) to load the image. [export] creating pixelpipe took 0.140 secs (0.261 CPU) [dev_pixelpipe] took 0.000 secs (0.000 CPU) initing base buffer [thumbnail] [dev_pixelpipe] took 0.003 secs (0.004 CPU) processed `raw black/white point' on CPU, blended on CPU [thumbnail] [dev_pixelpipe] took 0.004 secs (0.004 CPU) processed `white balance' on CPU, blended on CPU [thumbnail] [dev_pixelpipe] took 0.002 secs (0.003 CPU) processed `highlight reconstruction' on CPU, blended on CPU [thumbnail] denoise (profiled) roi in 0 0 597 447 denoise (profiled) roi out 0 0 597 447 [dev_pixelpipe] took 0.101 secs (0.157 CPU) processed `denoise (profiled)' on CPU, blended on CPU [thumbnail] [dev_pixelpipe] took 0.120 secs (0.220 CPU) processed `lens correction' on CPU, blended on CPU [thumbnail] [dev_pixelpipe] took 0.011 secs (0.016 CPU) processed `input color profile' on CPU, blended on CPU [thumbnail] [dev] took 0.000 secs (-0.000 CPU) to load the image. [dev_pixelpipe] took 0.020 secs (0.031 CPU) processed `output color profile' on CPU, blended on CPU [thumbnail] [dev_pixelpipe] took 0.003 secs (0.004 CPU) processed `gamma' on CPU, blended on CPU [thumbnail] [dev_process_thumbnail] pixel pipeline processing took 0.274 secs (0.458 CPU) [export] creating pixelpipe took 0.140 secs (0.192 CPU) [dev_pixelpipe] took 0.009 secs (0.017 CPU) initing base buffer [thumbnail] [dev_pixelpipe] took 0.000 secs (-0.000 CPU) processed `raw black/white point' on CPU, blended on CPU [thumbnail] [dev_pixelpipe] took 0.000 secs (-0.000 CPU) processed `white balance' on CPU, blended on CPU [thumbnail] [dev_pixelpipe] took 0.000 secs (0.001 CPU) processed `highlight reconstruction' on CPU, blended on CPU [thumbnail] denoise (profiled) roi in 0 0 146 110 denoise (profiled) roi out 0 0 146 110 [dev_pixelpipe] took 0.003 secs (0.005 CPU) processed `denoise (profiled)' on CPU, blended on CPU [thumbnail] [dev_pixelpipe] took 0.005 secs (0.009 CPU) processed `lens correction' on CPU, blended on CPU [thumbnail] [dev_pixelpipe] took 0.000 secs (0.001 CPU) processed `input color profile' on CPU, blended on CPU [thumbnail] [dev_pixelpipe] took 0.001 secs (0.001 CPU) processed `output color profile' on CPU, blended on CPU [thumbnail] [dev_pixelpipe] took 0.000 secs (-0.000 CPU) processed `gamma' on CPU, blended on CPU [thumbnail] [dev_process_thumbnail] pixel pipeline processing took 0.020 secs (0.035 CPU) [dev] took 0.000 secs (0.000 CPU) to load the image. [dev] took 0.000 secs (-0.000 CPU) to load the image. [dev_pixelpipe] took 0.021 secs (0.019 CPU) initing base buffer [full] [dev_pixelpipe] took 0.019 secs (0.019 CPU) processed `raw black/white point' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.023 secs (0.023 CPU) processed `white balance' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.022 secs (0.024 CPU) processed `highlight reconstruction' on CPU, blended on CPU [full] [dev_pixelpipe] took 1.004 secs (1.759 CPU) processed `demosaic' on CPU, blended on CPU [full] denoise (profiled) roi in 0 0 748 561 denoise (profiled) roi out 0 0 748 561 [dev_pixelpipe] took 0.151 secs (0.289 CPU) processed `denoise (profiled)' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.118 secs (0.228 CPU) processed `lens correction' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.009 secs (0.017 CPU) processed `input color profile' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.021 secs (0.031 CPU) processed `output color profile' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.003 secs (0.003 CPU) processed `gamma' on CPU, blended on CPU [full] [dev_process_image] pixel pipeline processing took 1.403 secs (2.430 CPU) [dev_pixelpipe] took 0.000 secs (0.000 CPU) initing base buffer [preview] [dev_pixelpipe] took 0.003 secs (0.003 CPU) processed `raw black/white point' on CPU, blended on C
Re: [darktable-user] darktable 2.2.0 rc0 released
On Sat, Nov 12, 2016 at 2:08 AM, wrote: > > > On Fri, Nov 11, 2016, at 13:55, Roman Lebedev wrote: > >> Hm, so the speed decrease is for the full pipe, which is for main darkroom >> view. >> I expected to see a problem in preview pipe. >> >> How did you get darktable? > > Built on Slackware64 14.2, with the same build options I've been using for > latest releases: > > cmake \ > -DCMAKE_C_FLAGS:STRING=-O2 -fPIC \ > -DCMAKE_CXX_FLAGS:STRING=-O2 -fPIC\ > -DOPENJPEG_LIBRARY="/usr/lib64/libopenmj2.so" \ > -DOPENJPEG_INCLUDE_DIR="/usr/include/openmj2-2.1" \ > -DDONT_USE_INTERNAL_LUA=Off \ > -DUSE_LIBSECRET=On \ > -DUSE_GNOME_KEYRING=Off \ > -DBINARY_PACKAGE_BUILD=1 \ > -DCMAKE_BUILD_TYPE=Release .. > > > >> What does this say (for 2.2.0rc0): >> $ grep codepath ~/.config/darktable/darktablerc > > codepaths/openmp_simd=false > codepaths/sse2=true > >> Also, please show me whole darktable output when you just start it and >> then close it, without any -d options. > There is none. Good, i suppose. > I'd be willing to build a debug version if that would help. Debug build will not help. 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. > -- > jys Roman. darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] darktable 2.2.0 rc0 released
On Fri, Nov 11, 2016, at 13:55, Roman Lebedev wrote: > Hm, so the speed decrease is for the full pipe, which is for main darkroom > view. > I expected to see a problem in preview pipe. > > How did you get darktable? Built on Slackware64 14.2, with the same build options I've been using for latest releases: cmake \ -DCMAKE_C_FLAGS:STRING=-O2 -fPIC \ -DCMAKE_CXX_FLAGS:STRING=-O2 -fPIC\ -DOPENJPEG_LIBRARY="/usr/lib64/libopenmj2.so" \ -DOPENJPEG_INCLUDE_DIR="/usr/include/openmj2-2.1" \ -DDONT_USE_INTERNAL_LUA=Off \ -DUSE_LIBSECRET=On \ -DUSE_GNOME_KEYRING=Off \ -DBINARY_PACKAGE_BUILD=1 \ -DCMAKE_BUILD_TYPE=Release .. > What does this say (for 2.2.0rc0): > $ grep codepath ~/.config/darktable/darktablerc codepaths/openmp_simd=false codepaths/sse2=true > Also, please show me whole darktable output when you just start it and > then close it, without any -d options. There is none. I'd be willing to build a debug version if that would help. -- jys darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] darktable 2.2.0 rc0 released
On Sat, Nov 12, 2016 at 12:39 AM, wrote: > > > On Fri, Nov 11, 2016, at 06:23, Roman Lebedev wrote: > >> I would make a educated guess that at some point the darkroom caches, >> which usually are there and make darkroom fast, are invalidated for >> valid reasons, so darktable has to re-run the whole pipe, and not just >> one module. >> And as you can guess, the total pipe processing time is more than just the >> time >> of one of the modules... > > Ok, to illustrate how extreme the difference is, here's the perf data for > doing the exact same thing in 2.0.7 and 2.2~rc0, essentially having only lens > correction and denoise in the history stack while moving the viewed section > of 1:1 image around to random spots via the thumbnail. Same file, same > settings (other than anything that the new version changes when importing > settings from an older version), no OpenCL. The last entry for the 2.2 log > was an astonishing 49 seconds! That was an outlier, but there were several > between 20-30 seconds, and even the shortest times were notably slower than > the fairly consistent and short ones in 2.0.7. If this isn't a bug, it's > probably unlikely to be considered an enhancement by most users. ;) Hm, so the speed decrease is for the full pipe, which is for main darkroom view. I expected to see a problem in preview pipe. How did you get darktable? What does this say (for 2.2.0rc0): $ grep codepath ~/.config/darktable/darktablerc Also, please show me whole darktable output when you just start it and then close it, without any -d options. > -- > jys Roman. darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] darktable 2.2.0 rc0 released
On Fri, Nov 11, 2016, at 06:23, Roman Lebedev wrote: > I would make a educated guess that at some point the darkroom caches, > which usually are there and make darkroom fast, are invalidated for > valid reasons, so darktable has to re-run the whole pipe, and not just > one module. > And as you can guess, the total pipe processing time is more than just the > time > of one of the modules... Ok, to illustrate how extreme the difference is, here's the perf data for doing the exact same thing in 2.0.7 and 2.2~rc0, essentially having only lens correction and denoise in the history stack while moving the viewed section of 1:1 image around to random spots via the thumbnail. Same file, same settings (other than anything that the new version changes when importing settings from an older version), no OpenCL. The last entry for the 2.2 log was an astonishing 49 seconds! That was an outlier, but there were several between 20-30 seconds, and even the shortest times were notably slower than the fairly consistent and short ones in 2.0.7. If this isn't a bug, it's probably unlikely to be considered an enhancement by most users. ;) -- jys darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org[dev] took 1.043 secs (0.279 CPU) to load the image. [dev_pixelpipe] took 0.001 secs (0.001 CPU) initing base buffer [full] [dev_pixelpipe] took 0.001 secs (0.001 CPU) processed `raw black/white point' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.001 secs (0.001 CPU) processed `white balance' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.001 secs (0.002 CPU) processed `highlight reconstruction' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.017 secs (0.031 CPU) processed `demosaic' on CPU, blended on CPU [full] [dev_pixelpipe] took 2.182 secs (4.092 CPU) processed `denoise (profiled)' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.195 secs (0.368 CPU) processed `lens correction' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.014 secs (0.028 CPU) processed `input color profile' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.020 secs (0.037 CPU) processed `output color profile' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.004 secs (0.008 CPU) processed `gamma' on CPU, blended on CPU [full] [dev_process_image] pixel pipeline processing took 2.455 secs (4.602 CPU) [dev] took 0.000 secs (0.000 CPU) to load the image. [dev_pixelpipe] took 0.001 secs (0.001 CPU) initing base buffer [full] [dev_pixelpipe] took 0.001 secs (0.001 CPU) processed `raw black/white point' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.002 secs (0.002 CPU) processed `white balance' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.002 secs (0.001 CPU) processed `highlight reconstruction' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.025 secs (0.033 CPU) processed `demosaic' on CPU, blended on CPU [full] [dev_pixelpipe] took 2.099 secs (4.048 CPU) processed `denoise (profiled)' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.195 secs (0.369 CPU) processed `lens correction' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.014 secs (0.028 CPU) processed `input color profile' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.019 secs (0.036 CPU) processed `output color profile' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.004 secs (0.008 CPU) processed `gamma' on CPU, blended on CPU [full] [dev_process_image] pixel pipeline processing took 2.383 secs (4.562 CPU) [dev] took 0.000 secs (0.000 CPU) to load the image. [dev_process_image] pixel pipeline processing took 0.000 secs (0.000 CPU) [dev] took 0.000 secs (-0.000 CPU) to load the image. [dev_pixelpipe] took 0.001 secs (0.002 CPU) initing base buffer [full] [dev_pixelpipe] took 0.001 secs (0.001 CPU) processed `raw black/white point' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.001 secs (0.001 CPU) processed `white balance' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.001 secs (0.002 CPU) processed `highlight reconstruction' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.028 secs (0.047 CPU) processed `demosaic' on CPU, blended on CPU [full] [dev_pixelpipe] took 2.228 secs (4.211 CPU) processed `denoise (profiled)' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.191 secs (0.367 CPU) processed `lens correction' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.015 secs (0.029 CPU) processed `input color profile' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.018 secs (0.035 CPU) processed `output color profile' on CPU, blended on CPU [full] [dev_pixelpipe] took 0.004 secs (0.007 CPU) processed `gamma' on CPU, blended on CPU [full] [dev_process_image] pixel pipeline processing took 2.509 secs (4.736 CPU) [dev] took 0.000 secs (-0.000 CPU) to load the image. [dev_pixelpipe] took 0.001 secs (0.001 CPU) initing base buffer [full] [dev_pixelpipe] took 0.001 secs (0.0
Re: [darktable-user] darktable 2.2.0 rc0 released
On Fri, Nov 11, 2016 at 4:49 PM, wrote: > > > On Fri, Nov 11, 2016, at 01:40, Roman Lebedev wrote: > >> I doubt that is a bug. Especially profiled denoise is quite CPU-hungry. > > Thanks. I'm well aware that the denoise is computationally expensive (and > rarely have it enabled while editing). What I don't understand is why, > occasionally, the rendering time is many times more than the sum of the time > for either lens correction *or* profiled denoise, when both are enabled. > Explain like I'm five? :) I would look at the darktable -d perf output. I would make a educated guess that at some point the darkroom caches, which usually are there and make darkroom fast, are invalidated for valid reasons, so darktable has to re-run the whole pipe, and not just one module. And as you can guess, the total pipe processing time is more than just the time of one of the modules... > -- > jys Roman. > > darktable user mailing list > to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] darktable 2.2.0 rc0 released
On Fri, Nov 11, 2016, at 01:40, Roman Lebedev wrote: > I doubt that is a bug. Especially profiled denoise is quite CPU-hungry. Thanks. I'm well aware that the denoise is computationally expensive (and rarely have it enabled while editing). What I don't understand is why, occasionally, the rendering time is many times more than the sum of the time for either lens correction *or* profiled denoise, when both are enabled. Explain like I'm five? :) -- jys darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] darktable 2.2.0 rc0 released
On Fri, Nov 11, 2016 at 5:44 AM, wrote: > Thanks for splitting the preset storage out from the image db, very happy to > see that, and the modifier keys on the sliders is a nice UI enhancement... if > I can retrain myself to use them! > I've encountered one odd behavior, but can't quite seem to nail down exact > steps to reproduce: when viewing an image at 1:1 zoom, with lens correction > and profiled denoise enabled, it sometimes takes an *extremely* long time to > render the view, on the order of ~20 seconds or more instead of the typical > 3-4. This only happens with both of those modules enabled (even if they are > the only ones in the stack), and then only sometimes; I would say maybe about > 1 in 5 times when dragging the viewport box around in the thumbnail preview > with both modules enabled. I'm not using OpenCL. If I can narrow down the > circumstances a little more I'll file a bug report, but meanwhile maybe > somebody else with better knowledge of the internals can attempt to duplicate > this behavior... I doubt that is a bug. Especially profiled denoise is quite CPU-hungry. > -- > jys Roman. > On Sun, Nov 6, 2016, at 05:26, Tobias Ellinghaus wrote: >> we’re proud to announce the first release candidate for the upcoming 2.2 >> series >> of darktable, 2.2.0rc0! > [...] > > darktable user mailing list > to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] darktable 2.2.0 rc0 released
Thanks for splitting the preset storage out from the image db, very happy to see that, and the modifier keys on the sliders is a nice UI enhancement... if I can retrain myself to use them! I've encountered one odd behavior, but can't quite seem to nail down exact steps to reproduce: when viewing an image at 1:1 zoom, with lens correction and profiled denoise enabled, it sometimes takes an *extremely* long time to render the view, on the order of ~20 seconds or more instead of the typical 3-4. This only happens with both of those modules enabled (even if they are the only ones in the stack), and then only sometimes; I would say maybe about 1 in 5 times when dragging the viewport box around in the thumbnail preview with both modules enabled. I'm not using OpenCL. If I can narrow down the circumstances a little more I'll file a bug report, but meanwhile maybe somebody else with better knowledge of the internals can attempt to duplicate this behavior... -- jys On Sun, Nov 6, 2016, at 05:26, Tobias Ellinghaus wrote: > we’re proud to announce the first release candidate for the upcoming 2.2 > series > of darktable, 2.2.0rc0! [...] darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] darktable 2.2.0 rc0 released
- Original Message - > we’re proud to announce the first release candidate for the upcoming 2.2 > series > of darktable, 2.2.0rc0! Congratulations to all contributors! > - Darkroom: the preview (in top-left corner) is now no longer pre-demosaiced, > thus the preview, color picker, histogram show the proper results when there > is highlight clipping. [...] > - Preview pipe now does run demosaic module too, and its input is no longer > pre-demosaiced, but is just downscaled without demosaicing it at the same > time. I guess these two items talk about the same thing and if so you may want to remove one or merge both items in the final release notes. Perhaps: - Darkroom: the preview (in top-left corner), color picker, histogram show the proper results when there is highlight clipping. Internally, the preview is no longer pre-demosaiced, but downscaled and ran through the demosaic module. ? (Not sure if it counts as a "Big one" or "Quite interesting change", I'd lean towards the later) Thanks, -- Matthieu Moy http://www-verimag.imag.fr/~moy/ darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] darktable 2.2.0 rc0 released
we’re proud to announce the first release candidate for the upcoming 2.2 series of darktable, 2.2.0rc0! the github release is here: https://github.com/darktable-org/darktable/ releases/tag/release-2.2.0rc0. as always, please don’t use the autogenerated tarball provided by github, but only our tar.xz. the checksum is: a084ef367b1a1b189ad11a6300f7e0cadb36354d11bf0368de7048c6a0732229 darktable-2.2.0~rc0.tar.xz Packages for OSX might take a little time as the build environment has to be adapted to the new requirements. This is not a final release but a release candidate, so make sure to have backups of your darktable settings, library and sidecar files. Also don't use it if you are on a deadline. Apart from that we are confident that it's quite stable so please, try it, break it and report bugs! and the changelog as compared to 2.0.0 can be found below. - Well over 2k commits since 2.0.0 The Big Ones: - Add new automatic perspective correction module (https://www.darktable.org/ 2016/03/a-new-module-for-automatic-perspective-correction/) - Liquify tool for all your fancy pixel moving (https://www.darktable.org/ 2016/04/liquify-liquify/) - A new image module to use a Color Look Up Table (CLUT) to change colors in the image (https://www.darktable.org/2016/05/colour-manipulation-with-the-colour-checker-lut-module/) - In Highlight reconstruction module, the mode LCh reconstruction was completedy rewritten, and is no longer useless! - A new tool, darktable-chart, that goes along with the CLUT module, to create styles for the latter - Exposure fusion in the basecurve module to lower the dynamic range of images (https://www.darktable.org/2016/08/compressing-dynamic-range-with-exposure-fusion/) - Add new raw overexposure indication (https://www.darktable.org/2016/10/raw-overexposed/) - Darkroom: the preview (in top-left corner) is now no longer pre-demosaiced, thus the preview, color picker, histogram show the proper results when there is highlight clipping. - Add undo/redo support for the darkroom Quite Interesting Changes: - Split the database into a library containing images and a general one with styles, presets and tags. That allows having access to those when for example running with a :memory: library - Support running on platforms other than x86 (64bit little-endian, currently ARM64 only) (https://www.darktable.org/2016/04/running-on-non-x86-platforms/) - darktable is now happy to use smaller stack sizes. That should allow using musl libc - Allow darktable-cli to work on directories - Allow to import/export tags from Lightroom keyword files - Allow using modifier keys to modify the step for sliders and curves. Defaults: Ctrl - x0.1; Shift - x10 - Allow using the [keyboard] cursor keys to interact with sliders, comboboxes and curves; modifiers apply too - Support presets in "more modules" so you can quickly switch between your favorite sets of modules shown in the GUI - Add range operator and date compare to the collection module - Support the Exif date and time when importing photos from camera - Rudimentary CYGM and RGBE color filter array support - Preview pipe now does run demosaic module too, and its input is no longer pre-demosaiced, but is just downscaled without demosaicing it at the same time. - Nicer web gallery exporter -- now touch friendly! - OpenCL implementation of VNG/VNG4 demosaicing methods - OpenCL implementation of Markesteijn demosaicing method for X-Trans sensors - Filter-out some useless EXIF tags when exporting, helps keep EXIF size under ~64Kb - OpenCL: properly discard CPU-based OpenCL devices. Fixes crashes on startup with some partially-working OpenCL implementations like pocl. - darktable-cli: do not even try to open display, we don't need it. - Hotpixels iop: make it actually work for X-Trans Some More Changes, Probably Not Complete: - Drop darktable-viewer tool in favor of slideshow view - Remove gnome keyring password backend, use libsecret instead - When using libsecret to store passwords then put them into the correct collection - Hint via window manager when import/export is done - Quick tagging searches anywhere, not just at the start of tags - The sidecar XMP schema for history entries is now more consistent and less error prone - Rawspeed: fixes for building with libjpeg (as opposed to libjpeg-turbo) - Give the choice of equidistant and proportional feathering when using elliptical masks - Add geolocation to watermark variables - Fix some crashes with missing configured ICC profiles - Support greyscale color profiles - OSX: add trash support (thanks to Michael Kefeder for initial patch) - Attach Xmp data to EXR files - Several fixes for HighDPI displays - Use Pango for text layout, thus supporting RTL languages - Many bugs got fixed and some memory leaks plugged - The usermanual was updated to reflect the changes in the 2.2 series Changed Dependencies: - CMake 3.0 is now required. - In order to compile darktable you now need at lea
