hm the question is of course which granularity makes sense for the ui. the modules you see in this ui will themselves consist of a set of connected nodes, which in turn correspond 1:1 to GPU kernels. so what you see here is an abstraction already. for instance the llap module does quite a bit of laplacian pyramid decomposition in a handful of cascaded nodes internally. so if you expose the splitting/laplacian fusion at the module level then only because you expect users to mess with the individual parts in creative ways…
this is done by moving a connected input pin into the void (this is the imnodes repo, not my code/idea). output pins can be connected to multiple different inputs, so you can’t delete a link this way on the other side.
sounds brittle to me. there are so many potentially overlapping lines, not sure i like this. also it sounds like there’ll be a modal dialog popping up when you innocuously move a node. i’ll probably port the insert before this node button from the pipeline config tab for this purpose.
oh absolutely. i was planning to port some hotkeys + add module and insert block to this view.
your crash recovery files are the backups of lighttable (db) and darkroom (cfg) work in progress that might not have been saved. the actual crash report is missing but you posted two .cfg
Well, forgive my NodeRed reference but it has this feature that when putting a new node Z on an existing link between nodes A & B, the previous link becomes dotted and instead shows, in dotted line, what would the new link A<->Z<->B be if the user release the mouse click on this place. Otherwise, if you move the node again to an empty place, nothing happens A & B are still directly linked and Z is still in the void !
But I understand that you would not want to trickle into the nodes code itself or reimplement new functions in it
… of course this is one of the operations that only works if the node has a unique input and a one main output channel (can’t have more inputs because i couldn’t plug them in and has to have one main output so i know what to connect to the next node). in simple imaging pipelines this is often the case though, so it’s worthwhile thinking about it.
Hanatos,
(forgive my many messages and questions)
Is there any way to emulate vibrance, and if so with which nodes ?
I like using vibrance (as opposed to saturation) as it has less “in your eyes” of an impact !
I’ve looked for “vibrance” is the module list (CTRL+M) to no avail.
Thanks
there’s no implementation of that particular formula. but if you apply the gamut.pst preset, the colour module will switch the saturation to something that follows lines of same hue when changing saturation. also it will respect the combo box to limit the effect to a certain gamut. if you set that to srgb for instance, it will never increase saturation out of this set. since it compresses gradually near the boundary the effect may be similar (keep already saturated colours where they are, only boost the moderate ones).
hm stack trace is unintelligible. do you remember what you did to trigger it? can you still trigger it with new master? i fixed a thing or two in the meantime.
Playing again with modules … and this time with AB .
May I dare suggesting a visual cue to indicate which part corresponds to input A and which to input B ?
Usually, it’d be named “Before” & “After”, but since the user can build the graph he likes, ‘before’ & ‘after’ will probably be wrong 50% times, hence this idea to see A&B :
As for the granularity question, take a look at the awesome work happening for the blender Geometry nodes. They expose very fine granularity, more advanced nodes such as llap can in that case be expressed as a group of nodes. The ability to group nodes (and group groups for that matter) and store these groups for reuse has proven extremely powerful over there.
right. i wanted to streamline this a little bit by using labels on the history stack (ctrl-h) and some automatic generation of sub-graphs and connection of an a/b module. gui overlays are on the agenda too, just takes a bit of time to do it (the rest of the ui is autogenerated from text files, that’s fast to do).
i think the difference is that i’m not trying to do a low-code interface to programming, but primarily a workflow thing to go through many images quickly. also, the nodes are exposed if you want to program, you can include them in any other module by calling them by full name (llap/assemble for instance). this is on a programming level though and probably not useful for photography.
also i really care about execution speed, and granularity has a big impact here. after every node/compute kernel, the pixels will be carried to global memory, and will be carried back to the SM when the next kernel starts. this means if the kernels are super fine grained (+ or / or so) it’ll waste a lot of memory bandwidth. an extreme example is the richardson lucy deconvolution which i initially implemented as a sequence of many div and mul kernels and later as a single kernel deconv which iterates directly in shared memory before writing back to global.
Would there be something in here that could be fairly easily tweaked to match or come closer to vkdt?? Or wishful thinking…
/* Graphs : histogram, navigation thumbnail and some items on tone curve / @define-color graph_bg @grey_15; @define-color graph_exterior shade(@graph_bg, 0.9); @define-color graph_border @grey_05; @define-color graph_fg @grey_75; @define-color graph_fg_active @grey_95; @define-color graph_grid @grey_05; @define-color graph_overlay @grey_50; @define-color inset_histogram alpha(@grey_65, 0.50);
/ Primaries selected for visual legibility across a variety of
gamuts, and to combine to pleasing secondaries. The combination of
all three must either to either the same number or >= 255 to
produce a neutral overlap. */ @define-color graph_red rgb(237,30,20); @define-color graph_green rgb(28,235,26); @define-color graph_blue rgb(14,14,233);
…maybe to illustrate, here’s what vkdt-cli generates for a very simple linear graph using --dump-nodes to visualise the finest level. nodes.pdf (22.0 KB)
i find that not very convenient to work with.
