about drivers: since recently, the driver support in debian’s apt sources is really very good. i went back to just using nvidia driver and vulkan sdk from there, apt has the latest and greatest (in sid at least, that is). very happy not having to mess with a manual .run install.
about the GPU spec. i talked to a few folks who have pre-5500 intel gpus, where vulkan support was lacking. i mean we’re talking 10 year old equipment here. still vkdt has a hard dependency on some vulkan features, so lack of this support means you just can’t run it at all.
the other thing is that i did not spend much thought really optimising the code for low-end machines. obvious things like dt does it (only reprocess the pipeline from modules that actually changed their parameters and such) i just didn’t care about, because on my nvidia GPUs this would strip off half a handfull of milliseconds. on older intel, this introduces noticeable lag (more in the 100s of milliseconds).
so: yes it will perform better even on old hardware. the caveat is that “better” here means it does what it does faster. only it always processes all modules and full res and full crop, where today dt processes downsized to your viewport resolution and only the visible crop (often this is like 20x less work, but comes with some substantial headaches for local operations that require some amount of context or even global histograms…). on my nvidia the vulkan implementation eats this 20x for breakfast. on older intel not so much.
while i believe this illustrates the point that vkdt’s pipeline/processing graph is better, for a practical piece of software you’d also be interested in the final user experience. this either needs some careful implementation of caching (i’ll get to this as processing graphs become more complex i suppose), or your GPU needs to be past the turnaround point (i have no good data here, the bigger and newer the better…).
About merging back to old darktable: I think there are already some interesting features in vkdt - apart form the pure GPU pipline - that maybe should be merged into old darktabe asap. E.g. the local laplacian filter works in linear RGB in vkdt but in Lab in old darktable. Am I seeing this right? Unfortunately I am too stupid to do this myself.
… i believe the current default config applies the local contrast after the curve, so strictly speaking it’s not linear (though the working space is linear rec2020 throughout the pipeline). it’s easy enough to move it around though, both in vkdt and dt (well in dt i guess it works in Lab so there would need to be some wiring work in the code).
but the old pipeline with the full-crop preview + fine res full pipelines which need to talk to each other to compute approximate laplacian coefficients… is no fun to program, when you can have a much simpler one which is also faster. so my motivation backporting stuff to the old pipeline (not even just old dt) is a bit limited.
So you think it is easier to modify local contrast in old darktable so it works in linear RGB than backport local contrast from vkdt?
Guess what: after I wrote this comment I got an encouraging private message from someone stating that he was convinced that I could do it
Sure it was meant as a compliment to my overestimated intelligence when I don’t even understand what a Laplace pyramid is…
I did not mean that you should do it. Nevertheless I am sad that you are not developing old darktable any more.
Still playing with code, I’ve some questions and/or difficulties.
black point. A rggb value 0 remains 0. This seems aligned with the filmcurv code (black slider). But I would like to be able to offset a bit those black points. Do I miss something ? Should an exposure black slider be added ?
contrast. When I connect it before filmcurv the developped image is ok, but exiting darkroom the thumbnail remains black (I got also a darkroom black image but I’m not able to reproduce every time).
If I connect it before hist the displayed histogram looks strange. then connecting it to display, the histogram is back ok. And the thumbnail is ok too.
The contrast radius has no effect.
black point: yep, no control for that. should probably be added to the exposure module. however, i also have quite a bit of garbage intertwined in this module because i wasn’t willing to spend another module for colour transforms and white balancing. we should probably rip out exposure as a real exposure thing, so it can be combined with the “draw” module for dodging/burning, and have a “colorin” matrix/lut thing for the colour part.
would you have a .cfg or screenshot of your connectors for this second case? i’d like to reproduce and fix this. possible that the thumbnails graph conversion fails somehow, i wanted to touch this code again anyways (reuse the cache that already exists in dr mode, now it reprocesses the whole thing which costs a few ms when exiting dr mode).
…just tried to reproduce. swapping llap/contrast and film curve modules works here. you sure you didn’t accidentally disconnect the display module? if the 1D visualisation in the gui is confusing, there is also “vkdt-cli --dump-modules” and “dot -Tpdf <” to visualise the graph in 2D.
you sure you didn’t accidentally disconnect the display module?
Normally not, because playing with the position it works, but only before hist and display.
All the other positions work in darkroom (not always but I haven’t captured the conditions) but produce black thumbnails.
Here an example where darkroom is black.
Using this default config: default-darkroom.cfg.txt (1.2 KB) and connecting contrast before filmcurv ending with 020.NEF.cfg.txt (1.6 KB) and main.pdf (14.9 KB)
This black darkroom does not happen when contrast is already connected in default-darkroom.cfg.
aaah i see, sorry i thought you meant the local laplacian. the contrast module is the other one using the guided filter and a single pass, so it would only ever boost detail at one scale. i changed something maybe in the guided filter code and the module broke. i should probably look into getting it back. until then contrast is known broken…
hm good catch, it’s not wired. i’m not sure i have much plans for this module at all… anyways i pushed the radius wired to the slider. there may be one more piece of infrastructure missing to make this useful:
changing the radius of the blur a lot means that the pipeline needs to change (needs to insert more recursive blur kernels). this means that all memory allocations become void and if such an event happens the full graph needs to be rebuilt. to this end the modules should have a callback mechanism that allows them to return runflags when a value is changed, given old and new values of a certain parameter from the gui. i should try to find some time in the next couple of days and fix this in (i might remember all the modules that need it). currently the gui assumes no big changes take place when you push a slider (only for the crop buttons).
this api is now pushed. the contrast module has quite a few issues though. the filter seems to have weird border artifacts on some images. it is USM with a guided filter, not a real blur, so it sharpens textures and noise, mostly. i introduced a “threshold” parameter for it but can’t get good results with it. i might replace it by a regular USM blur (would also be faster), or do something else clever about it.
sidenote: i introduced an additional parameter, but old history stacks are still valid here, since they are explicitly named in the cfg and i didn’t change meaning of the old values.
In a previous message of this post you compared the speed of Darktable (updating the preview of the thumbnails images) with your current work on the GPU side. Your code was much faster.
Just out of curiosity, have you checked one of the latest builds of Darktable?
In these past weeks there have been huge amount of improvements some of them related to its speed. Therefore, Darktable should be much faster now
no, i did not do a new comparison. you’re referring mostly to the light table rendering speed? i don’t think olden dt can compete with the image processing (for thumbnails, rendering, or export). but also light table rendering is a non-issue if you’re doing it on hardware. this is fractions of a millisecond if you do it directly, vs carrying pixels through obscure channels in 8 bits through various helper libraries… you simply don’t need any of the single thread tricks.
