What does today’s Adobe announcement of sophisticated masking tools in the next version of LR mean for Photolab?
Will PL ‘follow suit’? My speculation here is that they won’t and, although I would like them to try to improve on the Adobe offer (that’s what competition is about) I’m not sure it makes a lot of sense for them to do so.
One way of looking at it is that as of now both LR and CaputureOne have local adustment masks that are more advanced than those of PL. (I’m less sure about Luminar or On1 because I don’t use them.) As of the end of October, LR will take an even longer lead.
What the Adobe engineers seem to have done looks impressive. Among other advances, they have added pixel masking routines (they say for the sake of AI aids) into a parametric development tool, which seems pretty difficult. But it may bring the ‘best of both worlds’ to LR. (I imagine the XMP data output by LR will now contains big blobs of pixel data in addition to the record of the parametric adjustments. Maybe that’s the trade-off.)
PL already has adjustment masks, of course. The most innovative – ‘control points’ – offer a mix of luminosity and hue (and texture?) masking; although it’s sort of crude because the user can’t directly choose which of these parameters under the control point should determine the region to be masked and the masking (within a radial gradient) is akward, requiring multiple small-diameter masks (and ‘negative masks’) to achieve reasonably accurate mask-boundaries. LR masking routines are already more accurate (e.g. in locating relevant edges) and the so-called ‘AI’ controls will apparently take that to a new level.
PL masks are also individually controllable for duplication, opacity and inversion. But they cannot be blended like ‘true’ masks in e.g. a pixel-editor (I’m not sure if the new LR masks can be, either: I think not for the present, anyway).
My guess is that it would take a lot of research and development by DXO to equal or better the sort of things Adobe is promising (yes, I know… the devil will be in the details).
Then, C1 and LR (and On1?) have a strong lead, too, on other aspects of their tools: ingesting, cataloguing, image-renaming, exporting ‘recipes’, printing, and – by year’s end in C1 – merging for HDR and Panorama. None of these is trivial to implement in a parametric editor.
Will DXO forge ahead trying to keep up? After the apparent success of “Pure Raw” as a stand-alone and plug-in, I would be surprised if DXO is not already considering another future.
The ‘crown jewel’ of PL, in my view, is it’s demosaicing/sharpening/color-management/noise-reduction at the input stage. I do not think either LR/ACR or C1 can match this. Combined with DXO’s camera-body and lens modules (which must really be considered variable elements in these same routines), DXO/PL offers unbeaten image quality at the input stage of Raw development. The chief ‘non-linear’ adjustments it provides in the PL interface for creative adjustments — “Smart Lighting”, “ClearView” and “MicroContrast control” — are as useful as they are, I believe, because they can build on the results of the input/demosaicing routines. All of these creative adjustments in PL can be emulated, albeit with a little more effort, in other parametric editors and even more readily in pixel editors. But without the quality of the DXO input stage, the results will probably not be as good.
Given its singular advantage in ‘input processing’, DXO must be asking itself why it would continue to devote expensive resources to the competitive race to keep PL’s interface-based file-management and creative tools (the mostly ‘non-linear’ user-adjustments) up to the competitive ‘bar’ (and probably remain in an also-ran position). The success of Pure Raw demonstrates that it can leverage it’s greatest assets with less interface-overhead as plug-ins for other parametric development environments (LR, C1 etc) and steal the first place in that market. After all, it’s best-known product – the NIK suite – is already such a product.
Much as I would like them to continue to innovate and compete with the parametric editors and to steadily and solidly improve the PL suite/interface, I speculate that business logic points in the ‘plug-in’ direction and, consequently, ‘benign neglect’ for PL.
I hope I’m wrong. Am I?