Please could someone confirm (or tell me where to find in the git repository) the default (correct) order for the modules in the darktable pixelpipe so that I can put it back if I move one to the wrong place.
Never mind. I should have looked before asking (darktable/iop_order.c at master · darktable-org/darktable · GitHub).
Ok now to the point of my original post. I’ve spent the last week or so going over previous edits using the new filmic workflow.
I’ve mostly been reusing bits of my old edits and adding the new modules in place of old ones (like filmic in place of base curve). However, I’ve only just tried removing the history stack from an image and noticed that the module order has changed.
This means that I’ve been doing all of my edits using the linear RGB workflow, but with the modules ordered incorrectly (presumably in the same order as was defined for darktable 2.x). Is there a way that I can make darktable re-order my history stack correctly without starting from scratch or manually moving modules about in the pixelpipe?
I assume this is going to be a fairly common problem.
Only way I’ve found so far is to duplicate the image, discard history on the duplicate, then copy the entire history stack from the original to the duplicate. Presumably works because the order isn’t copied when you copy/paste the history stack (same as for styles). Bit of a pain to do it this way though.
If we take ‘filmic rgb’ as the pivot point between scene-referred and display-referred (I’ll ignore base curve as we’ll consider it depracated, though base curve has moved quite a bit in the pixelpipe), a lot of modules have moved from one to the other between darktable 2.6 and darktable 3.0 (i.e. between an image previously edited in darktable 2.6 and an image that’s newly-imported into 3.0).
Moved from scene-referred to display-referred:
- color reconstruction
- vibrance
- colorize
- color mapping
- bloom
- shadows/highlights
- local contrast
- color zones
- lowlight vision
- monochrome
Moved from display-referred to scene-referred
- rgb levels
- rgb curve
- sharpen
- lowpass
- highpass
- lut 3d
- channel mixer
I can’t disagree with any of these movements in general – they look like positive changes. But many of these modules will have very different effects in a 2.6.x-edited raw than in a 3.0-edited raw.
This means that you can’t come up with a workflow using the 3.0 modules and then apply the same workflow to a file previously imported via 2.6.x, with consistent results (even if the only thing you enabled in 2.6 was, for example, the crop & rotate module). The very fact that it was previously edited in 2.6 significantly changes the pixelpipe order.
I think we should recommend that users wanting to move to a new (3.0-based) workflow start from a fresh edit, i.e. discard their prior history, first. Those wanting to retain a crop should do so by duplicating, discarding and pasting as I’ve described above.
There will be a way: po/change iop order by TurboGit · Pull Request #3908 · darktable-org/darktable · GitHub
Looks interesting. Unfortunately I don’t use dev versions of darktable to do my edits (only for playing around in a VM) so unless 3.0.1 is coming next week (based on the 2.6.x release cycle it will be March) I will probably end up having to use my workaround unless anyone can suggest an alternative.
Plus the fact that if you’ve used a number of modules, the change in order will significantly impact the image (I’ve tried my workaround on a few of the images I re-edited in dt3.0) means you’ve pretty much got to start again anyway.