Project

General

Profile

Feature #9085

Modular Workflow and Compositor Interface

Added by Brylie Oxley almost 7 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
Darkroom
Target version:
-
Start date:
11/26/2012
Due date:
% Done:

0%

Estimated time:
Affected Version:
System:
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Workflow Compositor

The Workflow Compositor would provide a modular, or node based, interface for users to construct chains of image processing functions. Each node represents an input, processing, logic, scripting, or output module. Nodes have input and/or output connectors, and are 'wired' together in arbitrary order.

Examples of Nodal/Modular interfaces

Blender3D Composite Editor
Nodebox
Synapse - node based compositor

History

#1 Updated by Johannes Hanika almost 7 years ago

fastest way to use dt's modules inside a node graph is to write an openfx (http://openfx.sourceforge.net/) wrapper and load it in nuke (http://www.thefoundry.co.uk/products/nuke/).

#2 Updated by Richard Wonka almost 7 years ago

What a nice idea!. This would be a bit more than just an alternative to the history stack if I understand correctly?

#3 Updated by juan luis fernández gallo almost 7 years ago

It would be quite interesting but... is it really user-friendly? I mean, DT is a very nice "gate" to new Linux users that want to try digital photography instead of Lightroom or other privative software; and simplicity is something important for a fotography workflow application. Maybe something like a layer system would provide the same functions as a node-based one, IMHO.

#4 Updated by Brylie Oxley almost 7 years ago

Richard Wonka wrote:

This would be a bit more than just an alternative to the history stack if I understand correctly?

Yes, it would be similar to the history, but would allow branching. Users can create a sequence of actions, with logical points such as
  • 'is the histogram positively or negatively skewed?' :: Apply a curve based on tonal balance.
  • 'is there clipping in the highlights?' :: Use cliped areas as mask for subsequent processes.

#5 Updated by Brylie Oxley almost 7 years ago

juan luis fernández gallo wrote:

simplicity is something important for a fotography workflow application.

The modular workflow can be optional and may actually simplify repetitive aspects of photo post-processing.

I would also like to encourage users to share their processing workflows, so that we can build on each others' experience.

#6 Updated by Johannes Hanika almost 7 years ago

Brylie Oxley wrote:

Richard Wonka wrote:

This would be a bit more than just an alternative to the history stack if I understand correctly?

Yes, it would be similar to the history, but would allow branching.

no. history is a timeline, not a dataflow diagram.

Users can create a sequence of actions, with logical points such as
  • 'is the histogram positively or negatively skewed?' :: Apply a curve based on tonal balance.
  • 'is there clipping in the highlights?' :: Use cliped areas as mask for subsequent processes.

this sounds more like a job for boucman's lua branch or an image processing library for python than anything gui related.

that said, i really think you're looking for nuke and not dt (and even nuke will probably have a single `import raw' read node with a static pipeline).

reordering modules for raw processing is not something i'd like to leave for a user (at least without expecting that he's going to shoot himself in the foot). run tools/iop_dependencies.py to create a nice dependency graph. violating any of these will cause unexpected behaviour of all sorts.

#7 Updated by Brylie Oxley almost 7 years ago

Johannes Hanika wrote:

Yes, it would be similar to the history, but would allow branching.

no. history is a timeline, not a dataflow diagram.

Yes, we often use timelines to conceptualize history. This would be a timeline with branches, similar to a river delta.

this sounds more like a job for boucman's lua branch or an image processing library for python than anything gui related.

I want the user to have the freedom to experiment and build image workflows using graphical elements such as boxes, connectors, and sliders.

that said, i really think you're looking for nuke and not dt (and even nuke will probably have a single `import raw' read node with a static pipeline).

I am looking for Free and Open Source image processing and compositing tool(s), with a graphical user interface.

reordering modules for raw processing is not something i'd like to leave for a user (at least without expecting that he's going to shoot himself in the foot). run tools/iop_dependencies.py to create a nice dependency graph. violating any of these will cause unexpected behaviour of all sorts.

The processing modules are already used in various logical or illogical order by users. We learn by experimentation, trial, and error. It is alright that we mess up sometimes.

I am not exactly sure that allowing users to choose sequential processing paths using a modular interface will be significantly more error prone, or inherently impossible. Can you please explain your thoughts a bit more in depth regarding the dependency graph?

#8 Updated by Tobias Ellinghaus almost 7 years ago

Brylie Oxley wrote:

Johannes Hanika wrote:

[...]

that said, i really think you're looking for nuke and not dt (and even nuke will probably have a single `import raw' read node with a static pipeline).

I am looking for Free and Open Source image processing and compositing tool(s), with a graphical user interface.

Have you tried blender?

reordering modules for raw processing is not something i'd like to leave for a user (at least without expecting that he's going to shoot himself in the foot). run tools/iop_dependencies.py to create a nice dependency graph. violating any of these will cause unexpected behaviour of all sorts.

The processing modules are already used in various logical or illogical order by users. We learn by experimentation, trial, and error. It is alright that we mess up sometimes.

Currently there is no way to change the order in which the modules are applied. So no, they are not used in various orders.

[...]

#9 Updated by Brylie Oxley almost 7 years ago

Tobias Ellinghaus wrote:

Have you tried blender?

Yes. It is a great example of a compositing interface.

Currently there is no way to change the order in which the modules are applied. So no, they are not used in various orders.

That is an interesting prerequisite. Running the image processing modules (sharpen, curves, denoise, etc) in different sequence can give dramatically different results. How does Darktable determine the sequence of modules to run?

Also available in: Atom PDF

Go to top