Your answer is far more dire than even I expected.
Trying to tie metadata management to the conventions of a single OS is perhaps the stupidest idea I’ve ever seen. I’ll alert you to the existence of Linux, iOS, iPadOS, Windows of various flavours, Android.
What kind of dunderhead would try to dictate to the world that every photographer must run Apple computers.
Apple has botched Aperture (great program with fatal flaws interacting with other programs) and created the greatest monstrosity to afflict photo management, Apple Photos. Only a fool would follow Apple’s lead in photography.
Frankly I’m surprised you are allowed to persistently promote your own software in these forums. It’s a huge conflict of interest and basically hijacking a community for personal gain.
Anyone considering using your software is pushing their images into an incompatible locked box which makes photography worse.
That’s not what I was suggesting and, having been a consultant software engineer for over 30 years, working on anything from Windows 3.1 to macOS Big Sur and with dBase, Clipper, Pascal, C, C++, Delphi, C#, SQL, Objective-C and Swift, I am very well aware of the problems involved in the enforcement of any kind of standards, especially if it means allow other companies to more easily offer alternatives to one particular company’s standards.
Apple?
That’s as maybe, but one thing they have done particularly well, although little known, is metadata management; possibly because it is so transparent and doesn’t interfere with just getting on with whatever task you are currently performing.
You mean in the way that you constantly promote PhotoMechanic and denigrate DxO for not catering for your old operating systems?
Be careful. That is a libelous statement that you cannot support because you haven’t even looked at it. As I said previously, my app is 100% compliant with XMP, MWG and Dublin Core standards. What it does do is offer the option of writing metadata to RAW files if a user so wishes - according to @Stenis, just like PhotoMechanic
And, as I have also explained, I do not create a locked box because I do not use a database and I facilitate both the reading and writing of XMP files, which are freely interchangeable with any other app.
When I started my app, DxO didn’t have a DAM. As far as the public knew, PL5 has only just acquired one and I have worked very closely with DxO on the metadata side of things to ensure that, should someone want to use my app as an alternative for metadata management, there are no incompatibilities with what they are offering.
Our apps are targeted at different primary markets. PhotoLab is primarily aimed at providing the greatest image editing experience that I would pay anything to have. My app is primarily aimed at providing a non-hierarchical browsing experience, with the ability to create smart searches, whilst also providing a one click interface to image editing software that was initially and exclusively aimed at users of PhotoLab.
In this migration scenario the precedence is given to the value set by the user in DxO PhotoLab 4. We tend to keep user’s editing untouched; otherwise, many people will be left unhappy or even angry. Believe me, we learnt this lesson very well
I’m not sure that I understood you. Could you please clarify your scenario behind this statement?
The point here is that unique metadata can be added to virtual copies. As there is no any physical file behind them, .dop sidecars look a natural choice to store their metadata there so you will be able to access it years later.
You should differentiate migration and normal use scenarios. They are handled differently by DxO PhotoLab 5. What exactly scenario you are writing about here?
And I would totally agree. It is perfectly logical. And, just as sometimes I would de-normalise a database for performance reasons, so .dop files are a “necessary evil”
Although, from time to time, I do wonder if it would be possible to add the editing/version/etc data to an XMP file? Please sir, don’t hit me
You are right here. However, let me explain in details how .dop files are handled in relation to metadata because things are slightly more complicated than people may think here. You know that there is a master image and optional virtual copies for it. Each of them can have its own unique metadata. However, only the master copy is backended with a physical file. Taking all of these into account, we write all metadata into .dop sidecars (for simplicity) but read only those which relate to virtual copies. It means that for master copies we prefer to read metadata from the physical image and omit metadata from .dop sidecars. Does it make things clearer now?
Do you mean merging current .dop sidecars into .xmp sidecars by creating custom sections with a proprietary PhotoLab information? The benefit that I see is that there will be only 1 extra file. However, I also see a few disadvantages too:
for JPEG and similar formats XMP is embedded that means that its size is restricted (if I remember correctly, by 64 KBytes). You can easily check it, if you try to copy a Bible, for example, and paste it as a comment in some of the IPTC tags using your favorite DAM solution;
other software may not respect custom unknown sections in XMP and easily overwrite them zeroing all your creativity efforts.
Indeed. I think sometimes we forget that not everybody uses PhotoLab to process RAW files.
How would it sit if only RAW files had their metadata stored in XMP sidecars, whilst leaving other file types as they are? Although I can see that being quite fun if a user selected a mixture of RAW and other files
Don’t use other software?
Nah! leave it as it is and write the metadata to RAW files
I easily understand your confusion here and can explain it in a few words: DxO PhotoLab 4 and its predecessors had… 3 different ratings
EXIF rating (read-only, yellow)
XMP rating (read-only, yellow)
PhotoLab (or .dop) rating (read-write, white)
The XMP rating took precedence over the EXIF one and the PhotoLab rating was the king of the hill; however, it could be removed, i.e. reset to XMP / EXIF. We got rid of this nightmare in DxO PhotoLab 5 and now there is a single rating everywhere that comes from image metadata (I think that XMP over EXIF is kept preserved). No more yellow stars anymore So it’s not entirely correct to directly compare DxO PhotoLab 4 with DxO PhotoLab 5 because they rely on different rating logic.
I only wrote about a migration scenario. I performed a test with a folder containing some nef files, most of them have a rating. Rating was set using AcdSee, I never set rating or any other metadata using PL4.
Some of the files in this folder have been developed with PL4 so there is a .dop file but it doesn’t contain any rating.
When I open that folder with PL5 all files that have a .dop file are listed with rating 0 (see screen shot in my first post) while they had a rating 3 in PL4 (the xmp sidecar contains a rating 3)
I suppose that PL5 when reading dop file from PL4 doesn’t find rating and assume they have a rating 0
In this scenario if I check the option to syncrhonize metadata what happens is that when PL5 opens the folder sets a rating 0 also in xmp sidecar erasing the rating 3 stored there.
I lost ratings in several folders full of photos before to understand what caused the issue. Luckily AcdSee keeps a copy of its data in a private xmp namespace so using ExifTool I was able to recover them.
Note: before doing this tests I also deleted the database in both PL4 and PL5, so I started from a clean situation.
I was not aware of the File menu items to read/write. Now I know that I must keep synch disabled and after PL5 has indexed a folder I must select all photos then File->metadata->read and I get all my rating in PL5
In a normal use scenario I still prefer PL4. PL5 uses the metadata stored in the dop file, if I change rating/keywords from an external program it doesn’t read them unless I select them then go to the menu File->Metadata-Read
I know that dealing with metadata is a real mess, but selecting photos then file->metadata->read every time is really boring.
It would be much better if there was a setting for who is using an external DAM, so PL5 always gets metadata from xmp sidecar
In addition it would nice to explain in the user manual how PL5 handle metadata, which is the primary source and how synchronization is performed. At the moment user manual is very generic and doesn’t help.
It’s impossible. For example, DxO PhotoLab 3 cannot render an image from DxO PhotoLab 4 with the DeepPRIME applied because it simply doesn’t have a physical code needed for that. And there is a lot of such scenarios.
This is an achilles system of the current system. I’d suggest that DxO could add a notes field which is .dop stored which covers any notes about each virtual copy. There’s very little reason that a virtual copy would require different metadata. All other metadata would be common and stored in the single .xmp.
I could see how a photographer might want to rate different versions of an image differently. It’s a mistake to allow that. The virtual copies should share the rating with the master. What might help here is a preferred version for the virtual copies. It’s basically Apple Aperture’s stacks system which was used for multiple very similar shots (common in fashion and product shots, for that matter in landscapes). Something similar could work very well for virtual copies. Virtual copies would be stacked by default and would unfold only when the master file is chosen. At that point the photographer would be able to rank the virtual copies in order in the stack. Technically speaking the master would also be a virtual copy. I.e. the preferred processing for the master would be the virtual copy at the top of the stack.
The XMP rating took precedence over the EXIF one and the PhotoLab rating was the king of the hill; however, it could be removed, i.e. reset to XMP / EXIF. We got rid of this nightmare in DxO PhotoLab 5 and now there is a single rating everywhere that comes from image metadata (I think that XMP over EXIF is kept preserved).
That’s a logical and welcome improvement.
It’s impossible. For example, DxO PhotoLab 3 cannot render an image from DxO PhotoLab 4 with the DeepPRIME applied because it simply doesn’t have a physical code needed for that. And there is a lot of such scenarios.
Good to know. For a year I was stuck with PhotoLab 3 on laptop and PhotoLab 4 on desktop. Pre-grading in PhotoLab 3 and then reopening in PhotoLab 4 on desktop wasn’t always a perfect match. It was better to just grade in PhotoLab 4. I was also frustrated by the poor performance with healing and local adjustments in PhotoLab 3 (much better in PhotoLab 4). If we are reopening sets done for instance in PhotoLab 2, it’s important to plan enough time to review tonality and colour before re-exporting.
I have no financial or personal stake in PhotoMechanic or its success. I didn’t even particularly like the software before version 6 as the interface was hard to look at. Metadata is hard and CameraBits looks that difficulty straight in the face and deals with it.
The fatuity of your statements about old OS is ludicrous. Mojave was introduced in 2018 and Apple’s own active update program for Mojave only ended this week. Mojave will continue to get security updates for another three or four years via Xprotect, Gatekeeper, MRT (Malware Removal Tool) and TCC (Transparency, Consent and Control).
If you’d like a job selling Apple computers, I’m sure the Genius Bar in Paris is hiring. Your bilingual skills and enthusiasm would be much appreciated. It’s all new computers there and the latest OS so you’d feel much more at home, than among photographers who have work to create and would rather not spend their time troubleshooting OS/app incompatibility issues every year.
offer the option of writing metadata to RAW files if a user so wishes - according to @Stenis, just like PhotoMechanic
CameraBits strongly discourages choosing to do so. Metadata applications rooting around in RAW files is a recipe for long-term disaster.
Adobe DNG Converter for that very reason from its origin actually includes the untouched original RAW file inside a DNG to make sure that photographers won’t lose access to the original image.
A “simple” metadata converter which risks the long-term integrity of a photographer’s archive by writing to the RAW originals seems a terrifying bio-hazard to me.
That said, there is space for a much simplified version of PhotoMechanic which works well with PhotoMechanic, Adobe Lightroom, CaptureOne, DxO PhotoLab and other applications which work non-destructively with .xmp files.
FastRawViewer’s developer does a very good job building independent and simple and affordable software for the photo space (FRV is for triage and not metadata despite some very basic metadata features). FastRawViewer is cross-platform, lightning fast and compatible with everything. Even the just released v2 runs on any OS back to Sierra 10.12 on Mac and Windows 7 as well as the latest versions. Iliah Borg does not need the “very latest version of OS X” to be able to get out of bed in the morning or manage photos. FastRawViewer should serve as a model for anyone attempting to build a metadata editor.
DxO could (has?) build such a metadata editor into PhotoLab, although I’d like to see the Library module become its own independent mini-application like FilmPack and ViewPoint with its own sales. Bundling is okay but Library should pay its own way and not interfere with core PhotoLab functionality. As Library grows larger and more complex it should be possible to not see the Library functionality at all when using PhotoLab.
I’m encouraged by Alex’s answers and the care DxO is taking not to allow PhotoLab’s handling of metadata to disrupt the use of external DAM and metadata solutions.
I tried to reproduce this scenario locally and I confirm it. I consider it as a bug so we will try to fix it as soon as possible.
It’s true only if this .dop sidecar is being migrated from a previous PhotoLab version. It’s not needed, if the image is brand new to PhotoLab.
It’s not that simple to implement because you have an ability to modify metadata in PhotoLab. What we should when you modified metadata in PhotoLab (without any sync) and then modified it in a third-party application? There is a kind of a conflict.
This is exactly why PhotoLab should write metadata changes immediately. The whole idea of sync is rotten at the core. For most applications which support true sync, making sync work quickly takes up more development time than the rest of the entire project.
If there’s another app which hoards data and then overwrites what was changed in PhotoLab, that’s a workflow issue for the photographer. It’s not DxO’s lookout. As PhotoLab doesn’t sync but writes immediately, your hands are clean.
As I remember, any of DxO PhotoLab activation code implies 3 legal activations, i.e. you can have a legal copy of PhotoLab on 3 different computers. Do you know that?
Part of the issue here Alex is that the settings and their results are a complicated maze. DxO could be more prescriptive here and a little less accommodating.
If I were DxO, I’d hide these settings and set them to intelligent defaults with a clearly described workflow which really works. You could write a special article for advanced users including guidelines on how to access the hidden settings.
What’s frustrating is that DxO has more or less done this very well but left a lot of room for users to break things and knock their metadata out of sync. Expecting most users to understand metadata sync properly is asking a lot, perhaps too much. It’s one place where one can help them make the best choice.
you can have a legal copy of PhotoLab on 3 different computers.
Thanks for asking. Activation was not the issue. Support for High Sierra 10.13 was the issue. Now I’m locked out of PhotoLab 5 completely because of the OS -1 support policy. All my Macs are limited to Mojave and I don’t intend to replace Mac Pros at €12000/piece with equivalent configuration to be able to run PhotoLab.
I would not assume this taking into account that we have tens of thousands of customers and each of them is a unique person
We allow to modify any metadata tag for a virtual copy. As a rating is a metadata tag, it’s true for it as well. There is no any special treatment for ratings in this respect.
We were thinking a lot when we were introducing this option. Finally we decided to go for the safer option taking into account how many existing customers will migrate their image libraries into DxO PhotoLab 5 from the previous versions. If we would set this option checked by default, they could lose their edits applied before. Summarizing, we took this decision because we believed that it was a less evil than the opposite.
Please sir, don’t hit me 
