hanatos / vkdt

raw photography workflow that sucks less

Home Page:https://vkdt.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

node position

cherob67 opened this issue · comments

commented

Good morning,

I would like to make a suggestion regarding the position of the nodes. I think it would be easier to add these positions to the .cfg file following the list of nodes, links between nodes and parameters.
When you make a backup of your photo (or video) collection, the advantage of this solution is to include all the information related to the saved photos.

Same thing for .pst files (presets) or default pipes (ex: default-darkroom.i-raw).

Another wish: when customizing the default pipe it would be better to save the modified file in the directory ~/.config/vkdt so as not to lose the modifications when reinstalling vkdt. The modified file is to be used as a priority thereafter.

One last question: I couldn't use the blocks. Are they definitely replaced by the presets?

Thanks !

heya, let me try to answer that:

  • node positions: are kinda gui stuff, so i was hesitant to put them into .cfg files. the backup argument is valid though, and arguably grabbing the files from a directory containing only cryptic hashes is not easy. so putting into cfg may not be a bad idea, have to think about it.
  • by now all the files should be read first from ~/.config/vkdt and only after that in the system wide install directory. that should work for your default pipelines, colour profiles, presets, and blocks too.
  • i certainly don't want to put presets/blocks into cfg files. that's not what you meant?
  • blocks: since i deleted the pipeline config tab in darkroom mode, the only way of adding them is to select a module on the graph, then click the insert block before this button in the right panel of the graph editor:
    2023-03-19-103757_742x230_scrot
    which, after disentangling the node positions a bit, results in this (i.e. works here):
    2023-03-19-103733_797x838_scrot
    what is the issue on your end? does it not work? i used the draw block, i.e. a shipped builtin.
commented

Thanks for your answer.

directory ~/.config/vkdt : oh ! i don't think it was possible for the default pipes. I try and it works fine.

blocks: yes it works: the reason was i had tried with ctrl-b and this didn't work.

presets and blocks file: I just think to be able to add the position of the nodes that compose them in the corresponding pst or cfg files. For now, in the node editor, when adding a preset or a block, the nodes appear piled up in a corner of the screen.

okay i see what you mean. that makes a lot of sense. probably have to think about a way forward how to store gui stuff. i like the idea that presets/blocks bring their gui portion too. and that you can open a .cfg like a project file, similar to blender: stores configuration of gui too, might include window arrangement etc in the future (imgui docking style, dual monitor/popped out window). maybe it could have a "gui only" section that can safely be skipped.

I think a [gui] section is quite alright, can be ignored when not needed.

However, the node editor needs heuristics to consider if the [gui] section is missing, for an initial layout.

I'm thinking similarly for less-obtuse forms of configuration, such as a simple toolchain where the node connections are assumed by the serial order of tools. A fairly simple toolchain2cfg() routine can do the translation to a form the processing pipeline loves...

yes such an implicit initial ordering is in place in this line of code:
https://github.com/hanatos/vkdt/blob/master/src/gui/render_nodes.cc#L402

it just goes from left to right through the module list.

the next branch inits from positions that have been read from file.

probably the thing with presets and blocks is that they have to be merged into the current graph, i.e. potentially move around original graph nodes to make space and then move the preset/block stuff to the free spot. maybe a simple thing like selecting the bunch after inserting could help move them around manually too.

the cfg file format now includes module positions as (optional) first class citizens right in the line of defining the module. i think this closes this particular issue, the other two related ones should cover the other aspects.