But do you need to go with a database for what is basically metadata? I think there are other programs better suited for tagging and searching (Digikam comes to mind). Although getting a thumbnail to the DAM program might be a hassle. Not sure how you have to handle the processing steps in such a scenario, though (sidecar sounds easy, but does have its own complications).
I’ll try to understand your db implementation… 
Tagging is for me a way to manage and find my images inside dt. I’ve tried external DAM solutions but it’s always a burden.
With dt tagging, I like the hierarchical mechanism and the fact you can cover most of the metadata field with it (exceptions like title, description or geotags for example, which are mostly image specific). It could cover easily colors and rating as well…
In dt, the tagging UI sped up when displays/changes stopped accessing the db and used gtk tree data instead. I guess that imgui tree is also able to do similar things.
And beside the associated searches (by image or by tag) there is also the translation (read/write) to external exif/xmp or other babel world information.
Could this be developed as its own module or as some sort of plug-in. I say this for two reasons. As VKDT is not yet mature as a raw processor would it not be easier to develop to see how lean stable and powerful it could become for that purpose before expanding it too much and also as a use case. I have always had the best intentions to use ratings and tags etc etc but I never get to it and I likely never will if I am honest… For me my folder structure is enough. There may be other users that would use VKDT that way as well and prefer the simplest fastest program that could be created. There may be users that would use a different DAM or just use vkdt to process part of their workflow… So I guess I am saying if it is added to vkdt is there a way to keep it from hampering the core functions and perhaps even stay out of the way for users that don’t want to use it…while still being available to those that do…
That’s surely an idea. But allowing plugins is in itself already a big challenge (see the lua plugins infrastructure for dt).
I understand also your reasons, but tagging has nothing to do with raw processing and it should not penalize you if you don’t use it. Are you suffering from it in dt ?
No really I am not and I likely didn’t really articulate what I was thinking…it was more along the lines of simply thinking about prioritizing the processing aspects of the software and not having distractions or other issues that might arrive with a snowball effect of add this and add that… For sure the tagging is not in my way at all in DT as I mentioned I don’t use it… I just had no idea really being naïve how much code or integration had to be created, monitored and maintained to introduce something like that.
yeah i sympathise a lot with that idea… keep things simple. also i’m not using tags much. but i do use them to collect images from multiple directories for, say, a calendar or so. for this usecase, the current implementation (add symlink to tag-directory) is completely sufficient. i’d also be fine to limit tags severely in length (say 8 characters). i don’t use persistent tags, more like named collections.
and yes, star ratings and colour labels are already implemented, i have no interest implementing that again one layer higher up the #$%^stack. rating and colour labels are different, these can be used even more temporarily to perform quick filtering and sorting.
i’m all for implementing little things that have a clear use case in a typical photography workflow. i wouldn’t say i’m interested in writing or using the most accurate cataloguing software for archival purposes of cultural heritage imagery or so.
for general metadata i was toying with the idea of outsourcing that to some scripting language binding which could call exiftool or something python to extract and mangle the data as needed, somewhere really far from the core and only compiled in if requested.
Would you have any example out there, just to understand a bit how that would work ?
It’s hard to get away from libraries in this business. exiv2 does a decent job of it, provides an insular class containing whatever it found in the file container. In rawproc I use it for the essential metadata (well, for raw files I still use what libraw provides), but I also have an exiftool interface in line with what you describe mainly for the convenience of using exiftool. I even wrote an interactive filter to cull out tags, really handy when doing research for pixls.us posts… 
not sure what you mean by example? anyways i don’t
i was thinking something to extract the strings from files to organise them and then pass them back to the ui to display, or do other things (create named collections from it etc). maybe via lua scripting or a pybind11 interface. but i’m undecided whether i actually want a scripting language and if so which one.
vkdt optionally links against exiv2 in the raw input module, to get to some anecdotal information about aperture etc. all of the really relevant data i can get from rawspeed (and it seems decoding a few more tiff tags would not be overly complicated).
i removed exiv2 from the loop when creating thumbnails/importing images. too much speed impact.
I managed to build vkdt on Ubuntu Studio 20.04.4, using the latest Vulkan SDK and clang 12. It wouldn’t run on my AMD RX 5700XT video card until I also installed the latest amdvlk from repo.radeon.com. Looking forward to playing with this!
nice! 20.04 sounds like the rock bottom oldest possible environment to run it let me know how it’s going.
I am very interested in vkdt and have it installed on arch. I have played a little using older cr2 images, but vkdt does not seem to support cr3 images. Any pointers how I could accomplish this would be very much appreciated.
i managed to load cr3 images in the past using the steps in this post: vkdt dev diary, pt2 - #34 by hanatos
that assumes you compiled yourself from source, however: you need to use the rawspeed branch that supports cr3, the patch to db.h mentioned in teh post is already upstream by now and not needed any more.
cytrinox, the author of that branch, is also working on another piece of code that we could maybe use in the future to import raw images, we’ll see.
let me know if you’re trying this and need more assistance.
1 Like
Thanks for this. I tried it, and unfortunately it does not work any more. I get this error:
git remote add cytrinox https://github.com/cytrinox/rawspeed/tree/canon_cr3
git fetch --all
Hämtar origin
Hämtar cytrinox
fatal: arkivet “GitHub - cytrinox/rawspeed at canon_cr3” hittades inte
error: kunde inte hämta cytrinox
I know that my request may be a distraction, but I would be happy to try again.
ah, sorry. i think my url in that post was wrong. should probably be
git remote add cytrinox https://github.com/cytrinox/rawspeed.git
and then the rest looks good from here.
Thank you so much!! Now I have vkdt up and running with cr3 support!
I feel dim and dumb at the same time. Managed to pull from git and compile. VKDT runs fine and instantly shows ORF, CR2 and other raw files but draws a blank on any Pentax PEF files - I tried as far back as my K-5, K-70 but also my current KP. Even though I can see the models in my ~/vkdt/bin/data/cameras.xml file.
What am I doing wrong?
./vkdt /home/mike/vkdt/bin/P1120111.ORF
[gui] glfwGetVersionString() : 3.3.7 X11 GLX EGL OSMesa clock_gettime evdev shared
[gui] monitor [0] eDP-1 at 0 0
[gui] vk extension required by GLFW:
[gui] VK_KHR_surface
[gui] VK_KHR_xcb_surface
[gui] no joysticks found
[gui] no display profile file display.eDP-1, using sRGB!
[gui] no display profile file display.eDP-1, using sRGB!
[rawspeed] load /home/mike/vkdt/bin/P1120111.ORF in 381ms
[rawspeed] load /home/mike/vkdt/bin/P1120111.ORF in 392ms
./vkdt CMG15634.PEF
[gui] glfwGetVersionString() : 3.3.7 X11 GLX EGL OSMesa clock_gettime evdev shared
[gui] monitor [0] eDP-1 at 0 0
[gui] vk extension required by GLFW:
[gui] VK_KHR_surface
[gui] VK_KHR_xcb_surface
[gui] no joysticks found
[gui] no display profile file display.eDP-1, using sRGB!
[gui] no display profile file display.eDP-1, using sRGB!
[ERR] image could not be loaded!
Are the RAWs in the same directory as vkdt?
Yes.