This looks like a bug (or some very odd option). There is an export, but I dont see an import.
Iâm not sure what you are trying to do. The module screenshot represents a layout option you created. This layout is reflected when you are using dt to edit images. The layout does not apply a workflow, it just helps your workflow.
As for the XML format (also for @cedric) - feel free to skip this:
Summary
the XML is well-formed
description is empty
blendop_params is empty
Darktable uses the same XML format (I could say âschemaâ, but thatâs a specific thing in the XML world and darktable does not indicate one in the file) for all modules, whether they are processing modules (most, but not all of which support blending) or not.
The format is quite general. Cedric is right in a way: if we had a schema for each module type, there could be human-readable (and verbose) parameters, like group and so on. Instead, the parameters are in that op_params tag, which contains base64-encoded binary data, which can simply be loaded right into the moduleâs internal parameter area (itâs platform-independent, though, endianness is handled correctly). Even if it were human-readable data, usually there is very little a human could do with them anyway, and this is more efficient size-wise and speed-wise (no complicated XML parsing is needed to load the data), and development-wise (whenever a new module parameter is added, code is written to ensure backward compatibility, but no new XML tag needs to be added to the schema and the XML reader / writer).
So, donât worry, your export worked, and can be shared with others or saved to a separate location and it can be re-imported just fine.
Even with a general schema, you could use âkey/valueâ pairs for the parameter (something like
<parameter name=âxâ value=âyâ />). Very verbose, and does the reader know what ânameâ stands for, or what âvalueâ means? Internal names and value ranges donât have to be the same as UI names and ranges. E.g. angles need to be expressed in radians for most math, I guess most users feel more at ease with degreesâŚ
As for storing a workflow this way, that looks hard: a workflow is also an âorder of operationsâ, not just the modules you use (or may use, not all images will need all modules).
XML schema doesnât enforce this; you can have deacriptive attribute values without schema. We could also supply schema for the current document type that darktable produces and the base64 values would still be valid.
In XML, you canât really have a âgeneral schemaâ â the idea doesnât really make sense. In XML, a schema generally expresses how an XML document is formed, generally via document constrains. Instead of âgeneral schemaâ we have the idea of well formed or valid XML. The âkey/valueâ pairs are called âattributesâ in XML.
Right, I should have said âA schema used for all module preset exportsâ. And I know about attributes in XML . I just didnât want to get too technical in this context.
In this case, I think that while there are ways to store individual parameters, the notion of âhuman-readableâ is abused: yes, you could read the text (syntax), but what does that text tell you (semantics)?
Sorry for the naming. It was chosen in a way that I can recognize easily that this was created by me.
I am doing notes in a textfile. I simply would like to remember the modules, whcih I often used and not typing everything.
These modules are used in the beginners video https://youtu.be/ZUc6LOzg_Nk I am sure I will change this later. Is it possible to rearrange the modules in the listing?
No question, coders know better which module has to be used in the export first.
Maybe the word âworkflowâ describes best what I mean.
You see the screenshot. I put some modules there. I would like to see them there in a way I use them.
Examples:
Denoise, I do at the end. It doesnât make sense to do it, when I crop the noisy area.
Levelling I do before cropping⌠If heavy levelling is needed cropping before is useless.
So I would like to have my modules in a special order which is my standard workflow, not all used with every photo. There are some modules, where it doesnât matter if used before another.
My personal workflow order doesnât have any influence how the photo is computed at the end.
But the order in the module panel is the pipe-line order and you use that panel to change the pipe-line order. (which is useful or even needed in some situations, LUTs come to mind)
So allowing users to rearrange the available modules as they want it means you need another way to change pipeline order⌠(I know there is a tab to show the active modules, but having the modules only there in pipeline order is confusing as well, as the order would be different in the other tabs).
Iâm not advocating this as a change but I think that is one way of thinking (as you mention) but not all people think or work that wayâŚso for example for me a perfectly acceptable and logical way to work would be to have the active modules tab be the focus and control of the pipeline and to have that tab be the only place that pipeline changes would be made just as they are now and then to have custom module groups be separated and unbound from that order reflect how I would like to organize and work through my modules either by name or alphabetically or whatever⌠Iâm fine with how it is and can adapt to whatever is in place but I have never really understood why the modules in custom or select groups need to be in pipeline order
One reason could be âno one ever thought of the alternativeââŚ
Also, treating one tab differently for the layout may complicate the code, now itâs just one order for all tabs, and âjust keep only the modules you needâ.
)
. I just didnât want to get too technical in this context.