It works for DNG too. JPEG, TIFF and DNG are all XMP-compatible and gets the metadata written into XMP-headers.
@Stenis
I don’t know if you answered me, anyway I didn’t use the index function. I just opened a folder with some NEF files, when metadata synchronization is active all files that have a dop sidecar get the rating reset to 0 and xmp sidecar modified accordingly. I can reproduce the issue.
i stil would be happier to mark folders for indexing in a tree as active folders.
so when i in library i don’t see all non image holding folders to scroll through. i get too much folder to see i don’t need in a image edit program.
a simple “show all” checkbox can help to overcome missing folders to mark them also for indexing.
…having “favorites” for folders. Something nice to have…
4 Likes
We already have a Recent Locations list on the File menu but, unfortunately, that only shows the leaf folder, which is less than useless if you have a hierarchy of year/month/day and, of course, several leaf folders with the same day number.
The has been mentioned before and is really simple to change but still no movement 
1 Like
i need to test it but the “syncronise action” is only done when you leave the image and selecting an other. just check en uncheck checkbox synchronise doesn’t work.
(i am very fond of more detailed control over how sync would work. i do like a hierachical data transfer setup. and “plain synchronising” isn’t that. So unless i am absolutly sure about the “chain of command” i am very carefull using “synchronise”. No affence to the builders of the DAM. I know it’s in evolving state and needs to be tested in daily use to find the loopholes and errors and prop the leakagespots.)
In order to gain control over creation and editing of sidecars, one needs to switch off all automatic actions as shown in the screenshot below. Then, control is quite granular and with the user - as is responsibility.
Granularity: Separate menu entries for read or write of .dop and .xmp sidecars.
3 Likes
Forcing users to manage metadata themselves amid confusing and unreliable results is not a solution. DxO should step up to the plate here and handle metadata sensibly. This means reading metadata from the XMP and writing the metadata back to the XMP. Metadata has no place in either the DOP file or the database.
“What? You want to undercut the database, you monster!”
No, no, no.
The database can store metadata for quick display but at any point the photographer decides to edit the metadata, the metadata must be refreshed from the XMP.
“But what if the photographer doesn’t want XMP files in the RAW photos directory?”
If a photographer uses metadata, s/he should have to live with XMP files. XMP is the standard for metadata and DxO has no business breaking standards. The same short-sighted fools who don’t want .dop files to store their editing corrections could perhaps turn off both .dop and .xmp and go entirely database driven.
When these photographers lose all their edits and metadata in a creeping database corruption incident (poor DxO support having to try to unravel the broken databases individually for these unhappy individuals: could be averted by simply requiring that data be stored in both database and sidecar) they will see the light. Ironically many of those same short-sighted individual will then bitterly blame DxO for allowing them to lose years of work. Best for DxO to make it very difficult to run database only with loud warnings along the way.
There are some right decisions to be made with the handling of metadata. A confusing mess of options which all end in the result of the loss of or inconsistency in metadata is no solution.
3 Likes
Re PLv5 doco …
Great job on the update to PL User Guide, Gilles … It’s really good to (finally) have some explanation for the Resizing Mode options … At last, I can now see the intended difference for Fit vs Rotate to Fit … 
Regards, John M
That’s what i proposed few months back.
along with the explanation text change to get clearer view on what’s happening.
same as the pull down menu’s:
export what? (when writing) or import what? (when reading)
all? or only selected? the manual would be clear about it as it seems but i don’t want to read it every time i am confused.
it should be “read selected” and “write selected”
(if that’s the action)
Simple clear and every one knows what to expect.
2 Likes
…considering that we can have more than one sidecar per image, DxO could rename the “Sidecar” menu to " .dop sidecar" in order to improve differentiation between .dop and XMP.
1 Like
Metadata should never be stored in the .dop sidecar at all which would make the housekeeping, syncing and interface much clearer and much easier.
1 Like
I believe the idea of so doing is so that you can add metadata to virtual copies, not just to the single XMP for the RAW. And, for those who detest the database, it makes sense.
1 Like
No reason the application could not write to the single XMP. There’s little reason to have separate metadata for Virtual copies (it’s the same photo). Notes on processing could be a separate field stored in .dop and database.
Making complex and unreliable what should be simple and straightforward.
Well, if I understand correctly, Lr writes adjustments to the XMP. Are you suggesting that PL does the same? It would inflate the size of the XMP and possibly make them unwieldy and take more time to read and search.
No, you didn’t understand correctly, Joanna. I didn’t say anything about adjustments, which live very happily in .dop files. I said all metadata belongs in .xmp files. I also accounted for speed in searches and other data reading:
The database can store metadata for quick display but at any point the photographer decides to edit the metadata, the metadata must be refreshed from the XMP.
When a photographer decides to edit the metadata of an image, the milliseconds it takes to read an .xmp file from an SSD are of no consequence. There would be no need to reread .xmp files just to perform a search. A photographer should be able to force a reread of the .xmp files. Or PhotoLab could do so intelligently by keeping timestamps on modifications of the .xmp files in the database. When PhotoLab detects that the .xmp files have been modified since the data was stored in the database that could trigger a background read of the .xmp files in that folder.
There are ways to keep metadata up to date and in sync. Simplifying sync means avoiding it by making a single version canonical. The canonical version of metadata should always be the .xmp sidecar as that’s where the other well-behaved photo applications which manage metadata store metadata.
@StevenL I’ve just solved most of your issues with metadata sync and inconsistency in the metadata between applications. I’ll accept a working version of PhotoLab 5 on Mojave as payment. You’re welcome.
2 Likes
From some test I did this evening it seems PL5 uses dop sidecar as the primary source for metadata, but this is crazy. When reading dop from PL4 there is no rating/keyword so every developed photo gets its rating set to 0
xmp sidecar should be the primary source, then if PL wish to save also to its database (and dop) ok, but in any case it should never overwrite the xmp unless the user changes rating/keywords from Photolab. In this case PL should update the xmp,database (and dop).
2 Likes
Alec, I have just one comment:
When having another DAM-system as metadata owner it’s not a good idea to allow Photolab to update the XMP. That should exclusively be left to the external metadata owner. Photolab shall in that case only read XMP and ought to be configurable to let the user chose whether Photolab shall be the master or not. If a user choses to use an external DAM instead of PhotoLibrary the File -Metadata - Write ought to be inactivated in order to block bidirectional metadata flows. En the IPTC and EXIF-fields in PhotoLibrary out to greyed ut and inactivated.
1 Like
I’d like it be possible for write/edit capability to be disabled/enabled in preferences. That said, I disagree about not allowing Photolab to edit data. The whole point of portable XMP data is for all the applications to touch the metadata without changing its structure.
Of course, the mess with hierarchical keywords which you and @Joanna are exploring in detail (very informative posts, thank you both) indicate no cross-compatibility between any of the major players. It makes me happy that I’ve avoided hierarchical keywords. When I saw Adobe push for them in Lightroom I knew ahead of time it was a death trap of the Microsoft “Embrace, Extend, Extinguish” kind.
Outside of hierarchical keywords, most tags should be shareable among major applications. Title/headline, description/caption, creator, location, event, etc. I’d enjoy the opportunity to be able to occasionally title and caption images in Photolab while doing most of the metadata batching in Photo Mechanic. Of course I’ll never get the chance as DxO offers next to no support for macOS (OS -1 is not support, it’s a kick in the face, DxO has fallen in my opinion into the category of non-professional hobbyist software with this policy).
Alec, there seems still to be some operability problems between Photolab 5 and Photo Mechanic and that´s why I am really reluctant to start updating from both applications despite I use flat keywords in both. I wonder still what Photolab means with having some EXIF-elements open lik the rating. Photo Mechanic is strictly IPTC still. Just one example. I also would like to be able to disable write/edit in “Preferences” and I also would like to have it optionally to allow a keyword list built during indexing of the files. You have to be able to turn that off if you use structured keywords and for those who does it should be possible to import tabseparated files like we can do in Photo Mechanic and Lightroom. If you have two programs that integrate it is a must to be able to migrate even the keyword list.
Personally I see no problems just maintaining everything only in PM Plus. When developing the images in Photolab 5 and exporting to derivates like JPEG-files Photolab 5 handles the metadata perfectly fine.
Sorry to hear about your compatibility problems with Mac and Photolab.