I’m putting together a new workflow using FRV and PL6. I will use Apple Photos as my DAM. The workflow will look something like this:
FRV: select raw files and move to
PL6: view every file in “Customize” with default preset
PL6: perform additional editing on some files
PL6: export some files as JPGs
FRV: rename JPGs
DAM: import JPGs, organize, share
OS: move to SSD
Ideally, I want to capture all PL6 edits in *.dop files. This way, I can open up the archived directory and pick up where I left off on any computer with no reliance on the PL6 database. After some testing, I noted the following:
A. Opening a file in “Customize” and applying the default preset is not sufficient for PL6 to create a *.dop file. You must apply additional edits, export a file, explicitly export sidecars via File>Sidecars>Export, or change flags/ratings/etc in the “PhotoLibrary” for PL6 to create a *.dop file.
B. FRV will rename associated *.dop files, but it does not update the filename embedded in the *.dop file. PL6 will rename the *.dop file and the embedded filename. PL6 properly handles *.dop files renamed by FRV. If PL6 updates the *.dop file for any reason, it will also update the embedded filename.
I’m hoping someone can help with the following questions:
Will information in a *.dop always take precedence over information in the PL6 database?
Should PL6 create a *.dop file when a file is opened in “Customize”?
Are there potential issues renaming raw or jpg files via FRV?
Bonus: Why does PL6 create a *.dop file instead of a *.xmp file when I change flags/ratings/etc.?
I use a similar workflow - tho, my “DAM” is simply a well structured file-system.
True, but … if you haven’t taken at least one of those actions then there’s nothing worthwhile to store in a sidecar/.dop file.
Yes - As you found, PL does not care about this … It simply looks for an associated sidecar/.dop file with the same prefix (which must be identical, up to the .dop suffix)
PL embeds an “ID” within the sidecar/.dop - and also in the database. If it finds any difference it creates a Virtual Copy (so that both versions are retained), and leaves it to the user to determine precedence.
A way to avoid this is to delete the database for each session, and rely purely on the sidecars (as I do)
I’m not bothered by this; PL creates a sidecar when there’s something to store in one. Otherwise, not.
To be completely safe, PL should bot be running at the same time. Having said that, I often do so anyway (tho, not using FRV). The key is to be doing so using a tool for which you can be sure that multiple {RAW+Sidecar} files are always being renamed as pairs - so that both renames are completed fast enuff that PL does not commence any clean-ups on what it considers to be orphans.
eg. On the Windows side; do NOT trust File Manager to safely rename multiple {RAW+Sidecar}s
I believe FRV is “safe” in this regard - but t’would be wise to test & confirm that.
I run PL via a “Wrapper” that first deletes the database (and cache) before it invokes PL.
I process all my images as batches, within a work-in-progress folder → (Rename) / Archive / Repeat.
I was thinking it might be useful to have a snapshot of the default preset captured alongside the unedited file so your starting point would be the same as the original editing session if you ever return to this file.
Thank you for this exlanation! It’s good to know the *.dop version will not be lost when there is a conflict.
Does anyone know what I might be doing (or understanding) incorrectly here?
Check your preferences for the creation of xmp files as I think there is an option to write those settings to xmp files. I can’t remember the details and I am not on my computer right now but I think you can turn off xmp files in which case those settings are written to the database and/or dop files.
@cdp The option is now in the ‘Preference’/‘Metadata’ this might or might not help and there is a lot more things to consider but Granddaughter minding is currently more important!
PS Either check the 'Synchronize option ’ or leave unset when you must ‘Read from…’ or ‘Write to …’. If you are only working between FRV and DxPL then set the option would be my recommendation and remember that FRV does not do automatic updating you must
On the subject of renaming files, would it be worth your while to rename the Raw files on import. This would lead to .dop and .jpg files being given that new name.
The following may interest other readers:
My workflow which uses Faststone Image Viewer (FIV) rather than FRV on my Olympus and Fuji images:
FIV: Import Raw files, renaming to YYYYMMDD_hhmmss.orf, YYYYMMDD_hhmmss.raf
Photolab: edit Raw, export to YYYYMMDD_hhmmss_PL.tif
Photoshop: edit tif, save as YYYYMMDD_hhmmss_PL.jpg
Photoshop: resize to screen dimensions, sharpen, save as YYYYMMDD_hhmmss_scr.jpg
I store files in a Windows folder structure with a per year folder and subfolder for screen sized versions:
2022
– 2022_scr
2021
– 2021_scr
2021_holiday
– 2021_holiday_scr
2020
– 2020_scr
etc
I’ve been doing this since 2002, backing up to other drives as I progress through the years.
If I want to print, I use the top level folders.
If I want to view my photos or share to social media, I use the _scr subfolders.
Unfortunately, I just can’t migrate to a DAM - too many thousands of uncatalogued images.
However, I am thankful that Photolab doesn’t force this upon me, unlike Lightroom etc.
@KeithRJ
Thank you for pointing me to the options.
@BHAYT
Thank you for the illustration and detailed response. I hope that didn’t take you away from your granddaughter too long! I was a bit hesitant to explore this option given the warning, but I think I understand how this works now. With “Synchronize metadata with XMP sidecar files” unchecked, the XMP data is stored in the PL6 database. Because I have “Automatically export sidecars” checked, a change in the PL6 database XMP data causes PL6 to write out an *.dop file. If I then check the “Synchronize” button, PL6 will start writing to a *.xmp file instead and any XMP data in the *.dop file will become stale. Did I get that right?
@David_McA
Thank you for the suggestion. I have silly reason for renaming the JPGs instead of the raw files. I like the JPG sequencing to be uninterrupted. Perhaps I’m just worried about folks asking what happened to the “missing” images .
@cdp Just had to dash to a chemist (pharmacist) to get child Ibuprofen, one of them is coughing but temperature O.K. the other has gone quiet and temperatures up! But they dragged us out so the youngest could try out her new scooter with two laps of the avenue, I do like the flashing wheels!
Sought of right but
The database is always the lead in all things!
The DOP is essentially a “portable” version of the database entry and once anything of “note” has been changed in DxPL and been written to the database then the DOP will normally be written up to a maximum of 20 seconds after a change, i.e. DOP updates are “batched”.
Therefore what metadata is in the database is also written to the DOP, always, unless you have changed the option shown below and personally I don’t, unless testing, i.e. trying to understand or trying to break things!!
The 'Synchronize …" flag controls the automatic recognition and updating of the image metadata either embedded for JPG, TIFF or DNG or in a sidecar for RAW (DxPL never updates the RAW image). The warning is because when the process is working correctly a change in DxPL will be written and a change externally will be recognized and read and this “flip-flop” cycle will be repeated ad nauseum … BUT if something goes wrong then there is a risk of either the data being read from the image and the data in the database overwritten or vice versa, automatically. However, with this option off then the only way that any metadata will be transferred will be via the ‘Read from image’ or ‘Write to image’ commands, under user control and relying on the users memory as to which way the transfer should actually be going!!
Hence once the option is set then you will be updating the database and the DOP and the external metadata largely synchronously all the time!!
The biggest issue is that DxPL is mostly as “bad” as the other packages at having its own metadata formatting rules for hierarchical keywords and if it is automatically writing back to the image the “carefully” crafted metadata inserted by a favourite program or DAM will be overwritten by the DxPL format! With the new PL6.1.0 changes my own personal choice is to set options 1, 2, and 4 or 2 and 4 which will then rely on me keeping track or using the DxPL ‘Conflict Resolution’ feature! Option 1 works well with FRV where change to ‘Rating’ and ‘Color’ labels work well but with a little bit of FRV configuration I believe.
It started as a “mistake”, i.e. I forgot that the first option was off (AS(OFF)) and didn’t get a nice row of “identical” images from DxPL, I got the 'S’s instead (most of my testing with FRV in the past has been with AS(ON) rather than AS(OFF)).
But actually I realised it was the best thing that could have happened so followed it through with appropriate snapshots!
DxO have done a good job that way round but if you make any changes to the metadata within DxPL with AS(OFF) there is no indication that a ‘Write to image’ might be “useful”!
I have had indications from DxO that they do not intend to “rectify” that “omission”. I feel that is a lost opportunity but …
Lightroom does both and offers an option to not add a badge for the “needs metadata save” situation. This makes sense for those who don’t autosync xmp sidecars.
.
