Great questions Joanna.
Keith, I’m with you on moving metadata to XMP but there’s no good reason for DxO’s own proprietary development information to be cluttering up XMP and some good reason for it not to be there (other programs may either scramble or erase it, as it’s not a known standard).
Personally I’d like to see DxO thrown their hat in the DAM arena and I’d even be willing to pay them to do so. But only as a separate application which has to stand on its own merits. Photolab should remain a standalone RAW developer which plays well with photo management tools like FastRawViewer, ApolloOne, Photomechanic Plus, iMatch, Photo Supreme and even Lightroom and Bridge.
I’m somewhat ticked off that 1. a database is obligatory (I don’t want it) 2. metadata is not written into XMP sidecars but proprietary .dop files. Anything which moves Photolab to playing worse with others could push me to look for alternative, more open tools. If DxO have sufficient resources.
Right now, there’s some kind of severe performance issue in my copy of Photolab 3 (3.3.3) on Mojave 10.14.6 when the open folder has more than a few dozen images. Hence my first priorities are like very similar to @m-photo Marc’s: stability and performance.
For big enhancements like those @pierre5018 suggests, I’d like to see them developed as extra tools:
Some nice to have features : panorama stitching, focus stacking. However external applications exist, and they can be invoked from PL.
Panorama stitching could either be its own module or part of a big ViewPoint upgrade. Focus-stacking also seems like a separate add-on like ViewPoint (but doesn’t belong there). What would be good about keeping these extras outside of the main program it would mean they would have to pay their way. If not enough people are willing to pay for a focus stacking tool, then those resources should be spent elsewhere on tools like an advanced panorama and stitching tool.
DAM is the “extra” project which worries me the most. There are two reasons for that:
- DxO’s announced tendency is to try to shoehorn it into the existing Photolab application.
- DAM is an infinite blackhole. DAM involves two-way file syncing (the toughest task in IT) and an incredible mess of conflicting standards.
Photomechanic have been building photo triage and metadata tools for twenty years. It took them five years to bring their DAM add-on (Photomechanic Plus) to public beta. It’s good but it has problems. Some of the other DAM builders are capable coding teams: some of them have been at it for more than ten years and I have to say the results are not attractive (I test drove Photo Supreme on someone’s recommendation this year and found it clumsy and ugly at least on Mac OS X: java or Linux interfaces – the otherwise solid open-source Digikam – usually look lousy on OS X).
There’s so much other urgent work to be done on Photolab starting with performance while DAM will take up all the resources and more, threefold, and still not be competitive for three years.