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…
(okay, this is stupid, broken code online. please pull and try again)
Your last commit is still on 8th June… 
oops too many remotes, should be on github now too.
Works great now. No black image any more. Thanks !
What about contrast / radius ? Any issue or plan about it ?
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.
Hello @hanatos
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 
hi silvio,
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.
Hello @hanatos
you’re referring mostly to the light table rendering speed?
Yep. You posted 2 videos and your code was much faster.
There has been a huge amount of improvements on this task on Darktable these past months but I suppose your GPU stuff is still faster 
well yes, the videos were about thumbnail creation (so nothing much has changed for dt in that regard). lighttable rendering is pretty much free in vulkan, and it’s great that dt got improvements there.
Interesting: please post a sample.
okay, here are your numbers. i measured the time between two events in dt (the current darktable -d perf -d lighttable seems broken in git). typical outputs are like
vkdt
[perf] total frame time 0.000s
[perf] ui time 0.000s
[perf] total frame time 0.000s
[perf] ui time 0.000s
[perf] total frame time 0.000s
[perf] ui time 0.000s
[perf] total frame time 0.000s
[perf] ui time 0.000s
[perf] total frame time 0.000s
darktable
8.494874 [lighttable] expose took 0.0530 sec
8.537822 [lighttable] expose took 0.0429 sec
8.644052 [lighttable] expose took 0.1062 sec
8.711264 [lighttable] expose took 0.0672 sec
8.741537 [lighttable] expose took 0.0303 sec
8.762014 [lighttable] expose took 0.0205 sec
8.766640 [lighttable] expose took 0.0046 sec
8.826952 [lighttable] expose took 0.0603 sec
8.946266 [lighttable] expose took 0.1193 sec
this is on the same directory of raw files, both have precached thumbnails, both use fullscreen on 1440p with 6 images per row. but yes, drawing a few pixels in 2D is a non-issue, as i said. nothing very surprising or meaningful here.
in all fairness, the directory contains some regression tests with truncated raw, for which vkdt tries to load the raw/thumbnail and fails, which temporarily pushes up the frame times to like 6ms because it loads the thumbnail in the gui thread, because why not.
that said, i’m not worried about anything <16ms in this category (typical screen refresh rate).
Breaking things is part of the learning process. Wouldn’t have developed my custom guided filters otherwise.
1 Like