Keywords in the XMP sidecars is okay.
But what about the possibilities to (partly) write different keywords to different virtual copies (like aspect ratio)?
The XMP only has place for one set of Keywords in the Standard way.
Whilst there is no definitive standard in this area the use of XMP files is probably to closest we get. Therefore I’d like to see PL embrace the use of XMP files for keywords rather consider using the DOP file as the vehicle.
At the same time I’d like them continue to be added to the database allowing keyword searching in PL. The benefit for me that images are displayed with PL adjustments applied.
2 Likes
The different virtual copies are part of the processing, therefore in the DOP file and / or the database.
Agree - I do not want to be locked into a softwae for my metadata. All DAM software out there will read and write xmp files for metadata. Having that in a .dop file is not a good idea.
4 Likes
I would like to have automated database and DOP file backup (you can call it maintenance).
As mentioned by others, IMatch is the gold standard in terms of how they manage it.
But a light version will do 
2 Likes
A ‘delete database’ button would do it for me.
All I would like is the ability to purge the records in the db for selected files, i.e. allow me to go back to a clean slate for those images.
Oh, and if PL was ever to write anything into a RAW file. That would be the last time I would ever use PL.
stuck
1 Like
How difficult is the implementation of a list of important settings in xmp , dop, database?
- used preset and partial preset.
- denoise type
- amount of Virtual copy’s connected to master.
- export settings, resized, watermark type of file (dng tiff jpeg)
- a memo field for typing reminders or other info by user.
Al this in a label, a image tagg.
Which would be visible in the exif, IPTC, section as extra information tab.
Main component no unique database items. All saved in dop or xml or file-properties and copied in database for quicker acces wile browsing in librarymode.
If PL is to write keywords, then it should do so to according to the internationally recognized IPTC Photo Metadata Standard 2019.1, with the option to write the data to XMP sidecare files, or to the image file, according to the preference of the photographer.
However .dop files should be retained for their current purpose - holding PL’s image processing data.
1 Like
IPTC may be standardized, and writing to documented formats like TIFF or JPEG or DNG is one thing, but writing to undocumented raw file formats is completely another. I certainly hope DxO never goes down that road.
1 Like
RAW file formats lack official documentation, but most are thoroughly understood - they’re mostly based on TIFF
(more)
But user choice is key - some photographers hate writing to XMP files, others hate writing to RAW.
1 Like
Yes, most look like TIFF, but they’re reverse-engineered. The consequence of getting it wrong on read are that you can’t open the file, or can’t process it. The consequence of getting it wrong on write can be to render the file unreadable, or unreadable for certain applications, which you might not discover until much later.
If the formats were meant to be written by applications then they would be documented.
Edit: Don’t any of the proponents of writing to raw files do backups? Having to backup modified raws requires much more space than backing up sidecars.
No engineering required, just understanding - it’s pretty simple (see exiftool.org)
Of course, but the risk is tiny, provided the software tool is competently written.
The risk of the XMP file being lost or accidentally deleted is very much higher, but I’m sure I’ll never convince you.
As long as PL provides both options, we can both be happy
I hope that all photographers have multiple backups!
Writing keywords directly to the raw file was standard for Nikon in CaptureNx(2) and ViewNx(2). They stopped with adding keywords directly to the raw file that a few years ago, probably when the Nik software was sold to Google, but I’m not sure.
I just downloaded a Z6 raw file and opened it in ViewNx. I was not able to edit it but I was able to add keywords to the file. The Z6 file has a different structure as what was used at the time the Z6 was brought on the market.
I keep my raw file since 2008. All have keywords.
No. No backups of the files before adding keywords.
IPTC/XMP are made to be added to the file or as sidecar.
George
2 Likes
Oh yes, very simple.
Just look at the huge number of tags and notes about them that exiftool documents, and every new camera that comes out requires investigation. It takes DxO and others a long time to support various new cameras just for read. Asking them to write to the formats as well isn’t going to speed things up exactly. Even if they were to just wrap exiftool they then create a dependency that needs to be kept in sync, and hope that exiftool continues to be maintained.
Exiftool exists. If people want to use it to modify their raw files then why should DxO spend time reinventing the wheel? Should they also spend time ensuring that they can read raws that have been modified by various other tools, with possibly varying degrees of competence. You’re adding a lot of complexity to something that’s complex enough given the sheer number of different variations, TIFF-based or not. I think DxO would be better off not sinking time into it. (Although I admittedly think the same of much of the DAM-like functionality.)
Of course, we all know that software is bug-free.
Not in my experience. I’ve never lost a sidecar.
See above.
But XMP is an ISO standard and is documented. writing keywords to image files is a tried and tested procedure and, as long as software developers stick to the essentials, the risk is absolutely minimal. By default, ExifTool creates a safety backup of the original file until the changes are made, only, optionally, deleting that after the modified file is successfully written.
For PL, this is a very valid point. Whether you use XMP embedded in the image file or a separate XMP file, there will normally only be one place to write the metadata for all versions. Given the current standards for one metadata block per physical file, I’m not sure if per-version keywords would be possible, since versions is a PL concept, recorded in the .dop file.
1 Like
Again, XMP is a standard, most raw file formats you can imagine writing it to aren’t even documented publicly. Big difference.
1 Like
Most raw files do have a tiff shell. Writing iptc/xmp is adding that to that shell.
George
1 Like
Hello,
I don’t know all the things you are talking about, but as a user with a little bit of technical skill I ask myself if it would be a good idea to make step by step.
- There are standard EXIF Metadata like is described here http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf. This standard data DPL must be able to read/write, and for working with the search function of Photo library DPL must be able to search with search criterias (and/or/not…) my photo collection. If this works well I will be happy.
- Photo Metadata User Guide (iptc.org) would be the basic for the next step working with metadata/keywords writing to XMP files.
- Database design and function I’m not interested…for me as user it has to work
. I must have the possibility to backup and restore (it’s implemented), by closing DPL it would be fine if i got a message to backup ( like LR does it with the catalog) - I would be glad if DPL could separate program data, user data and user config, and if I would be able to choose the location where user data and user config will be saved. At the moment I can only choose this for database and cache. Presets, Plugins … are anywhere in the program folder and/or in the user profile (Windows system…don’t know where in Mac OS). So for me it’s not so easy to backup these files if I made custom presets, palettes, workspaces. Watching forum threads I noticed that also for users working a long time with DPL it’s not easy to remember where all the stuff is stored.
If anybody is here knowing about terminalServer/citrix environments some years ago, she/he knows how difficult it is to bring a software not designed for multiuser environment to run (this only for a synonym seperating data)
That’s the sight of someone who likes to take photos, want to keep his data safe and easy and not interested to crawl or dig for parts of the data.
So keep on discussing, I will go outside because here the sun is shining and the air is clean.
Please keep all in good mood, stay healthy and enjoy the coming christmas days 
with your family
best regards
Guenter
1 Like
Correct.
Well I agree that DxO shouldn’t have moved into the DAM space. But now they have, they need to meet international standards, basic user expectations and rock-solid reliability to maintain their good name.
As a careful photographer, I would hope not. But if your collection eventually gets passed on to someone else, are you confident that they will know what a sidecar is, that they won’t, say, delete them because they don’t show up as images? I wouldn’t be.
My family collection goes back to at least 1883. Many of the photos lack ‘metadata’ because they’ve become separated from the frames or albums that probably once held such data. Where I do have metadata, it’s mainly where someone has ‘embedded’ it - by writing directly on the back of the photo. What I have found or reconstructed is now securely embedded in the image files in perpetuity.