Hello, On Tue, Dec 17, 2019 at 9:14 AM Remco Viëtor <remco.vie...@wanadoo.fr> wrote:
> On mardi 17 décembre 2019 07:42:32 CET Jochen Keil wrote: > (...) > > > > Btw. does anybody know how darktable handles editing of pictures? E.g. my > > pictures are 8000x4000, yet my viewport has only 2000x1000 (just an > > example). Shouldn't it be enough to render the image to this size to > > improve editing speed? > The numbers that have been given so far were for export, presumably to > full > size. Does rendering take as long as exporting the images? > No, sorry for the derailing. Rendering / Editing is noticable faster, but still sometimes sluggish. Actually that's a bigger concern for me, because I can run export jobs in batch. According to the manual, full demosaicing for viewport is only done when > the > image is zoomed at more than 50%, or when asked for explicitly by the user > (through a setting in the preference dialog). > > Also, I noticed that by enabling the amaze demosaicing the editing > > performance degrades. That's why I usually switch it to amaze at the end > of > > my editing process. However, from what I understand demosaic is one of > the > > first (if not the first) module in the pipeline. Shouldn't it be possible > > to cache the result, just like exporting to a tiff and reloading? > > > "Amaze" is known to be a slow method, which is why it's not the default. > Yes, but as far as I understood it, it's the recommended method for use with the filmic module. > Demosaic is not the first step in the pipeline, at least 'raw black/white > point', 'white balance' and 'highlight reconstruction' come before. And > those > are almost always present. As under normal operation (with normal screen > sizes) demosaicing is *only* performed when zoomed in, or on export, > caching > of the demosaicing step isn't all that useful (I think). > > A proper cache might also be quite complicated to implement correctly: > there > are other slow modules, which would also benefit (e.g. 'denoise > (profiled)'). > But then you have to have multiple intermediate results cached (after each > expensive step), or keep track of which change in the processing stack > invalidates the cache in each particular case. > Thank you for the explanation! My idea stems from the fact that a friend of mine always tells me how great Lightroom is at handling this stuff. He doesn't have a specialized computer, only a Macbook (2 or 3 years old, rather high end afaik). He described the way Lightroom does it as a local copy for editing, which then applies all the editing to the real file only on export. Allegedly it's much faster. > The export to tiff & reload "pattern" does help performance-wise, but I > > don't like it, because you'll scatter your history across several files. > Perhaps check your 'preferences' setting wrt demosaicing (core options, > 'demosaicing for zoomed out darkroom mode'). If it's set to "full > (possibly > slow)", try one of the other options? (That should have no effect on the > *exported* results). > I will look into that and report back, thank you! And what happens if you aply a style with (just) the "amaze" demosaicing on > export, while having the default active during editing? Or is there a > particular reason you need to have the final demosaicing active while > editing? > That's what I kind of do to speed things up (also denoising, chromatic abberations, and a few others). However, as far as I understood it's not ideal. According to Aurelien Pierre the filmic module works best when all those correction modules are already enabled. Cheers, Jochen > > Remco > > > > ____________________________________________________________________________ > 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
