vkdt devel diary

A question concerning denoise: is it necessary to create a noise profile for every single image or can I use a profile that is already there for photos from the same camera at the same iso?

And another question: I have seen under the recent commits that you added a lens correction module - does that do CA correction as well?

noise profiles are created for camera (maker/model) + iso value, just like in darktable too.

the lens correction module was there for some time now, but now it appears as disconnected module in the default raw processing graph for convenience. it does handle transversal C/A, not lateral (similar to the lensfun sliders). it does not have a database of lenses, but only two parameters guiding the distortion (squish0,1). so far i found it easy enough to dial these in by hand, but i might want presets for this.

I am quite satisfied with RT’s automagical raw CA module. I don’t even have to worry about presets and could adjust sliders if it doesn’t quite do it. On top of that there are separate non-raw CA and defringe modules in the other tabs/categories.

yes, these are better. the ones in the lens module were like 4 lines of code so i thought i might as well put them in (most !/$). more sophisticated c/a reduction later.

many thanks to @darix! we now have regularly built suse and debian packages:

2 Likes

current state is:

  • Debian works (11 and unstable)
  • openSUSE Tumbleweed works
  • Fedora package fails with clang that it doesn’t find OpenMP and with gcc it fails with a lot of buffer size problems. (34 and Rawhide)
  • Ubuntu clang 12 does not support C++ 14 std? (only 21.04 is new enough)

older distros? vkdt needs very recent vulkan support in your drivers and libraries, so you need a very recent distro anyway.

make install is installing too many files. like all the C and C++ files. or those generator files ( macadam, mkabney, mkspectra )

I did compile vkdt on Manjaro some weeks ago. Tried on Mint/Ubuntu 20.04. Failed but not because of C++ 14 std but the fact that I have an original Nvidia driver from the Nvidia .run and not the Ubuntu packaged driver. I was going to try again on Ubuntu/Mint 20.04. The Nvidia driver for Ubuntu 20.04 (465 and 470) is newer than the Debian 11 driver (I think 461). I think it should be possible to compile it on Ubuntu 20.04 somehow.

the vulkan-headers package on 20.04 is too old

Trying to compile vkdt on Ubuntu 20.04 I get this error:

[100%] Linking CXX executable TiffParserFuzzer-GetDecoder-Decode
make[5]: Leaving directory '/home/anna/vkdt/built/ext/rawspeed'
[100%] Built target TiffParserFuzzer-GetDecoder-Decode
make[5]: Entering directory '/home/anna/vkdt/built/ext/rawspeed'
Scanning dependencies of target ParserFuzzers
make[5]: Leaving directory '/home/anna/vkdt/built/ext/rawspeed'
[100%] Built target ParserFuzzers
make[5]: Entering directory '/home/anna/vkdt/built/ext/rawspeed'
Scanning dependencies of target fuzzers
make[5]: Leaving directory '/home/anna/vkdt/built/ext/rawspeed'
[100%] Built target fuzzers
make[4]: Leaving directory '/home/anna/vkdt/built/ext/rawspeed'
make[3]: Leaving directory '/home/anna/vkdt/built/ext/rawspeed'
strip -S ../built/ext/rawspeed/librawspeed.a
make[2]: Leaving directory '/home/anna/vkdt/ext'
Makefile:53: [src (ext Makefile)]
mkdir -p built/
Makefile:13: [src (ext Makefile)]
Makefile:54: [src (ext Makefile)]
make -C src/
make[2]: Entering directory '/home/anna/vkdt/src'
ls: cannot access 'pipe/modules/*/*.tesc': No such file or directory
ls: cannot access 'pipe/modules/*/*.tese': No such file or directory
clang -Wall -pipe -I. -D_GNU_SOURCE -std=c11 -DVK_ENABLE_BETA_EXTENSIONS -fPIE -Wall -pipe -O3 -march=native   -c cli/main.c -o cli/main.o
In file included from cli/main.c:2:
In file included from ./pipe/graph.h:2:
In file included from ./pipe/node.h:4:
./pipe/raytrace.h:10:3: error: unknown type name 'VkAccelerationStructureKHR'; did you mean 'VkAccelerationStructureNV'?
  VkAccelerationStructureKHR                  accel;          // for ray tracing: top level for all nodes that may hold bottom level
  ^~~~~~~~~~~~~~~~~~~~~~~~~~
  VkAccelerationStructureNV                                                           
/usr/include/vulkan/vulkan_core.h:9281:35: note: 'VkAccelerationStructureNV' declared here
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkAccelerationStructureNV)
                                  ^
In file included from cli/main.c:2:                                                   
In file included from ./pipe/graph.h:2:
In file included from ./pipe/node.h:4:
./pipe/raytrace.h:17:2: error: unknown type name 'VkAccelerationStructureGeometryKHR'
        VkAccelerationStructureGeometryKHR          geometry;
        ^
./pipe/raytrace.h:18:3: error: unknown type name 'VkAccelerationStructureBuildGeometryInfoKHR'; did you mean 'VkAccelerationStructureCreateInfoNV'?
  VkAccelerationStructureBuildGeometryInfoKHR build_info;
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  VkAccelerationStructureCreateInfoNV                                                 
/usr/include/vulkan/vulkan_core.h:9435:3: note: 'VkAccelerationStructureCreateInfoNV' declared here
} VkAccelerationStructureCreateInfoNV;
  ^
In file included from cli/main.c:2:                                                   
In file included from ./pipe/graph.h:2:
In file included from ./pipe/node.h:4:
./pipe/raytrace.h:38:3: error: unknown type name 'VkAccelerationStructureKHR'; did you mean 'VkAccelerationStructureNV'?
  VkAccelerationStructureKHR                  accel;          // needed for ray tracing kernels: bottom level structure
  ^~~~~~~~~~~~~~~~~~~~~~~~~~
  VkAccelerationStructureNV                                                           
/usr/include/vulkan/vulkan_core.h:9281:35: note: 'VkAccelerationStructureNV' declared here
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkAccelerationStructureNV)
                                  ^
In file included from cli/main.c:2:                                                   
In file included from ./pipe/graph.h:2:
In file included from ./pipe/node.h:4:
./pipe/raytrace.h:39:2: error: unknown type name 'VkAccelerationStructureGeometryKHR'
        VkAccelerationStructureGeometryKHR          geometry;
        ^
./pipe/raytrace.h:40:3: error: unknown type name 'VkAccelerationStructureBuildGeometryInfoKHR'; did you mean 'VkAccelerationStructureCreateInfoNV'?
  VkAccelerationStructureBuildGeometryInfoKHR build_info;     // geometry info
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  VkAccelerationStructureCreateInfoNV                                                 
/usr/include/vulkan/vulkan_core.h:9435:3: note: 'VkAccelerationStructureCreateInfoNV' declared here
} VkAccelerationStructureCreateInfoNV;
  ^
6 errors generated.                                                                   
make[2]: *** [Makefile:73: cli/main.o] Error 1
make[2]: Leaving directory '/home/anna/vkdt/src'
make[1]: *** [Makefile:54: src] Error 2
make[1]: Leaving directory '/home/anna/vkdt'
make: *** [Makefile:7: all] Error 2

Just want to add one more thing: It was definitely possible to compile earlier versions of vkdt on Ubuntu 20.04., maybe even 19.10 or so. I am also quite sure that in the beginning someone complied it on 18.04 or even 16.04.

hi, sorry i have trouble finding time on a computer these days… just some quick comments:

  • will look into the make install rule, i suspect it’s not the makefile but the debian install-executables or what it’s called
  • since i could not resist coding some super basic 3d/path tracing vkdt has a dependency on recent vulkan now. this also makes some yuv/webcam formats possible but also means you need a more recent libvulkan (as darix pointed out). i mean, “recent” is like from january 2021 (1.2.185 works i think).

confirmed, fix pushed, now using rsync too.

new debian tarball

you should get your OBS account so you can edit it directly :wink:

you didnt update the control file to include rsync in the list and also not all the other missing build deps that i added to the dsc file in the OBS

diff -urN control.old control
--- control.old	2021-08-18 14:42:19.000000000 +0200
+++ control	2021-10-04 23:02:23.598894397 +0200
@@ -2,7 +2,22 @@
 Section: graphics
 Priority: optional
 Maintainer: johannes hanika <hanatos@gmail.com>
-Build-Depends: debhelper-compat (= 12), cmake, pkg-config, libomp-dev, clang, libglfw3-dev, libvulkan-dev, libjpeg-dev, libpugixml-dev
+Build-Depends: debhelper-compat (= 10),
+        cmake,
+        pkg-config,
+        libomp-dev,
+        clang,
+        libasound2-dev,
+        libglfw3-dev,
+        libvulkan-dev (>= 1.2.162),
+        libjpeg-dev,
+        libpugixml-dev,
+        libfreetype-dev,
+        zlib1g-dev,
+        libexiv2-dev,
+        libxml2-utils,
+        rsync,
+        glslang-tools
 Standards-Version: 4.5.0
 Homepage: https://jo.dreggn.org/vkdt/
 

@hanatos now you can load even videos via vulkan :smiley:

https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-470.62.05-Beta

package download via

https://software.opensuse.org/download.html?project=graphics%3Adarktable%3Amaster&package=vkdt

heh, i’m telling you this api is fun to work with. not overly focused on video at this point, but for anything higher res than what my camera can do some async copy/decode like this will be needed. i’d very much like to replace the ffmpeg encoding by something like this too.

You can encode as well An Introduction to Vulkan Video - The Khronos Group Inc

i’m currently editing a set of a few hundred images taken over the course of the year. to make this halfway efficient workflow wise i prepared a new version with a preset system:

this is somewhat more flexible than in dt classic. if you press ctrl-o in darkroom mode (or the button “create preset”) it’ll show you the full list of settings of the current image (this is the content of the .cfg file):

since that is usually a lot and you can already copy everything via ctrl-c ctrl-v in lighttable mode, the text input box at the top allows you to filter the list. for instance searching for lens will give you everything related to the lens corrections module:

the individual lines are buttons, you can select them (they will be highlighted in red). different to the original dt, you can select only parts of the parameters of a module to be included in a preset. it would even be possible to include only portions of a single parameter if it holds an array value (via paramsub instead of param, but that’s not exposed in the ui). conversely, you can include settings for multiple modules at once (like full sub-graphs for dodging/burning or so, by filtering by the instance name).

you can choose to include the module definition itself as well as the connections. these will place the module at a specific position in the processing graph. as the preset creator you’ll have to be careful that this introduces dependencies on the other modules mentioned in the connection (here that’d be crop:01 and demosaic:01, which are included in the default graph, configurable via default-darkroom.i-raw). i expect this module/connect thing to cause trouble in case of non-default history stacks, but including only param should always be safe.

once presets are created, you can apply them via ctrl-p in darkroom mode, bringing up this dialog:

again typing filters the list and pressing enter will accept the top item, so you can quickly navigate the list without mouse interaction. all it does is list the .pst files in ~/.config/vkdt/presets/*, so it’s very easy to maintain (delete/hand-tune/etc) the custom presets.

note that this is similar to the blocks concept, these are files in bin/data/blocks. the difference is that these contain wildcard connectors that enable me to insert them at a specific position in the pipeline. so they are more generic but also not as easy to apply.

3 Likes

the Debian package seems to be very stable, but I don’t find the read-icc script anywhere, and some other files such as the example files seem to be missing, too.

Edit: two features would be handy: first, some widget in the editor window which indicates the zoom level. Second: in the modules an on-and-off button so it is possible to quicky see what the photo looks like with and without the effect.
Another idea: when scaling down during export, a different algorithm should be used because the exported and downsized image looks a bit blurry.

Edit: apparently, when a photo is exported, it is converted to sRGB and apparently a profile is atteched too, though I am not sure about the latter - is it possible to save the photo in a different color space?