XMP implementation for database purposes in the future DPL DAM

We have some post about the use of XMP files so the database info can be read by other types of databases also. I not experienced with DAM as a transparant system for several applications So i used a DAM only for my end product in PSE. I did all the tagging/renaming/redating/undertittle in PSE’s Organizer and used a simple system for my other files. Date /where what.
But sins DPL has implemented a DAM i have two places where a DAM is active.
This needs a new approach i think. So to all DAM guru’s :wink: can someone bring up a speed tutorial about this? A specially with DPL involved?
This is what i know:
1 a camera produces a EXIF attachment which a rawprocessor uses to gain some basic info.
2 some rawprocessing applications can be used to add personal info in the EXIF attachment in order to have better information when the time proceed and searching is about keywords to find your image. like location of taken image person of such in the open fields of the EXIF.(This is stil no XMP) (PSE can write its database things in the actual windows property file which filles the “labels” what are the taggs i did in PSE.)
So in order to get tagging and extra info transparent for all database organized applications i need to create a XMP?
1- do i have to do this before opening DPL so its using that as info file instead of EXIF?
2 as far as i understand DPL does nothing jet in tagging so a XMP isn’t extra value for now

So what do i need to do in the future , when tagging and EXIF data altering is possible on the RAWfile site, to keep my managing system crisp and clear?

1 Like

If you are using an other DAM, that has private metadata in its database, that you want to share with PhotoLab, then exporting this metadata to XMP (for raws) or embedding the metadata to files (for RGB images) is the way to go. If PhotoLab once supports reading tags from XMPs (sidecars and embedded) and uses the identical tag names as your source DAM, the search in PL should work automatically, after the folders have been indexed.

Once PhotoLab support altering tags, it will update the tags in its database first. But at the same time it should also allow to write this metadata to XMP, so that the environment sees the metadata changes. The XMPs should be created automatically on user triggered writeback, if they do not exist, or updated otherwise.

The first question to answer is: Do you want to tag RAWs? It depends on your personal preference. I do tag raws and their exports, because I want to keep things together and want to search for raws. Others tag only their exports and put their raws into separate archives after this.

Well, there are some keywords other then date which can be help full.
But in general my old system of year /3months, / month or event and place with shooting date is enough.
But in this case when DxO is using a DAM on the raw file side it has to be tranferable to the endproduct metadata otherwise you are doing t twice. (Entering tags i mean)
until then it’s more a search function.

This would be step one for a clean system.
It would be great if DPL can create XMP’s to transport tags and personal info along the processing path into the final DAM for final images.
step two would be a system that find similair named XMP’s in different folders to equal information. (But this has also a down side if it goes both ways.(risk on overwriting original exif data)) So step one is enough for me. (with a manual function to create one or batch create xmp’s)

Ok did some youtubewatching and here at around minute 6.58 its shows the structure. (forget about the fact its Ad.cofcof related it’s just for visualizing for me to understand.

And i am convinced IF DPL DAM can provide a preference to start for RAW+XMP to make a transparent single sidecar readable for all databases the DAM in DPL can actualy work as a backbone for furter DAM’s on the final image site. (it creates a XMP-file instead of a DOP-file.)
So the Dopsystem needs to be rewritten i think, (open the .dop in a textreader like notebook it’s a settings list.)

Maybe it is keen to make a preference for using DOP or XMP (DOP means all tags , adjustment settings and EXIFmetadata are only for DPL DATABASE and stays on the raw file side. and XMP means all exifmetadata, adjustmentsettings(if RAW, exportTIff or DNG) and tagging are transportable by export in tiff and DNG.(adjustsettings) and jpg (all exif and tags but no adjustsettings)
Dop sidecar keeps your database entry of DAM only for DPL
XMP sidecar is a universal metadata container. which can be changed by other applications (risk ad wrong entries to ruin DPL settings)
DPL’s DAM is used as first step tagging and personalizing METAdata (like place or person or event) to bring along the hole proces of development until the final result is managed by any DAM you like with embedded XMPdata in the Jpeg.

Make a extra [checkbox] in export settings for every type of export, for if you like to keep DOP as a main sidecar in workspace of DPL (DPL DAM single based) but you want for Jpeg and TiFF/DNG by export a create a XMP structure sent with it. so it is a one way street:

Personal i think it could be done by first make the export side working to export in XMP-based METADATA by Jpeg/Tiff and DNG , and rewrite the dop-file managing system later for dual coupling DAM’s by XMP sidecar (So you can use a more extended DAM app to manage al your images (including raw-files) if you like which write tags in to the DAM of DPL without changing image adjustmentsettings.)

(end of thoughs)

In the first step, or second it is not really needed to choose between DOP and XMP. All the infrastructure with develop settings and virtual copy management is done with DOPs currently, not easy to replace that. PhotoLab just needs to produce an aditional XMP, where it stores universal metadata, which is common for all DAMs and additionally hierarchical keywords. In a further architectonical step they could try to get rid of the DOPs and put the product specific parts also into XMPs, like it is done by other develop tools, so that only one sidecar is left again. I think DOP is living legacy, which can be refactored away step by step.

Yesterday I checked the current state of PhotoLab with the search function. If it would be possible to create and manage hierarchical keywords, search by them and the metadata would be stored in XMPs and embedded into JPEGs, I would drop my current backend DAM (AcdSee), because the PhotoLibrary would be sufficient for me. The only functionality, I would miss, would be auto ingesting photos into my folder structure with the scheme year \ month \ day by date taken. But this is not a long way to go. I could even write an own batch tool for that.

Regarding the search facility, I never rename my files so I never and will never (probably)
search for file names.
What I do do is use Adobe Bridge to add key word tags (Venice, concert, school etc) into the meta data and this is what I search for. As I archive my images onto DVDs, I even tag the images with the DVD number so I know which DVD the original is on.
This is what I need.

Ideally, DxO needs to read this data in their XML sidecar and utilise it. I sure as hell don’t want DxO sidecars, Adobe sidecars etc

Yeah. DxO need to read and write XMP sidecar files.
That way DxO and any other DAM or editing application can exchange and parse the metadata which in turn will make us and the applications happier. :slight_smile:

Any comments from DXO regarding full XMP compliance of their developing DAM would be appreciated. Please!

" Reply



Yeah. DxO need to read and write XMP sidecar files.
That way DxO and any other DAM or editing application can exchange and parse the metadata which in turn will make us and the applications happier."

Nice ask but it isn’t going to happen as there’s editing stuff in an Adobe XMP file and it isn’t compatible with DxO stuff or so DxO say and which will make DxO ultimately fail

XMP is a bin for common and company specific XML tags. Even if there are some tags for adobe specific develop settings (starting with crs:), DxO can just ignore them. Do not touch anything, you do not understand. Other tags like dc:subject is common for all tools. XMP is not adobe specific.

I know that.

So talking about dragging old threads from the grave… :crazy_face:

But with a purpose.
in 2018 i needed more detailed search functions for rawfiles.
before: tagging jpegs and had a mirrored folder structure in jpeg and rawfiles. find the jpeg means the raw should be in the same folder on the other side. working fine but when searched images are in different folders that is a pain to collect.

XMP is the bone the core the spine in flexible keyword and exif/IPTC storage in my case anyway.

Where are we now?
well, FRV is my first step in culling, selecting and creating a XMP if i use rating (rest is for use in LR written and don’t work in DxOPL.)
Then, aslong as DxOPL has no editing of XMP, i use Adobe Bridge to tag keywords and fill the additional information in the EXIF/IPTC fields. (works fine but has some quirks which i detail later.)
This should be my main DAM place. The editplace to be in tagging. the search place and i can make “projects” in Bridge to send groups of file to DxOPL for editing which are a kind of “projects” in DxOPL
So all happy… eh no.

DxOPL is evolving in there search functions and bridge is about checking boxes to select groups to show or hide wile DxOPL is more intuitive in type your search in and we show the existing things what can be yours to find.
Both are fine, if you know what the key word is or Aperture or isovalue or any other search parameter DxOPL is great. better.
If you don’t know and relay on what you see in the choose section and use the boxes to sellect bridge is better. besides some annoying problems.
1 i have to check what i what to see in a folder:

which is fine but annoying to do every time i select a folder or change to a folder.

2 And this is where DxO has a muchbetter system,

No folder tree searching of keywords so i have to click on every folder and search there which is again point 1 very annoying.

So my present search and select function is:
open DxOPL use there the search function of keywords and such.
then find the folder and open bridge to alter or add the xmp changes.
go back to DxOPL check if changes are seen.
and or create a project of the group.

So i can’t wait on a editable xmp file based DAM module to murch those two together.
ditch Bridge, oh no! startup time is much faster because it doesn’t need to load the raw editor section.

But i think i would use Bridge as quick search and second stage keyword tagging tool and move over to DxOPL’s DAM for searching and projecting and adding keywords/exif/iptc updates.

Ok it’s two years but DxOPL is evolving the right way in this DAM functionality. (except the speed of starting up and the slugging by the database filling which is always a danger when functions are growing.)

DxOPL has two tabs so a two stage loading can be a solution for that problem.
This requiers two different view drivers.
one for embedded thumbnails in rawfiles and jpegs/tiffs no optical correction applied and one as the present viewer with loading and applying optical corrections.

one with detailed search and tagg functions and the other more grouped highlight image info.

So fire away, what do you think? am i wright to be positive about the evolution/progres or not?