vkdt dev diary pt 7

[hanatos (jo)]

hi all,

there have been a few recent updates:

• video output: support prores 10 bit with proxy/lt/sd/hq presets
• button in gui to construct videos/timelapses from sequence of images
• openexr input file support
• output modules all appear in gui with their options
• highlight reconstruction fix which avoids blurring c/a into the reconstructed region.
  before:
  
  
  
  after:
  
  
  
  (it’s a good hack i thought, no more memory or execution time needed)
• refactor raw loading library handling in the build system (no submodule but shallow clone)
• updated rawspeed (c++) to upstream and rebased cr3 support (this was likely the last time i have done this, the branch is not in very good shape)
• option to use rawloader/rawler (rust) instead of librawspeed/libexiv2, i hope this will make the obs packages build again on older distros (does not depend on recent c++ compiler)

[davidvj (David Vincent-Jones)]

The settings displayed are identical in both the ‘before’ and ‘after’ !!!

[hanatos (jo)]

yes, i call it a bugfix. there are no additional settings (why would you ever want psychedelic colours blurred into your skies). it just runs a hierarchical edge detection and switches the interpolation to smoother near edges now. while this does change your older edits, i’m going to claim only ever for the better. also i’m still not ready to give the same strong compatibility guarantees as darktable does (but getting closer).

[davidvj (David Vincent-Jones)]

Clearly understood now …

[clind]

Not sure it is the right place but I’ve tried to test the new version today and could not launch it :

[gui] glfwGetVersionString() : 3.3.8 X11 GLX EGL OSMesa clock_gettime evdev shared
[gui] monitor [0] HDMI-0 at 0 0
[gui] vk extension required by GLFW:
[gui]   VK_KHR_surface
[gui]   VK_KHR_xcb_surface
[qvk] error VK_ERROR_LAYER_NOT_PRESENT executing vkCreateInstance(&inst_create_info, NULL, &qvk.instance)!
[ERR] init vulkan failed
[ERR] failed to init gui/swapchain

[hanatos (jo)]

…are you trying a debug build without validation layers installed? on debian it’s called vulkan-validationlayers.

[clind]

Exactly, I crunch through your github instructions a little bit too quickly. Sorry.
on gentoo it seems to be activating the “layer” use on the “media-libs/vulkan-loader” package.

[hanatos (jo)]

…i should probably place such a hint in the error message here.

[clind]

vkdt crash when light table try to create the thumbnail for tif, I’ll recompile with debug and post a meaningful trace.
I tried 2 tif from different origins

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Unsupported { what: "Couldn't find a decoder for make \"Nikon\"", model: "Nikon COOLSCAN V ED", make: "Nikon", mode: "" }', lib.rs:62:45
stack backtrace:
   0:     0x7f2677fd90f4 - <unknown>
   1:     0x7f2677eec7ff - <unknown>
   2:     0x7f2677fb5c10 - <unknown>
   3:     0x7f2677fdaadf - <unknown>
   4:     0x7f2677fda365 - <unknown>
   5:     0x7f2677fdb26a - <unknown>
   6:     0x7f2677fdad62 - <unknown>
   7:     0x7f2677fdacc6 - <unknown>
   8:     0x7f2677fdacb1 - <unknown>
   9:     0x7f2677ee23a2 - <unknown>
  10:     0x7f2677ee2842 - <unknown>
  11:     0x7f2677ee98bc - rl_decode_file
  12:     0x7f2677ee66a7 - load_raw
  13:     0x7f2677ee6bcf - modify_roi_out
  14:     0x55b7866206aa - <unknown>
  15:     0x55b78661a461 - dt_graph_run
  16:     0x55b78662ae07 - dt_graph_export
  17:     0x55b78663364f - dt_thumbnails_cache_one
  18:     0x55b78663398c - <unknown>
  19:     0x55b786614dfc - threads_work
  20:     0x7f267843fbed - <unknown>
  21:     0x7f26784bfccc - <unknown>
  22:                0x0 - <unknown>

other one being from a different scanner

thread ‘’ panicked at ‘called Result::unwrap() on an Err value: Unsupported { what: “Couldn’t find a decoder for make "Nikon"”, model: “Nikon SUPER COOLSCAN 5000 ED”, make: “Nikon”, mode: “” }’, lib.rs:62:45
stack backtrace:

That said I like the updates made to the interface, adding module and switching from node to main view seems a lot easier than the last time I tried

[hanatos (jo)]

i’ve been having a few issues with the obs build because the build machines don’t have internet access. so i switched the rust backend on by default, apparently it doesn’t load these nikon raw files (or are these really straight tiff?). you can probably switch back to rawspeed in bin/config.mk (see bin/config.mk.defaults for instructions), and i should probably switch back to rawspeed as default and resolve the obs problem somehow.

[clind]

Building with rawspeed is throwing me another error when running

libi-raw.so: undefined symbol: omp_set_max_active_levels

I see from another post here that others been confronted to this issue in the past, I will investigate that

[hanatos (jo)]

this is something libomp.so. might be caused either by a wrong rawspeed branch, a confused install (clang-16 vs clang or so) or maybe one of the variables used in i-raw/flat.mk to detect the correct openmp linkage is confused.

i remember i had a thing like that in the past, but forgot what exactly caused it. did you git submodule sync && git submodule update -f after a pull?

[clind]

Ooook it requires clang-16 I’m currently running clang-15 … I masked the 16 version as no other package on my system requires it (and its quite long to compile).

I’ll get back to you when I’ll have the 16 version installed.
Thanks for your time.

[hanatos (jo)]

it’s too bad the OBS builds are broken due to how i get to the submodules during the build. i might get tired and do an appimage seems a bit idiotic to replace a good 4MB .deb by a 112MB .appimage, but at least i know how to build these.

[hanatos (jo)]

experimental/first time i’m doing this .appimage packages can be found here now:

https://vkdt.org/

[kmilos]

@hanatos

apparently it doesn’t load these nikon raw files (or are these really straight tiff?)

Yep, the CoolScan NEFs are really just “regular” 3-channel TIFFs.

RawSpeed won’t open them either btw…

[hatsnp (Nuno Paulino)]

@hanatos

seems a bit idiotic to replace a good 4MB .deb by a 112MB .appimage, but at least i know how to build these.

In more relative terms it’s only the size of two uncompressed 26MP raw files, seems worth it for the trouble it saves

[hanatos (jo)]

i’m sure there will be trouble though let me know if you encounter it.