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.
please try
./vkdt ./CMG15634.PEF
(note the second ./)
i wanted to fix this some time ago but forgot because i don’t usually do this so often (run from same directory).
Nope, whether with ./ before the filename or with the filename with full path, for any of my Pentax PEF files going all the way back from my current KP to the K-70, K-5 (and beyond), vkdt will not load it. It also will not show any PEF raws in a directory if opened with [Open directory]
Any other raws like ORF, ARW, CR2 open fine whether with or without path.
haha sorry then i probably already fixed the bug i thought was causing it. if you compiled from git, could you please try again? i didn’t push updated packages yet but i think i have pushed a patch for PEF files.
Yep, that did the trick indeed. All PEFs showing and loading fine. Super!
1 Like