PL5: Moving files outside PL loses corrections and more

Thank you John (@John-M) for clarifying that point.

Having the minutiae would allow for new preset developments to be “parked” in the database/DOP across sessions with the ability to roam down and up the stack and continue where the user left off.

Certainly useful but those of us on Win10 currently manage without so …

Thanks Brian for your review of my post and your concerns about some of my lack of concerns.
My workflow is fairly simple:

  1. Shoot in RAW only.
  2. Download from my camera to a dated folder using Canon EOS Utility.
  3. Import that Folder in Photo Supreme and often delete some in PS. No Tagging at this point.
  4. Open the images in PL5 with my custom default preset applied.
  5. Crop, straighten horizon and other editing in PL5 as needed. Sometimes more deletions.
    A. Sometimes export a TIFF to one of the Topaz products. Export it from there as a JPG to the original folder. Maybe review the jpg in PL5.
  6. Export from PL5 as a JPG to the original folder.
  7. Add flat keywords in PS. These include a star rating which I make as a keyword because of the ways different software can mess up Ratings.
  8. Send a copy of the JPG to a folder that is picked up by Mylio. Mylio then propagates copies to my wife’s desktop PC, our two laptops and our two cellphones.

I understand your concern about keywords in PL5. Since I add keywords after editing in PL5 that is not normally a concern to me. What I am concerned about though is if I should re-edit a photo in PL I don’t want it to alter my keywords in any way. I should probably do a little more testing by re-editing images that have previously been done in PL and confirm that my keywording is still okay. I don’t think I addressed this aspect enough.

(Added on Edit) In fact on further thought I think that could become a problem. If I re-edit a photo in PL5 I don’t think that PL looks again at the xmp. Thus any keywords I previously added in Photo Supreme are not in PL and will not be included in a new Export. Do need to investigate this one further! If it is a problem I may have to use @John-M approach of always deleting the PL database before editing in PL5. Then when re-opening PL5 it should pick up any new keywords that had been added by Photo Supreme. That is if it will maintain the integrity of the xmp and pass on any keywords!

I only mentioned the lack of PL showing Advanced History as an observation, not a concern. I have been aware that in the PC version it does not maintain that. It might be nice to have but has not been a problem for me. DXO has a lot bigger fish to fry than that one. What is important to me though is that previous editing is saved and that does seem to happen. I opened several images and they all showed adjustments that I believe were the final ones I made.

Thanks Wolfgang. I was aware of this and only noted it as an observation, not as a fault.

Just did another test related to the above.

  1. Took a previously PL5 edited RAW image with no keywords and added a keyword in Photo Supreme.
  2. Opened in PL5 and it didn’t show the Keyword. This I believe is because once the image is in the PL5 database it doesn’t look at the xmp on subsequent edits. So it misses any new information that has been added/changed in the xmp.
  3. Closed PL5 and deleted its database.
  4. Restarted PL5 and the Keyword showed in PL5.
  5. Exported it as a JPG and the keyword showed when imported into Photo Supreme.

I will have to implement @John-M’s approach of deleting the PL5 database before each PL5 start. Thank John for earlier sharing that information and your script.

Also @Bayht’s concern about my keywords not showing in PL5 is valid if I am going to re-edit anything previously done in PL. Thanks Brian.
Rod

1 Like

Hello Rod,
I can not confirm that

  • I took a previously edited raw image (cr2) and added a keyword in Photo Supreme
  • opened PL5 and immeditely got the symbol in the thumbnail that there is a change in metadata

No need to delete database or anything

Sigi

PS: I tried above now with a RAF file - same result, no problem

1 Like

Thanks very much Sigi!

I was not aware of the icon on the PL5 thumbnail that showed a MD change. I did the same sequence as you again and when I clicked on the icon it asked what I want to do with the change. When I clicked on Read From Image it picked up the new keyword. It also had a checkbox for Apply to All Images which could be handy.

It could be real easy for me to miss that small icon on the thumbnail in the future and then the new MD wouldn’t be passed through. I need to give some thought to which technique is better for my use case: this one or the database delete.

Thanks again for checking my test! :slight_smile:

Rod

@StevenL - this is a good point, maybe there is clearer warning, i.e different color for the sign that there was a change in metadata

2 Likes

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

  1. Adopting the @John-M strategy, turning the database into a temporary/transient entity.

  2. 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)!!

  3. 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

  1. Leave the database intact

  2. 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!

1 Like

Yes it is. After a re-edit the original keywords are still showing in the jpg using either of our discussed approaches. So at that point I only need to add if I want additional keywords.

Why not? I assume you are talking about when I have exported the jpg to the original directory where the RAW is. After I have done the jpg export I will be possibly/probably be adding or changing keywords in Photo Supreme.

It certainly helps but I must admit that I needed to reread the post a few times to find what I thought was applicable to my current situation. OTOH I truly appreciate the very thorough testing you do and your real efforts to help me, which even include your using the same DAM I do!

At this point I feel the easiest and safest approach for my workflow is to use the @John-M approach of automatically deleting the PL5 DB before starting PL. This is based on the fact you seem to have caught a few (very few) instances of PL5 missing some MD, and my preferring to not having to think about telling PL to read from file.

Thanks very much,
Rod

1 Like

After two requests from DXO for clarification of my questions I received this:

Here is some direct suggestions/questions from the developer team.

I also want to be able to open a RAW file (CR3) that has previously been developed and edited in Photolab and still have the Editing visible in the image and adjustment slider settings positions.

The customer should ensure that all applied editing settings were exported to .dop sidecars and then copy them along with his images to the new computer.

Many, but not all have keywords that I don’t want to lose

The customer should export metadata for all his images to .xmp files for RAW images or embedded metadata for JPG and TIFF images and then copy them along with those images to the new computer.

Will it work for him?"

Kind Regard,

Kelly- DxO Labs Support Team

In my support request I referenced this thread as a reason for my concerns.

1 Like