Ok, did some reading about what Exif, IPTC XMP is and how we can use it.
(I don’t have a large amount of images every month so i never bothered to label and tag my raw files other then folders with date and place. I do tag and label more detailed the processed files as a Jpeg. (i use the PSE Organisor for this.) Which has its quirks.
- changing quarded/watched folders outside the application does corrupt the library and repairing is time consuming. (so i always keep every thing out its grip until i am satisfied and only then i place the folder with new images in a special “import folder for DAM”
Why i am telling you this? Well before i place it in this folder, the EXIF data is the only image data in the jpeg or rawfile. The sidecar which DxO provides is a development status file name accordingly to the rawfile.
For me if i can write in the EXIF of the Jpeg/tiff or rawfile in that list of details some things like place and subject(s)
(date and such are already in there) that will be enough.
So why XMP then? eh i think the same reason as why using a DNG (not lineair).
In time it could be happening that the coding of a old specific rawfile can’t be read anymore and your image is lost in time. By decoding it in a general international container like Digital Negative Graphics its suppose to be accessible for ever.
So XMP is the DNG for the metadata of the image. (as far as i understand.)
Knowing this, yes if you build a DAM make it working with XMP-sidecars. Because it’s your archive for “livelong” managing images you can’t make again.
But as i understand building and maintaining this library cost computingpower which slows down the actual developement of groups of files. (Like to read every time again and again the hole index of a large booklibrary to got the indexnumbers of the shelf of the new books before you can walk to shelf with the latest books to see which one you like to read. That’s rather stupid if you know where that shelf is and you can walk directly to it because you bin there every month.)
It just slows you down unnecessary. But if you like to find that book you read years a go and you only know its a detective called Luke something and it was happening in Tokio around 1969, Yes then that slow index comes in handy.
So as i see a good working DAM.
- Automated indexing ónly when i want it to happen. (when i archive my rawfiles whom are worthy to keep. (that’s why i hated LR’s active folder “Stop doing things i didn’t ask you to!!!”
) - A DAM tab and a folderbased tab choise. (So i can choose if i want to search with TAGS and keywords or just jump to a folder i want to see.) And DAM-application is only running if the DAM tab is active.
- XMP seems to be read by all other applications the same so crossover to other applications and edit it elsewhere will update also in the original DAM. (This is crucial because you don’t want to do it twice or have different data in different tools/applications.)
- It has to be smart enough to overcome changes made outside the application without burning to much processingpower every time you start it up. And i think that’s a challenge to build.
So maybe DxO can build a DAM READER (XMP reader) inside DxO PL (so if you open a folder it reads only those XMP-sidecars and shows the information only when select a image) and make or use from a other DAM designer a DAMtool (editing XMP data) standalone.
Just keep images and sidecars connected wile moving around in the folders in DxO PL Organisor, so next time you start up the DAM it updates its indexlog.
Use the DAMtool to find and open folder or group with DxO PL organiser. or just don’t bother and open directly organisor and click on desired folder. 