Thank you for the detailed answer I can’t wait to explore the possibilities these informations will open 
By brackets I meant the braces or curly brackets used for “${home}” or such keywords stuffs in the filename field, but I noticed it’s because the key combination used for this character on my keymap is assigned to rating (stars) shortcut, I’ll have to custom that.
To have a meaningful stack trace I guess I’d have to keep the debug option activated when compiling vkdt ?
right. make debug it is. or customise the config.mk to at least not strip the binary. but you know… bloat is really bad i think 
re: customise keymaps: i still have to make these custom keys permanent, i don’t write/read them to/from disk yet.
updates since last changelog post:
frame to add postcard frame/border around image (b)(a):
(b):
also in the works: ca module: automatic chromatic aberration correction (2ms/2080Ti/20MP):
but want to tune it for speed, include defringing too, maybe run pre-demosaic, and test more to be sure it’s robust.
@hanatos,
I’ve finally foudn the culprit !
My graphic card driver had been switched from NVidia to Xorg new driver.
After switching back to Nvidia’s, everything is working fine.
I’m ashamed !
Sorry for the hassle, I’ll now tests your fixes
GLLM
Very impressive!
I once again have a laptop with a probably unsuitable iGPU (quite an old one, an Intel UHD 620, this time) but I used to be able to compile and start vkdt (but didn’t attempt to open a file then). Now I pulled the latest changes, ran git submodule update and make. When trying to start it I get the error:
zsh: floating point exception (core dumped) ./vkdt
Any ideas?
Thanks
EDIT:
Result of git bisect:
a139a1e2313734fb8daa21f751a176cbc6a17c8c is the first bad commit
commit a139a1e2313734fb8daa21f751a176cbc6a17c8c
Author: johannes hanika <hanatos@gmail.com>
Date: Tue Sep 20 08:40:01 2022 +0200
gui: don't write "imgui.ini"
src/gui/render.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
interesting. do you get a backtrace in /tmp/vkdt-bt-*?
(edit: be sure to git submodule update -f and make clean too)
I just noticed you mentioning this - is that the legacy HDR+ tiled align-and-merge (e.g. HDR+ Pipeline ) or the newer MFSR approach (e.g. GitHub - kunzmi/ImageStackAlignator: Implementation of Google's Handheld Multi-Frame Super-Resolution algorithm (from Pixel 3 and Pixel 4 camera))?
so far i’m not doing super res, but also no tiles. there is a correspondence/motion vector estimation step (on the full image, different mechanics) and quite ad-hoc merging of the aligned bayer blocks. as the github page you linked mentions… it’s not easy to get details right/exactly as in the paper. so let’s say the thing in vkdt behind the “merge into current” button in lighttable mode is something vaguely similar.
One of the two commands fixed it, thanks!
I tried out LOD=2 and got a very responsive interface even on this slow iGPU but expected a behavior similar to darktable: that when zoomed in, that ROI is rendered at screen resolution. So when zoomed in to 100% I expected to see that part of the image in full resolution. Instead zooming in has no purpose anymore as the image only gets blurry. I guess the behavior that darktable has is a lot harder to implement and necessary to reach usable speed on a CPU and deemed unnecessary on a GPU. But in order to use vkdt on an iGPU I think this would be desirable.
Dropping by to say good work and nice updates!
yes that mode does not receive much love. the one thing that would be easy to do is run the LOD=1 full res when zoomed in 1:1 and just show parts of it (so you’ll have to wait for it when zooming in). running on cropped resolution has all sorts of implications on boundary handling, especially for larger blurs. these are everywhere: local contrast, highlight inpainting, … and super messy to do in dt. doing that introduces a ton of complexity into every module and makes the pipeline run much slower (2x in the worst case, running twice essentially). also there’s a ton of synchronisation issues between dt’s preview and full pipelines (let alone the gui thread).
all that to support an integrated gpu from 2017 and introduce weight for everyone. does not exactly motivate me. i mean darktable works just fine for this kind of hardware and struck the trade offs as seemed the best choice 13 years ago.
btw you’re using an amd gpu? zoomed in should not blur, but pixelate (no magnification filter). 
I meant to say pixelated, no AMD weirdness going on here 
I get the argument that it introduces a ton of complexity. Still, even with an up to date discrete GPU there are occasions where I wound’t mind a more responsive interface (when using the draw module, e.g.). After all, running the pipeline at today’s screen resolution twice should still be faster than running a pipeline once at native resolution (for me the screen is less than 4MP, camera is 42MP).
And if the pipeline is capable of running at the screen’s refresh rate, there is no visible delay when zooming in neither.
For me, the main issue is that laptops with discrete graphics cards have too many compromises and using a different program back home means doing every edit twice.
But your idea of just adjusting the scale factor when zooming in seems like a very good compromise to me
I see lots of new commits and no posts here (checking this thread multiple times a week). I demand explanations!
(Also I just tried to make the latest version and it doesn’t seem to work. The lighttable only shows “bombs”)
haha fair enough
so some text to go with the commits:
i’m working on stuff in branches, so i don’t commit/push a whole lot to the public master branch.
mostly what i push are smaller fixes. remove bugs and annoyances, address stuff from the github issue tracker. i simplified the vignetting parameters, improved jpg workflow/defaults (rotation and colour space).
one thing i changed that might affect people is the colour correction that comes with the film curve is now the stupid dng-style simple thing, not aurelien’s dtUCS. it’s easy to swap out (i should make it a parameter i suppose) but i had some edge case images where especially dark pixels would misbehave/NaN with dtUCS.
the gui now has a “duplicate image” button (the key shortcut existed before) which also works if the image did not have an individual cfg yet. it doesn’t work for tagged collections / symlinks. i’m not sure which semantics would be best here. duplicate just the image in the tag/named collection or the original one.
i may have fixed the smoothed view when zoomed in on AMD cards (can’t test). there was a thing with immutable samplers in imgui vs my texture samplers that might have caused it.
i tested the c/a module a bit more on a variety of images, and it’s hit and miss… this needs more work to be a robust/everyday module.
a thing that may pop up on my todo list is better sound handling/time synchronisation. together with that i’m thinking i should overhaul the video rendering (stick closely to ffplay or so), but not this week or next.
as to the bombs (you remember the atari, right?): anything on the console if you run vkdt -d all ? are these raws or jpg in the directory? i mean it works for me ™ 
quick update just to keep posting:
fs.h platform specific abstraction layer, might help windows port at some point ).add module selection dialog:
readme.md documentation. in fact a module will not be shown here if it doesn’t have documentation. might extend it to module groups and add a go to docs button in the future.… could you try again? i fixed a validation layer complaint (that only shows on one of my machines) that might have caused this.
Oh this new module picker is great !!!
Suggestion: having 2 columns (one for the name, the other for the description), so that the heading are all aligned and easier to read.
I see there is a search box, which is great as well !!!
Unrelated question: could vkdt ever run on Android ? I think there are vulkan libs on Android, arent there ? (please, note that I’m completely out of my depth on this technical subject )
Thanks … will rebuild tonight and test those
G_LL_M
hm good idea and probably something that would happen once this thing has groups too. the dialog btw is the same as is used for blocks, tags, and presets, so i suppose improving it is time well spent.
i don’t see why not. glfw+vulkan apparently works there, the other dependencies are basic/optional really. whether or not it’d be a lot of fun to work with on a touch interface and with a presumably mobile low end gpu is another question
Okay ! Thanks.
I’ll wait for tablet with 4GB of VRAM 
heh. i think such devices often share the system ram, no? also i just read about a new “flagship gpu” that supports vulkan 1.1. that may not be enough to just compile vkdt, would probably require to strip some features
Running from the command line I get this… Anyone try running on 22.04 POPOS…
[qvk] dev 0: vendorid 0x10005
[qvk] dev 0: llvmpipe (LLVM 14.0.0, 256 bits)
[qvk] max number of allocations -1
[qvk] max image allocation size 16384 x 16384
[qvk] max uniform buffer range 65536
[qvk] device 0 does not support requested feature shaderSampledImageArrayDynamicIndexing, trying anyways
[qvk] device 0 does not support requested feature shaderStorageImageArrayDynamicIndexing, trying anyways
[qvk] device 0 does not support requested feature inheritedQueries, trying anyways
[qvk] num queue families: 1
[qvk] picked device 0 without ray tracing and without float atomics support
[qvk] validation layer: VkPhysicalDeviceShaderAtomicFloatFeaturesEXT.shaderImageFloat32Atomics not supported (VK_ERROR_FEATURE_NOT_PRESENT)
[qvk] validation layer: vkCreateDevice: Failed to create device chain.
[qvk] error VK_ERROR_FEATURE_NOT_PRESENT executing vkCreateDevice(qvk.physical_device, &dev_create_info, NULL, &qvk.device)!
EDIT… seems like a graphics card issue maybe?? I have a 3060TI but maybe not setup right in PopOS??