i have a gtx 1650 max-q on a laptop and it works okay. yours should be way superior. but anyways i think by now you found out for yourself 
Thanks. You are right, with a fresh checkout the first error have gone.
Trying to solve the [qvk] error now.
Installing vulkan-tools and vulkan-validationlayers-dev, the [qvk] error has gone.
Installing libomp-11-dev the following error has gone:
[pipe] could not open config file ‘/home/philippe/Desktop/test2/001.NEF.cfg’.
./vkdt: symbol lookup error: /home/philippe/git/vkdt/bin/modules/i-raw/libi-raw.so: undefined symbol: omp_set_max_active_levels
Now reading the images I get:
[ERR] individual config /home/philippe/Desktop/test2/016.NEF.cfg not found, loading default!
[ERR] roi of last connected sink module display did not get initialised!
[ERR] running the graph failed (VK_INCOMPLETE)!
And at init time I still have these errors:
[ERR] device does not support requested feature samplerAnisotropy, trying anyways
[ERR] device does not support requested feature shaderStorageImageExtendedFormats, trying anyways
[ERR] device does not support requested feature shaderUniformBufferArrayDynamicIndexing, trying anyways
[ERR] device does not support requested feature shaderSampledImageArrayDynamicIndexing, trying anyways
[ERR] device does not support requested feature shaderStorageBufferArrayDynamicIndexing, trying anyways
[ERR] device does not support requested feature shaderStorageImageArrayDynamicIndexing, trying anyways
[ERR] device does not support requested feature inheritedQueries, trying anyways
EDIT: when I double click on the the skull thumbnail it doesn’t open
You know, I think it’s funny (witzig) that we have different definitions of art, even though I think our tastes are not so different. But in the end, you are right: technology can be art, too.
Btw, I think dt’s color balance rgb is more like a drug.
okay, progress 
the omp thing seems to be a dependency of openmp in rawspeed… some distros have the runtime library factored out of the regular llvm/clang packages. for gcc compilations i assume there’ll be a similar package.
the large bunch of [ERR] about not supported features is likely just some output you can ignore… it first loudly complains about builtin intel gpus and llvm lavapipe vk implementations… and then picks the gpu that does have all the features. i may want to silence these warnings in case the actually selected device does have support.
now skull thumbnails and VK_INCOMPLETE results are a bit more worrying. could you post a full compile log and a full ./vkdt -d all runtime log somewhere? i suspect compilation didn’t finish correctly. did it compile all the compute kernels?
heh. i guess i’m saying at this point this is not so much about art yet for me. there’s so much half-arsed technology in dt’s core, and so many features put on top of unsuitable infrastructure… i want to get the basic core tech right before doing frontend work. for that it kinda helps to have difficult build instructions and terrible ui, so i have time to focus
that said, if you want ui or some specific use case to advance it will totally help to drown me in feature requests and bug reports. i may or may not have much time these days but often times huge usability gains can be achieved with very little effort, and many bugs i fixed here so far were single-digit-lines-of-code fixes.
I think the crashes are not real crashes, I read something about forced timeouts if there is only one gpu.
How do I reset the pipline to “factory default” if I changed it and messed it up?
smaller update:
i setup some documentation that might help to get started with individual modules. in particular the markdown is in the main repository, and there’s a separate web repo that contains the illustrations/images (because they may potentially be large and be replaced frequently, once they get outdated).
for instance here is the page for the denoise module with references to burst image alignment and noise profiling.
also, here is the page for the draw module explaining the workings of the raster masks.
i did check and the raster mask drawing does work currently… all updates are pushed to github at this point. there is an examples/draw-guided.cfg for testing (requires a file examples/test.cr2 to run).
hmm good question. the easiest way is probably to remove the .cfg outside vkdt. i don’t think i wired a button for this yet.
…now there is. if you pull, there’ll be a reset history stack button in the selected images expander.
1 Like
i don’t have multi-gpu support now. it’s possible that slow gpus will run into the timeout, but that’ll usually require quite involved processing graphs or quite old/builtin intel gpus. you would see a VK_TIMEOUT something on the console.
Really nice to see that it is still in motion! Checked the commit history a while ago and it looked a bit stale at that point, guess you just didn’t push for a while!
One question about its future. It is implemented using a node graph but the interface is still darktable-like, do you keep the architecture open for an actual node-based interface later on? It would be epic to be able to switch to a node graph for complex edits as an option to the easier slider stack.
And a side note on the real-time stacking of multiple images. That would open up for some pretty interesting effects when coupled with high frame rate sequences! As well as better workflow for HDR merging Good to see you progress!
thanks.
i did, i’m not living this dangerously… just not to github.
oh the graph architecture is very much decoupled from the ui indeed. the gui is kinda a node graph, you can connect/disconnect/rearrange your modules freely. they are just displayed as a list. this dt-like linear appearance of it has to do with the common use case that you’ll just drop in an input image (raw or whatnot) and what to process it in a simple chain of modules. so going full blown 2d would be overly complicated and not add any value for daily use.
i suppose it would be easy to add a 2d layout node graph editor. there are plenty of widgets for imgui available: Node Graph Editors with ImGui · Issue #306 · ocornut/imgui · GitHub
yes you can get fun results… especially when coupled with the webcam input.
right. i haven’t explored stacking of different exposures though, just many underexposed images. i’d need some special handling for the different clipping points, but should not be hard.
3 Likes
thanks for the hint. i was looking into this a bit, and it seems there are indeed a few occasions of rather careless resampling happening in my current default graph. i fixed some, but am still working on others. let me prepare a devised version of the code and then post a few before/after shots here.
okay, here goes. these images show a sophisticated sharpness tester ™, a t-shirt of the academy software foundation. the camera is a fuji with xtrans layout. left: vkdt (old), center: vkdt (new), right: darktable for reference. i think the difference was mainly due to resampling during crop/rotate, though i did improve the demosaicing sharpness as well. i really don’t like this kind of deep pixel peeping… it hurts my eyes. did not attempt to match darktable’s white balancing here, i’m using the straight d65 matrices without further processing in vkdt here.
@betazoid is that similar to what you observed? if you have any more specific examples i’d be happy to look into these too.
I am trying to test denoise, but if I move the strength slider a bit to the right, the whole image turns green. I also tried the noise profiling, not sure it works. Anyway, it does not help the green cast.
compiled it on MX Linux 21, it was easy
heya,
good to hear compiling was easy on mint. i have some makefile/build changes that make building debian packages easy (make install from the top level respecting DESTDIR and prefix). will try to release the next days/weeks and provide a debian. might need @darix help to setup something on obs again or so.
anyways, denoising. it turns green if there is no noise profile for the given camera/iso. you can usually use the very image you’re looking at and run it through the noise profiling script, it’s much more robust than the profiling tool in the original darktable. if you don’t want to do that for a quick test, you can set the gaussian/poissonian parameters as noise a and noise b parameters in the i-raw module (just below the denoise one in your screenshot) manually. it’s often enough to play with just the gaussian noise a part to observe how details vs. noise are classified.
that said i have a few local changes pending to the denoise module that i’d like to merge. it’d be a bit slower but higher quality especially for very high iso, and preserve lines/features a bit better on fine scale.
the noise profile script in your output fails because it fails to extract the metadata from the 5d3 image, it doesn’t find a good file name. i suppose i could do a generic fallback here but really making exiv2 understand cr3 would be better.
colour management is functional, i’m using it…
i did a change to the read-icc script such that it outputs display.profile but vkdt reads two of these (one for each of the two screens that are supported by the internal colour management). to distinguish between the screens, you need to have display.HDMI-0 in your case, and you might have display.eDP-1 as i do on the laptop. vkdt will echo these connector ids to you, but you can also find out via xrandr the regular way. i can’t know which connector has the monitor that matches the icc you gave on the command line, so this is a manual step.
this is mentioned here: https://jo.dreggn.org/vkdt/doc/colourmanagement.html (sorry my certificate ran out again) and here: https://github.com/hanatos/vkdt/blob/master/doc/colourmanagement.md (the source of the autogenerated webpage).
I also tried the noise profile script with a ORF from my Olympus E-M5 Mark III - apparently it did not work.