Just curious, why parse when you can use different s(0-4) flags and get the following:
$ exiftool -s4 filename.JPG -lensinfo
18-55mm f/2.8-4
or
$ exiftool -s2 filename.JPG -lensinfo
LensInfo: 18-55mm f/2.8-4
Edit: I’m sure you’ve thought this through already 
you can… and in fact -s2 might be a readable alternative:
it’s just that it’s not aligned at the colon. i found that to be a bit too cramped for easy reading. happy to change the default though if we find something that makes most people happy.
let me check my notes, I may have stumbled upon a parameter which adds a tab between the column and the output. I’ll try
Edit: nope, the -t separates the label form the output with a tab, but it’s not more legible…
I do similar with exiftool in rawproc. The command line is a configuration parameter, and I let exiftool do its thing. The default I supply is -G -S, groups metadata types and does Very Short output, one line. In the dialog box that displays the output, I made a filter field that cuts down the viewed lines in real-time, quite helpful…
yes it’s great that i don’t have to link another library for this… it’s really low profile. i don’t parse / filter the output, it goes straight to TextUnformatted()
in the good old tradition that a release needs to be obsolete by the time it comes out, i started to work on some new features in parallel:
I have two dumb questions. I am in WIndows right not so I don’t have vkdt running. but I did get it going on the PopOS linux distro that I have installed.
I had some trouble trying to build it so I had to resort to grabbing a binary. I guess I can go from the name of the binary but is there a way when running vkdt in the gui to expose the details of the version…
Second dumb question. I was trying in the add module/filter section to pull up a list of all modules in the box so I could experiment… I wasn’t able too…
I’ll have another go next time I jump on that install.
Looking forward to having some holiday time to poke around and get aquatinted with how things work…
I’m planning to poke at vkdt source code in the coming new year, will look at how imgui would support real-time filtered text. I used to use exiftool ... grep ... a lot in bash, now I just drag the file to rawproc and use exiftool from there…
troy_s would love it. Couple of years ago, he asked me about incorporating node graph in rawproc; I coudn’t find the motivation to do such for a simple straight-line list…
I may be in a minority here, but to me this looks awesome. (In addition to the processing speed) To be able to plug in the histogram wherever the user wants alone would be grand, but the complete flexibility of such a directed-graph pipeline…ooof 
.
ah, things like this don’t appear to me (which is why you explicitly need to ask). vkdt --version will output some information, but requires a console.
if you have an empty filter in the ctrl-m modal dialog that would be the list. or else of course the list in the documentation here.
cool! looking forward to more bug reports 
if you want to compare to my version, it’s here. it’s not so much an imgui thing than a libc thing. and there’s a check for static imgid in place that avoids constant real time reprocessing of the text (it’ll only call exiftool etc once if you select another).
oh but it’s always been a graph and the histogram you could always plug wherever you please. same for colour pickers etc. here’s another example with three raw files as input:
pipeline config tab was always a full node graph editor, only the one here is left->right and in the tab it’s bottom->top:also, this is not a mockup screen, it’s functional (see nodes branch on github, go to darkroom mode and press the hotkey for nodes view, default ctrl-n, esc takes you back). the graph was always functional of course, but this interface works to position nodes spatially and connect/disconnect.
the thing about mostly a linear list is my concern here, too. this is quite an overblown kind of interface for something that most of the time will look like the linear string in the screenshot above. also working with many pictures i don’t usually want to dive into graph configurations. i suppose the only way out is to offer both ways to interact with the graph.
Somehow for me that is a big difference! The list with, forgive the negative phrasing, “connector noodles” confused me so much so that I did not realize that it is the equivalent of the graph structure that is now clearly visible. I feel like a fool. I’m sorry! That makes vkdt so much cooler actually.
If you take masking (hand drawn or parametric) into account, I think the 2D layout will be much more visually clear though. If people don’t use localized edits, then the linear layout, maybe even with a fixed pipeline, is simpler.
Just adding a casual OMG !!! 
Suddenly, the flow graph/chart is muuuuch clearer than the old pipeline config tab I used to try avoid when I could !
You’ve been on fire lately, and so is vkdt ! 
Also, I did notice the line with exif in darkroom ! 
Thank you very much for the tips… I love your histogram color brightness and intensity. I wish I could duplicate this in DT. In DT, I find them just too light and washed out so its hard to see certain elements clearly …at least my old eyes…
hah, thanks for your enthusiastic replies everyone. i suppose this means i’ll have to mainstream the node view and probably also include it in the release.
this has to be just a matter of a few constants in what must be pretty much the same code. for reference, i’m using a gamma correction step, but i forgot where is the same code in dt’s code base.
Hi @hanatos
May I make a suggestion for a beta release ?
For JPEG (cannot say if it is needed as well for other file formats):
have, out of the box, a more feature-rich pipeline so that new users easily find the tools they are mostly used to find, such as ways to tweak:
in whatever order is, generally, making most sense (I know this is user-definable for a reason )
Does this make sense ?
Thanks
so in the jpg default pipeline (note that you can customise it by putting your own version of defaults-darkroom.i-jpg into ~/.config/vkdt/) contains the colour module which can be used to change saturation, white balance, and exposure. it also contains llap (shadows/highlights/local contrast) and filmcurv as disconnected modules. i recently removed them from the default jpg pipeline, because jpg are usually already cooked and you don’t want to extra-grade them by default.
given that i recently removed stuff from that pipeline i don’t really want to add it back… maybe i should write a howto doc on custom default pipelines instead.
One of the first use cases I can think of is one that I know you and I have discussed before - an implementation of tonemapping via exposure fusion.
darktable’s was tied to the basecurve as an underlying tonemapper, but ideally, tonemapping via synthetic exposure fusion would be implemented as:
Split graph 3 (or more) ways
Different exposure for each branch
Global tonemap/scene->display (legacy basecurve, jandren’s sigmoid, and filmic are some examples here) for each exposure-shifted input - the key difference being to be able to do it with any intermediary scene->display global tonemapper
The actual Mertens fusion/blending (after which the graph would regain linearity)
Played with nodes, very nice 
A few remarks:
Got a crash though :-/
Trace and more attached. I hope this may help.
vkdt-crash-recovery.cfg (2.4 KB)
[vkdt-bt-414460.txt|attachment]
vkdt-crash-recovery.db.txt (29 Bytes) - remove the .txt
(upload://yMX7bSvEInGcE2uoBRVKBY8veSH.txt) (36.0 KB)
vkdt-crash-recovery.cfg (2.4 KB)
Thanks for the great feature
GLLM
