I understand that essentially the addition of keywords in Photo Supreme (or IMatch or …) is the “end” of your normal workflow. PL5 contains the RAW files before exporting and these do not contain any keywords, if you decide to re-edit them you will need to add keywords to the (re-)exported JPGs but that is arguably your normal workflow.
If you do add the exported JPGs to the actual original directory then PL5 will discover these JPGs because it has discovered the RAWs in that directory already! However, adding the JPGs to the same location as the RAW makes it much easier to select the RAW for re-editing if a subsequent review of the RAW leads to a desire to re-edit and the previous attempt, possibly now keyworded, is available to transfer the keywords to the new edit!
I now shoot RAW + JPG but from 2003 to early 2018 I took only JPGs photos on the various cameras I owned, even a Lumix G7, and bought DxO OpticsPro 11 mainly to edit JPGs.
I started shooting RAWs with my Lumix G80 in 2018 and I import images from cards so that the JPGs are in the outer directory and RAWs in a “RAW” subfolder. I mostly did nothing with the RAWs except move them to another drive with the intention of deleting them when space became too tight!
Upgrading to a G90 in 2020 gave a better sensor than the G80 but a worse video crop so I added an EM1 Mkii and a 12-200 (24-400) lens and at that point I started to use the RAW editing of PL4. The G90 has since been replaced with a G9 and that is currently used with the Olympus 12-200 lens.
When making small tests I export to the original directory, the JPG or RAW directory, but with larger runs I put the outputs to a separate sub-directory e.g. ‘_DxP5’ or ‘_DxP5R’, but that could be named ‘Developed’, ‘Developed + Date’, ‘Developed + preset group identifier’ etc. If I then added keywords to ‘_DxP5R’ externally these would not be “discovered” by PL5 at all unless I deliberately navigated to that directory.
My directory structure is similar to yours and I have attached an example where my naming convention is now (roughly),
Date + (duplicate resolver) + (Location) + (Who) + (What) - Camera + (Lens) + (.F) for Family, e.g. 2020-10-22_01 - High Beeches, Autumn Colour - EM1(200).F
Within a .F directory there will be one or more files designated P123456-F.JPG or -F.RAW and these will indicate images with family members. All files are collated by Listary and older family photos have had simple keywords added to identify the family members.
The data was placed in the files using ExifPro and DxPL has never been able to spot the ExifPro changes to JPG in real-time. However, once the ‘Read from Image’ command was provided I could force PL5 to read the keywords but as soon as I attempted to force a write of the metadata, PL5 simply ignored the request. While other programs interwork with ExifPro and embedded keywords successfully, something to do with the way the metadata is set up by ExifPro causes problems with PL5!?
UPDATE:- I owe DxO an apology for this Statement, I have not re-tested this for some time so I revisited a JPG from 2005 which just had the ‘Family’ keyword.
Discovering the directory in PL5.2.0.4732 all the photos had the ‘Family’ keyword attached but this discovery has always worked!
I added a name to the photo in ExifPro, which other software detected automatically but PL5 still does not, but after ‘Read from image’ adding a name keyword in PL5 automatically updated the image with AS(ON) and an export worked correctly.
So, at the moment the metadata for my JPG family photos is “trapped” in the photos until I can find an appropriate piece of software to rewrite the image files in a way that enables PL5 to read and write the metadata successfully, if I ever want to revisit the old directories and re-edit the photos in DxPL!?
The above statement no longer appears to be true and I can now use PL5 to update the metadata for my “Family” photos but it can get a bit tedious checking every release to see if something reported via the forum (the issue was reported during PL5 Beta testing) has actually been fixed. But I am pleased that I can now update old keywords inserted by ExifPro in PL5!!
End Update:-
My photos are typically “tagged” with a suffix to identify what software was used to process the image and multiple suffixes indicates multiple processing stages! So _DxP4R_cp6 indicates the JPG came from PL4 processing a RAW image and the _cp6 also shows that is was then further processed in Franzis Colour Projects 6.
I typically haven’t used a DAM in the past because of potential name changes (spelling errors/restructuring) etc. can cause grief but I now have access to IMatch, Photo Supreme Lite, ACDsee and Zoner (and ExifPro if I want to add even more problems with JPGs)!
This is PL5 effectively working as designed!
The first time that PL5 encounters a directory (that is new to the database) it will execute the equivalent of the ‘Read from Image’ ‘Metadata’ command and enter that metadata into the database (and export to the DOP) but, while maintaining compatibility with what has been done before (PL4 DOP format + keywords etc) and also with the DOP entries stored for any VCs, this copy of the metadata for the [M]aster copy will be ignored when PL5 encounters a “new” image file with an associated DOP, i.e. it will not read that metadata from the DOP (as it would have with PL4) but will go looking for any in the embedded or sidecar xmp data in the image file(s).
So at step 1 the keywords are added to an image which will thereafter be new (in the current database) to PL5 so no further metadata capture will occur unless AS(ON) is set or AS(OFF) is set + ‘Read metadata from image’ executed!
At step 3. all knowledge about images will be eradicated, anything now (re-)discovered will be “new”.
At step 4. the image is being discovered as if new so the metadata will be read again etc.
The alternatives for your workflow are
-
Adopting the @John-M strategy, turning the database into a temporary/transient entity.
-
Set AS(ON) and let PL5 detect the changes automatically. At times my testing has shown PL5 keeping up with hundreds of fast modifications (880+ to be accurate) without a single miss! But other tests have shown PL5 missing a change but these changes are typically being made and detected in real-time, i.e. both PL5 and the other program running at the same time. PL5 should also be able to detect changes made while it is shut down. The ‘Read from image’ can be made at any time to refresh the metadata in PL5 so “if in any doubt” ‘Read from image’ (regardless of AS(ON) or AS(OFF) but if any changes have been made to the image metadata within/by PL5 such a command will cause the image metadata to be overwritten from the external, image source)!!
-
Set AS(OFF) and use the ‘Read from Image’ to force PL5 to refresh the metadata as and when and if you want it to. The new ‘Reconcilation’ ‘S’ indicator also helps avoid things getting out of step but, once again this depends for its absolute effectiveness on PL5 detecting all changes. I have seen things slip through the net and have no explanation (from me or DxO) for how that could happen, nor why it might have happened in the cases I have reported plus no advice on tests that I could run to help DxO “surround” and eradicate the problem if that is possible. Without the code, trying to formulate a test is next to impossible for someone on the outside and this is the reason for my request for the ‘Compare’ function to provide the ability to “help close any timing windows etc.” in the code.
If DxO implemented the icon for mismatches created by setting data in PL5, coupled with the direction indicators and a “Compare” function then it would at least be possible to determine the exact state of the metadata at any time.
Because of the occasional misstep by PL5 I cannot recommend AS(ON) without some reservations but I do find it really easy to live with while I am running tests!
In your case I would
-
Leave the database intact
-
Select all photos in a directory and ‘Files’ /‘Metadata’/‘Read from Image’ as and when and if you want the metadata in PL5 updated, e.g. when you first use PL5 after you have adjusted “old” JPGs in Photo Supreme and before you shut down PL5 if you even want PL5 to discover the rendered and keyworded and Rated JPGs at all!
However, you are arguably not interested in keeping PL5 up to date at all so AS(OFF) and (PL5 to) do nothing with the metadata whatsoever.
Do not read and definitely do not write any metadata from or to that directory!
Ignore the ‘S’ icon if it occurs! This would happen in your case for every JPG after you do the ‘Rating’ and ‘keywording’ in Photo Supreme iff (if and only if) the directory holding the JPGs is actually “discovered” by PL5, eg. if you put the exported JPGs from PL5 back into the same directory as the RAWs this is bound to happen but if you export them to a new (sub-)directory or move them then it won’t unless you deliberately or accidentally directed PL5 to that directory,
I hope that this helps more than it confuses and I “sort of” apologise for the length. I could certainly rewrite some of my posts after I have put down all the ideas on paper and that is much easier if I write them in Word or an alternative and then cut and paste and cull and precis … rather than write them directly into the forum post editor! But by the time I have got to the end I have had enough even more than a potential reader is going to have!
