The proposal is to introduce a concept of base images and derived images in the workflow.
Currently, it seems that Photolab starts over the process if raw development even when a virtual copy is created ans is left unchanged prior to saving to disk or when exporting to application.
The first part of this proposal is to retain in memory, behind the scene, the basic development process such as conversion from raw and lens corrections. Those initial steps should be computed only once for a collection of images derived from the same source. The additional post-processing would resume from a common checkpoint. This would speed-up processing of virtual copies, and further processing via external applications such as Nik collection. Additional processing such as light and color could also be retained when virtual copies differ only in repairs or cropping.
The second part of this proposal is to let the user create a sequence of image transformations with branching. The image transformation tree would be explicit, editable, and reusable for batch processing.
When a series of transformations is used in PL3 or PL4, the image browser is difficult to grasp. For example:
A raw file is processed for opical and denoising, creatingt a dng file
The dng file is branched in PL by creating virtual copies
Each main or virtual copy is processed creatively with different parameters, perhaps using external modules such as Nik collection or different settings and corrections in PL.
Some or all images are written to disk, using various file formats and multiple resize options.
As this happens,the computer is busy while executing the transformations.
In the above example, a jpeg file can both be the output of a transformation and the input for another one. The status of the transformation is difficult to track, because it is attached to a file and not to a transformation.
For reference
Picture Window Pro 8 implements non-destructive editing in a tree for rganizing the workflow. User can modify any editing step, and create branches with different settings.
Details
for compatibility, the existing Photolab interface for duplicating any conversion and work on them independently could be kept in the user interface. The image transformatiin tree is an addition that does not remove any existing capability or make it more complex.
the image transformation tree allows a user to name its nodes, such that the workflow leading to an image is understandable to the user, just like the local corrections can be renamed in PL.
browsing the image tree is visual. Think of it as a 2D browser extension to the existing linear image explorer
the relationships between source image, intermediate results and final images are obvious when looking at the tree.
the status of a transformation is clarified (clock to indicate in progress, some other symbol to show completion)
for computer geeks, the first part of the proposal is to significantly speedup processing of images derived from a common base similar to “makefile” automation.
Not a fan of this idea. The simplicity of being able to duplicate any conversion and work on them independently is something which I really like about Photolab. If I had to think in terms of image trees every time I made a version, it would lead to headaches and confusion.
Don’t forget you can create intermediate versions for your experimentation. What would be very nice is if DxO would allow us to rename those duplicate versions (even if we could only append to the original name and not remove it). That way we could make some quick notes in the version name (visible from the contact sheet, unlike a dedicated notes field).
Thanks for considering external input, Pierre. Many people who suggest features are unwilling to do so. Your proposal is better now but still seems a level of complexity which befits RAWtherapee (which is the only other RAW developer technically at the same level as Photolab in its ability to create wonderful final images from high ISO shots, but is much more difficult to use) than Photolab.
The user interface problem here is that the tree system would require yet another completely different view of the photo browser: tree view which only shows one family of images from a common master.
Between you and I, I would actually like this feature myself, but I’m very technical and already build flowcharts and mindmaps in my work, as well as developing user interface. I don’t think it would work for enough people. And even for someone like me who likes the feature, I wouldn’t use it often enough to justify its creation and the distraction of its existence. Every extra one adds to an interface takes away from the artist’s ability to concentrate on the purity of his work.
How do I handle a modern DSLR then? I set it up very carefully and afterwards only touch aperture, shutter speed and ISO. Oh occasionally I turn stabilisation (IBIS or OS, don’t use digital stabilisation after much careful testing) on. Almost all auto-enhancements (D-Lighting, lens correction, de-vignetting, etc) are turned off and I turn them on within Photolab or within Davinci Resolve if I want them. At the point one no longers must think about the tool that one can create great work.
I might be wrong. I’ll be interested in what some of the other Photolab users current or former professional interface or software developers think of your proposal. There’s quite a few of us using Photolab (thanks to the attractive interface and clear workflow I believe).
I would be interested in your feedback on image trees as found in the tool Picture Window Pro 8. You can install it for free !
It allows the user to define branches and invoke a chain of transformations on the go, and to go back along the pipeline.
For your information this is what the export menu “Export as DNG (denoising & optical correction only)” does starting from DxO PhotoLab 4. This will apply demosaicing, denoising and optical corrections as its name suggests. So you can do the heavy operations once beforehand, then open the exported DNG and apply lighting and color, without losing quality compared to doing all the operations at once. The identical quality with this intermediate export is a major difference with the other DNG export mode (all corrections).
This allows exporting with DeepPRIME during night then working on the preprocessed DNG faster when you have time behind your computer. The side-effect is that you’ll see DeepPRIME result in the main viewer of DxO PhotoLab 4, instead of just the loupe.
Another major difference with PhotoLab 3 is that PhotoLab 4 is now able to read the DNG that is has exported (whichever DNG export mode you choose), even the ones exported in earlier versions of PhotoLab.
However I can see two limitations with respect to your initial request:
The pre-processed image will no longer be able to receive changes on denoising or any optical correction based on DxO’s calibration data: at best some optical corrections palettes will remain usable but in manual mode only.
Nik Collection applications do not support DNG files, so this workflow is only valid within PhotoLab or other applications that support DNG files.
The first part is an optimization, not directly visible to the user. I’d be surprised if no one at DxO thought about that already. Especially now that there is a dedicated master which is the root of your assumed tree.
But it is not a feature so I wouldn’t vote on that.
The second part seems to be much too complicated. For sure it depends on the type of the user. I believe many users would be either overwhelmed or completely ignoring this feature.
Affinity Photo has a history with forks: if you go back in history and continue editing a new fork is created and you can switch between different forks. But for software like Affinity Photo, where also order of changes is critical, it makes much more sense. Still I see it mainly as an enhanced undo to save me from loosing work completely, not as a regular way of working. I’d rather use deactivated layers to experiment while keeping some edits. And in PL this is what virtual copies are good for.
By “this software”, Christian, do you mean PhotLab ?
If so then it’s not correct to say; “order of changes is critical”.
It actually makes no difference in which order we/users apply corrections/tools … PL applies them in a specific, set order. For more details on this, see here.