today’s news:
there is now a module to invert scanned film negatives. demo:
using the image from this thread.
also as you may have noticed the link to the docs above is now to vkdt.org, thanks to andabata vkdt has a proper domain+hosting now 
using the image from this thread.
7 Likes
Have tried vkdt a little bit, have a mixed feeling about it.
First of all, it looks very promising WRT image processing part. Fast, clean, neat. The implementation of compute-heavy stuff is really impressive!
As to UI, it’s rather disappointing ATM. Being quite low-level, it takes a lot more time to process a photo than using dt. Provided that there’s no convenient tooling neither to copy-paste the development steps to another photo nor to customize a default workflow, it becomes very time-consuming. I realize that it’s also a matter of habit, I’ve spent a lot more time with dt than with vkdt. Thus ATM I’d say vkdt is more a toy to play than a tool to work with. Yet a very funny toy! IMHO the UI needs much more love than it received so far to make vkdt a real photographer’s tool.
Also there are handful of bugs/weirdnesses I noticed.
- vkdt reports writing to
~/.config/vkdt/config.rcbut writes nothing there. It’s still 0 bytes long. - I don’t know how to stop
vkdtproperly. Alt-F4 closes the window but the process is still there and I have to kill it manually. - Probably it’s consequent to #2, but
vkdt now and then forgets the history, settings and last directory and starts clean with home dir again. - It doesn’t respect UTF-8 file names, I see question marks instead of Cyrillic dir names. Funny “Guess the tune” game:-) And BTW the font is too large in open dir dialog.
- I was struggling with vertical shots without any success.
vkdtdid not pick the orientaton up fromexif, trying to rotate it manually just crops the top and bottom parts, leaving the frame in landscape position. - And,
vkdtdoesn’t seem to useexifmuch while it might benefit from theexifinfo massively. - I also find the docs too short and sometimes a little bit cryptic. Given a quite specific UI along with some new concepts introduced, the full and clear docs are of much importance!
@hanatos, if you want me to file bugs on that matters for easy tracking, just let me know. I still consider vkdt worth time and efforts to be learned! Looking forward to the moment I’m able to overcome the dt development with it in terms of resulting PQ!
Thanks for your efforts!
2 Likes
what about copy/paste in lighttable mode?
there are hokeys for this too.
edit default-darkroom.i-raw. will also be picked up from your home directory. it’s in the howto docs in the undocumented section… also you can edit darkroom.ui to change the list of widgets in your favourites tab. some things you may like to bundle in a preset.
1.–3.: if you kill it it doesn’t write the config. since you seem to be using a bloaty window manager (alt-f4?), you may be in luck with this patch.
4.: this is nothing i would notice. it’s a matter of loading more characters in the font map, but i wouldn’t be able to test this with my data. should be a 1-2 liner in the imgui initialisation to fix this.
5./6.: but you are compiling with exiv2 support? see config.mk.defaults and hopefully your config.mk customisation thereof.
the crop/rotate ui is just barely there, that’s right. as probably the rest. as long as it doesn’t get into my way i’m fine with it though… this would probably be a good idea to formulate in a FR on github so i’ll be reminded to one day maybe work on it.
Yeah, this covers it partially but nothing close to dt in this regard yet. TBH I didn’t play with it much because vkdt discards all the changes for me every time.
Not practically acceptable in the long run, first of all because it may be easily overwritten by the next update and all the struggling will be lost. Then, I leave manual fiddling with the config files as the last resort. More or less frequent things ought to be available via UI somehow. Also please consider copying all these files under ~/.config and use only from there. It will give another level of protection if editing goes wrong. The originals should stay untouched AFAICT.
Practically presets did not look very obvious to me ATM, either. Probably I shall spend some more time with vkdt. I think, because vkdt, in a way, may be considered as a dt successor to some extent, it would be nice to have the UI as close as possible, to make learning curve not so steep. I don’t suggest to make an exact copy, not at all, but leave some continuation wherever it’s deemed reasonable instead. Otherwise users will be unduly confused, which in turn will have a negative impact on a user base. Because I think you’ve left the proof-of-concept stage behind, it’s a high time to give the usability matters some more love. If I can’t do whatever I want to the image after some reasonable amount of learning because I can’t manage to master the UI, then no matter how fast, reliable and generally good the processing itself is. So far I’m rather struggling with vkdt’s UI than really testing its processing capabilities. But even this way I’m impressed!
I wouldn’t call standalone Compiz bloaty in any way 
Anyway, the command/hotkey for exiting is a must IMHO.
re: 4. Please consider fixing it, and I’ll test.
I am AFAICT. vkdt shows some exif data (camera/aperture/iso…) but that seems to be it. No orientation, no black points or whatever. WB maybe…
1 Like
Yaaay great idea !
However, I do a lot of film scan using my Nikon D700 and there are some things to be done before that module position because it should be placed after all the camera corrections and matrix. 
hmm so just place negative after the colour module. maybe i should update the docs accordingly. didn’t think very deeply about this to tell the truth. just fiddling with my one single example image this seemed to make sense, but maybe it doesn’t. i wanted to have the exposure + messing with colours controls after the inversion. might require two instances of colour.
please be accurate. will definitely not implement all the many ways dt has to achieve the same. in particular not if it’s about gui dialogs. (selective copy can be achieved by a temporary preset, has very similar ui to select history entries)
an update will not write to the version in your home, which takes preceedence.
i disagree. on the other hand doing fs_copy in code behind a button instead of copying your example .cfg to the default.<input module> config files isn’t introducing a whole lot of ui complexity and clutter.
now that would be overwriting your stuff upon update. i see how it will make the place of config files more obvious, but the solution doesn’t seem so easy.
i think i agree here.
shows it where? under the histogram or in the metadat expander? there are three sources of common metadata: rawspeed (black/white/matrix), exiv2 (orientation, shutterspeed etc, dng matrices), and exiftool (configurable metadata expander).
You’re the driver. I only provide some (quite subjective) feedback here…
IMHO you don’t need to. I also think that dt’s UI is overly complicated in some aspects. Yet having an opportunity to do things with clear and convenient UI is a big advantage.
Won’t checking the mtime do the trick?
Both. After the last update vkdt seems to pick up the metadata properly. If I get the history shown and press “reset” button the orientation gets right now. I think it is solved.
Thanks!
now instead of 200k font file, this requires a 4.4MB one (and that’s not a complete set for all languages). since including this would triple the release tarball size i don’t think i’ll include it. might code my way around it so it works in theory and make the loaded font a config option, along with the obligation of the user to actually download it.
Wouldn’t it be simpler to provide opportunity to pick up fonts that are already in the system and leave builtin fonts as a backup?
try this. pull, build, and in your ~/.config/vkdt/config.rc set
strgui/font:NotoSansJP-Regular.otf
or something similar (otf or ttf). if the filename after the : starts with a /, it’ll be interpreted as an absolute filename (see /usr/share/fonts/truetype/…). if not, it’ll look in the vkdt data/ directory. if the file doesn’t exist, it probably just crashes
startup times suffer notably when loading a large font. certainly don’t want to make this a default for everybody.
It’s Roboto-Medium.ttf Tried other .ttf font with the same result…
And, I still can’t understand how to exit gracefully. vkdt still truncates config.rc to 0 upon exit.
I also see
corrupted double-linked list
message…
these need to be at least 4MB of size or else they will not contain your charset. for instance enter something esoteric here: Roboto - Google Fonts
make clean ?
hm. mine works, doesn’t speak japanese though:
had to download a specific character set of roboto and point vkdt to that file though.
this is the line in my config.rc
strgui/font:/tmp/Roboto-Regular.ttf
and got the ttf from here.
exit: ctrl-x or nowadays also the callback from your window manager should be followed.
Probably copy/pasted path introduced something unprintable somehow?? Or it’s a bug in parsing the string?? The file contained strgui/font:^R4^? upon closing. The manually typed-in path worked fine, but not every time. Tried few times, results are mixed bag. Weird.
Me neiter 
Also, Ctrl+x does not stop vkdt properly, either. Well, not every time:
$❯ pgrep vkdt
13256
…truncating config.rc to 0 again.
I’m not sure which signal Compiz sends on Alt+F4, and can not look because it seems that if I start vkdt from a command line, it does not stop it properly at all, so echo $? gives 0 all the time. You don’t process SIGTERM/SIGHUP, do you?
okay i think the main problem is actually the shutting down thing. i am catching abort/segfault, but not term. maybe i’ll have to do something more with glfwWindowShouldClose() to make compiz happy.
2 Likes
(@hanatos, slap me if I mis-state)…
vkdt is firstly about a radical change to the pixelpipe. It’s all in the GPU from ingest to export, and it’s crazy fast. No need for threading or tiling shenanigans; really, I think only needs one core to manage the data and shaders in the GPU. And, @hanatos knows well the darktable scene-referred ordering, and the current default network of operations reflects that.
Really, the current UI is just about presenting this concept. Took me a bit to figure it out, but I really don’t mind it. Again, I wanted at that pixelpipe, so whatever, UI…
One of the things I’m considering doing with my new-found time is poking around at a more-encompassing UI. Yeah, probably Qt/whateverversion, needs to do the basics like localization and language support, but I’m thinking it should look/work like rawproc… 
1 Like