I build vkdt for the first time and I have the same issue
Ubuntu 22.04
nVidia 1060 3G
you mean memory problem? i think the current version really only runs well with >=4G gpu memory.
if you’re adventurous you can try this:
diff --git a/src/db/thumbnails.c b/src/db/thumbnails.c
index eb04d39..1775af8 100644
--- a/src/db/thumbnails.c
+++ b/src/db/thumbnails.c
@@ -290,6 +290,10 @@ dt_thumbnails_cache_one(
clock_t end = clock();
dt_log(s_log_perf, "[thm] ran graph in %3.0fms", 1000.0*(end-beg)/CLOCKS_PER_SEC);
+ // XXX DEBUG free allocations to save memory:
+ dt_graph_cleanup(graph);
+ dt_graph_init(graph);
+
return VK_SUCCESS;
}
as a quick hack to always free thumbnail resources after processing (would be slower i suppose). maybe you can work within 3G then.
Wanted to try white balance with color picker.
When connecting the “picked” output of “pick” module to “picked” input of “color” module the pipeline seems to be updated but vkdt crashes just after.
vkdt-bt-79966.txt (20.7 KB)
I don’t see what I do wrong…
EDIT: if I connect first the input of “pick” module and then its “picked” output vkdt doesn’t crash.
EDIT2: sometimes I’ve to close firefox to let vkdt open a directory:
vkdt-bt-5860.txt (33.0 KB)
It becomes really easier to edit images. 
. About sharpening, I’ve found deconv. Is there anything else ? Any plan to steal diffuse and sharpen ?
yes, don’t do that (make graph inconsistent)!
but thanks for the reminder. i’ll probably have to make it more robust to broken/incomplete graphs once i start testing the history reset/replay feature.
firefox: probably eats away too much of your gpu memory.
deconv is just richardson/lucy deconvolution and can work really well at times (is also slow).
i don’t remember implementing anything else specifically for pixel level sharpness.
i was looking at diffuse/sharpen and think i should implement a faster version of it (given some time).
1 Like
The tagging feature is basic at the moment. I could contribute to port some how dt tagging. Would that be of interest for you ? If yes what should be the storage options (I guess you would not want of sqlite) ?
right. that is certainly a feature that will need some expanding. i don’t know the darktable interface here is particularly good. the one thing i’m certainly missing is the “reverse search”. like which image has which tags assigned to it/create lists for that. the obvious way of storing this data would be adding it to the vkdt.db text file that already stores star ratings and colour labels. there could be some process to keep that in sync with the actual tags (directories with symlinks), by reconstructing it from scratch or so.
there’s a question how often and how fast you’d need to access this data. i don’t feel like keeping piles of user-defined potentially long strings in memory.
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