DxO PL3 Workflow Question

John7 · February 6, 2020, 12:19pm

Fully agree

Required · February 6, 2020, 2:49pm

For a jpeg, tiff, dng and psd the xmp metadata and keywords should be written into the file.
For raw files the xmp metadata and keywords should be written to a sidecar xmp.

For application specific edits the development recipe should be written as a application specific side car - in this case .dop

But there’s no problem to write xmp as standalone and together with the recipe into the .dop. But xmp data should always be written into a xmp sidecar.

RWHendricks · February 6, 2020, 7:01pm

Hi all:

My questions have created a very interesting and useful discussion. I still have one question. In Mark’s first response, he noted that:

“Renaming both the raw and .dop files outside of PhotoLab will not give you the results you are looking for.”

This implies (at least to me) that the raw filename is contained in the .dop sidecar and that renaming both the RAW and the .dop file to the same new name (with appropriate extensions) will screw things up when .dop tries o use the old filename still remaining internally.

However, Sigi notes that:

“in regards to renaming, moving etc… I use Photo Supreme as my DAM software. When I change the name of a file withinin Photo Supreme, all sidecar files (.dop, .xmp etc…) will be renamed automatically. The same goes for moving files around to another folder, deleting a file etc… As long as I do that within Photo Supreme all sidecars will be moved etc… automatically.”

and similarly Pascal notes that “XnViewMP too when declaring “dop” as a associate file extension.”

Does this mean that both Photo Supreme and XnViewMP make the requisite changes to the filename within the .dop sidecar? I am afraid I do not fully understand the apparent discrepancy between these three statements.

Pieloe · February 6, 2020, 7:09pm

No for the last question.

And Yes, the file name is writing in the sidecar dop.
In fact, this information is useless.
You can rename both raw and dop outside PL.

In another post @John-M make the penny drop (!?) // John m’a mis la puce à l’oreille
Pascal

John-M · February 7, 2020, 3:41am

There is no problem with renaming BOTH the RAW filename and the sidecar/.dop filename - - even tho the old/previous name is contained within the sidecar/.dop file - - provided you give them exactly the same filename. PL will update the contents of sidecar/.dop file with the new filename.
– eg. Renaming DSC01234.ARW and DSC01234.ARW.dop … to ImageFromSonyCamera.ARW and ImageFromSonyCamera.ARW.dop is fine.
HOWEVER, you need to be very careful in doing bulk renames of RAW + sidecar/.dop files from outside PL, while PL is running/active.

This is because many tools that may allow you to do this do not necessarily action the changes in the order you expect them to (eg. Win Explorer is such a culprit) - - Such that, say, the filename of a RAW file is changed first, but the filename of its related sidecar/.dop file is not changed until much later (due to the erratic/unpredictable order in which multiple files are renamed). PL sees the new filename as being a new image, without a sidecar/.dop file - - and then things become confusing.

Summary: There’s no problem renaming RAW + sidecar/.dop files from outside PL - but, it’s safest to do so when PL is NOT active/running … I do this all the time.

John M

RWHendricks · February 7, 2020, 4:23am

John:

Thank you so much for clarifying this issue. Thanks also to all who responded–I think I now understand sufficiently to design a new workflow, renumber my files, and not lose the information for those files already processed.

Bob

mwsilvers · February 7, 2020, 5:41am

What I meant to say was it may not give you the results you intended. You have to be careful. For instance, if you use your mouse and copy a Canon raw file and its.dop file into the same folder automatically creating file names with -copy cr2 and -copy dop appended to the file names, the .dop file is not recognized. There also may be other instances. Additionally, manually renaming outside of PL also increases the possibility of a spelling error, extra space or other issue that would make the file names different.

Mark

George · February 10, 2020, 7:19am

Some thoughts.

Loosing the database means you also loose the keywords.

What happens when renaming a file outside PL, both master and dop, with the database? What happens with the old names and when is the new one added?

Why not adding keywords directly to the mainfile? Reading is done already. Well, partly.

George

zkarj · February 10, 2020, 8:56am

I completely agree with everything Joanna says above. While I would prefer the (improved) DAM to be part of the existing software, I can see that some people find it mostly gets in the way and so having it seperate as per FilmPack etc should please everyone. If it’s well specced, I’d even be prepared to pay for it as another product, too.

John-M · February 10, 2020, 9:16am

When a pair of image files, [source-file + sidecar/.dop], are renamed outside PL - then PL detects them as a “new” image - and, so, it stores the new entries in the database - but, it does not know to remove the (now redundant) entries related to the old names.

I have no interest in PL’s DAM capabilities - so, I am happy to delete the database file(s) on a regular basis - - - but, I see that this is an issue for those that do value PL’s DAM features - as keywords are not (as yet) stored in the sidecar/.dop files.

John M

George · February 10, 2020, 11:46am

That means that when renaming or deleting outside PL is done often, the database is growing with rubbish. So one must sometime either accept that or delete it and force a new database, but loosing all the keywords.
I don’t know what happens when renaming or deleting from inside PL.
I’m only interested in the keywords. Adding them outside PL directly to the mainfile solves that problem.

George

John7 · February 10, 2020, 12:25pm

I also would be intrested to know if renaming or deleting insde PL does update the data base. I have always tried to do both but if it doesn’t update it thats a wast of time!
To me all this points to a DAM should be an add for those that whant/use it with its own data base rather than tacked onto the existing stuff which has always appeared to me to be a short term bodge.

OXiDant · February 10, 2020, 2:48pm

You can manually push to create a dopfile out the DB stored edit data.
Select images create dops, repeat this for all folder you want this.
Then delete DB and reindex folders.
Not sure if it immidiatly load dop data or only when selected.
Only thing you lose is keywords made /added inside PL’s database. The xmp versions are re-read.

OXiDant · February 10, 2020, 6:28pm

Until DxOPL is able to export the keywords you add or edit inside PL back in the file it used to read the keywords from you risk to get a "closed in " Library which isn’t in sinc with the outside readouts like first made XMP-files to gain fast keywords attached to your rawfiles readable/usable for al your applications.
So i use only the index folder function to gain a library where i can search in. (if i would delete the DB it only index again and done ready to go. (dop-files are for the editing so that section is covered also.)
Same as exporting in my tiff’s and dng’s and jpegs from DxOPL. (until it’s able to write inside IPTC and or create a XMP you have to transport the source XMP out of the rawfile folder in the export folder where the tiffs and such are wrote to.)
assuming you don’t use a DAM which can do this around DxOPL automatic.
So a full pass through/and write back(update source) of data and file attached would be most usefull wile the Database is more for lookuptable quick access purposes.
(it would be much faster if it’s only updating the folder you active be looking in then when it’s monitoring your hole librarystructure for possible changes.)

And i think DxO is knowing this. (the feature of being at first a interface/connection and not really a full blown DAM competing with the bigboys.) first you need to learn how to ride a bike properly before you start to compete in races.

Personally i am thinking it’s not smart to use the DOP-files as storage of keywords and such. it isn’t universal for other applications to read. And they are changing sometimes in version updates which can be a pain after a wile when you go back in your archive. (sometimes it’s faster to delete dop info and start from scratch then “updating” version of the dop file and checking if it’s done conversion without a flaw. )And when you change your most used application for development your hole database is stuck in the other.
best option is:
filename.raw
filename.dop (editing values/data)
filename.xml (keywords andsuch)
import
—developing application----
export
filename.jpg and written IPTC with as option a xmp-file instead (some people want to clear out exif but have a external exif for internal purposes.)
And xmp sidecar for Tiff’s and dng’s with as option to write in the IPTC if possible.

This way it will be non application dependable. And outside renaming/deleting/ altering will be no problem other then a reindex of the readout in the DAM or other application.