that sounds like it’s using the software/llvm device (dev 0) and does not recognise any other device at all. do you have vulkaninfo installed? the nvidia driver?
I’ll check. Thanks for the suggestions…
today’s news:
- replaced the c/a correction module by something very simple that works robustly
- now loading pretty much everything from home directory with priority. this allows one to customise for every user
- display colour profiles
- default thumbnail and darkroom mode processing for image formats
- favourite ui elements in the respective tab in darkroom mode
- super hacky but very flexible metadata read support (can be customised in
config.rcby modifying the exiftool command):
5 Likes
i think i’m near feature completion for a first release. if anyone is still sorely missing something, speak up 
in the mean time, i started a small howto collection to introduce some special topics/workflows, and i’ll probably introduce a feature frozen release branch in the next days.
14 Likes
Oh, one thing I thought of, using vkdt in PlayRaws: if an image is opened from the command line, the export directory should be set to the path to the original image… ??
I haven’t pulled from github in a few weeks, if something like that is already there then ignore this…
right, good idea. i never notice because my default export path is /tmp which is also where i download playraws to. i suppose i should make ${file_folder} or some such work in the export filename expansion.
i’m less sure about changing the behaviour for command line/single image mode. the export filename is read from config.rc so i’d usually expect that to be respected. i suppose you’re making a case for export presets here.
My PlayRaw workflow is 1) regard the interestingness that are PlayRaw threads, pick one for munging; 2) download the raw file, goes to ~/Downloads on either my Linux or Windows machine; 3) drag the raw file from Downloads to a rawproc/vkdt icon on my desktop, which is really just opening the image in the respective software from a command-line parameter; 4) enjoy figuring out someone’s capture and save a JPEG, and finally; 5) save the JPEG rendition for posting here.
rawproc defaults to saving such in the same directory as where the raw resides, which also supports my Open->Source menu operation; the processing that made the JPEG is saved in the rendition metadata, and if I drag the JPEG over to the rawproc icon, rawproc will ask, “open the JPEG, or open the original file and apply the processing?”. But this is not a vkdt thing… 
If there was a preset that intimated, “same directory as input file” I’d be happy as a clam. I’m still happy anyway, vkdt is such a treat…
okay, the drag+drop should work. and if you’re not using vkdt for much else you can now just set your export file name to ${fdir}/img_${seq} which will place the exported image wherever the input image was coming from. (export: support ${fdir}, the directory of the input file · hanatos/vkdt@09582d7 · GitHub)
and well, to support multiple .cfg with the same raw, you’d need to create a duplicate in lighttable mode (or manually copy the .cfg to one with a different name that happens to source the same raw for input).
dt also has this “open xmp” menu that accepts jpg. maybe it’s worth implementing this button… but it’s simple enough to place a copy of the .cfg in the same directory as the raw file. vkdt opens .cfg files conceptually. there’s just a shortcut for supported files which will create a default filename.ext.cfg file that is loaded then. this means it is very straightforward to support multiple edits for the same input file.
1 Like
@hanatos ,
I have rebuilt ./vkdt @ d726161
vkdt now freezes completely when I click on the metadata entry in lighttable.
I have added this line in .config/vkdt/config.rc:
strgui/metadata/command:/usr/bin/exiftool -l -createdate -aperture -shutterspeed -iso
and I have exiftool, ofc:
After it freezes, I must kill it.
No real clue in the terminal output.
I tried to make clean && make debug and started again in hope the terminal would show something. But it does not.
vkdt still freezes, uses 24% of my 7700k CPU.
What can I do to provide more valuable info ?
Thanks
GLLM
if you built via make debug you can run
$ gdb --args vkdt -d all -D perf
(gdb) r
and then when it freezes move away the frozen window, go back to the gdb shell and type
(gdb) thread apply all bt full
and post the output (will be a lot), or just the output of the same without the full (so it’s not quite so much)
using cpu sounds like a busy loop, let’s see what it’s doing…
1 Like
oh i forgot to say: it might be worth pulling before trying again, there’s a slim chance i fixed it.
1 Like
I tried. Still freezes.
I need to check this gdb thing. FIrst attempt was a failure
Will keep you posted
Tyvm
hmm try again now please?
Well: no luck …
But now I see:
$ Use of uninitialized value $num in numeric ne (!=) at /usr/share/perl5/File/RandomAccess.pm line 317.
Use of uninitialized value $num in numeric ne (!=) at /usr/share/perl5/File/RandomAccess.pm line 317.
Error: Unknown file type - -
this is a perl error inside exiftool (i.e. i have no idea what it’s trying to tell me). it would really help to see where it is blocking there (gdb output). i’m poking around blindly here (pushed another thing).
@hanatos
well, after another pull, it’s now working fine :-o
Not sure what happened… Sorry for the false flag !
I’ve now played a bit with config.rc to try enrich the shown metadata.
Can I request an improvement : no line return after the exif title, just a column (maybe a tab) so the info is shown next to the exif type, and takes less space
See
could be changed to
Whatever your reply, thanks … This metadata module is very much welcome 
Sorry for the long wait. I just tried but got a crash. I opened an issue on GitHub and attached a back trace.
I’ve been seeing bees (not bombs) for the last few days at least (weeks).
Most opened folders shows this … only way to have this change is open the pics in darkroom 1 by 1 !
yeah i was thinking about this two-column layout. but that either requires that i actually parse the output before displaying (requires code and only deleted code is good code) or a monospace font. the monospace variant looked terrible i thought. will have to think about some elegant/lightweight solution here.
i saw this busy bee thing on jpg too once. but it went away after a make clean cycle so i didn’t worry about it. i suppose you can try to rm ~/.cache/vkdt/* to make sure all thumbnails are regenerated from scratch too.