XMP implementation for database purposes in the future DPL DAM


(Peter) #1

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?


#2

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.


(Peter) #3

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)


(Peter) #4

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)


#5

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.


(terrycym) #6

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


#7

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:


#8

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


(terrycym) #9

" Reply

Required

19m

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


#10

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.


(terrycym) #11

I know that.