Hello,
I see a strange behaviour with the current version of Photolab 6.5 (Windows 11 22H2): For some RAW files Photolab writes the corresponding XMP files, for some RAW files it does not. I’ve attached a screenshot of a directory.
They have all the same format (RW2) in the same directory. Any hints how to “fix” this behaviour?
Thanks in advance.
Some data is only registered in the XMP, maybe you have not used it on all your images ?
I’ve added to all images at least one keyword(-hierachy) which was the same. The XMP file was created for these images for which I added a second keyword(-hierarchy) (see yellow marked text in the screenshot)
Is PL the only software you use for your images? Other packages can create XMP files if, for instance, you’ve opened one of the files but not the others.
Until now I have used Adobe Lightroom Classic (newest version). But for the shown images (see first screenshot) I used PL 6.5 only. So all my other image editors haven’t saw these images.
I was able to “fix” this behaviour by adding an additional keyword to the images with no XMP file. After adding a second keyword, an XMP file was written. This is more a circumvention than a fix 
.
@LSe Short answer “No”!!
It should not happen. I tested with 1,000 images from my Bulk test directory and when I finally got all the correct options set in ‘Preferences’ i.e.
I discovered the 1,000 images in one of my Bulk tests directories (Bulk = 1,000 images BULK = 11,699 or thereabouts) and selected all (Ctrl A) after the “dust had settled”, i.e. after the count had stopped increasing and showed 1,000 and after a DxPL(Win) 6.5.0 shutdown I have
So I need more details to see if I can reproduce the problem, i.e. options used, the procedure for setting the keyword in DxPL(Win) 6.5.0 etc…
PS:-
Sorry I missed the bit about hierarchical keywords so I repeated the test using “Plant”|“Evergreen”|“Ivy” which took a bit longer with 1,000 images and got
and then changed the ‘Metadata’ ‘Preference’ to
and got this with “Plant”|“Evergreen”|“Ivy”|“First”
and
Nothing missing except my sanity!
Additional:- For the sake of completeness the following can be used (regardless of the preference settings)
but both operations are “destructive” (not additive), i.e. the ‘Read’ will take the metadata from the image and overwrite the values in the database and the ‘Write’ will overwrite the image metadata with the DxPL metadata from the database.
So if you experience a situation where you believe that some sidecar files have not been updated/created then Ctrl A to select all images in the directory and ‘File’/‘Metadata’/‘Write to image’ will result in all the metadata in DxPL being written to the images!
@LSe Thank you for your response but while the suggestion I made will work I am concerned that I found no evidence that DxPL is “losing” xmp updates, i.e. neither your second keyword nor my ‘Write to image’, both of which will trigger a metadata write (with the appropriate option set in the second keyword case) should be necessary.
Actually that is not entirely true because my first test showed that I had 549 xmp sidecar files but I then realised that I had option [1] reset! (see chart below), i.e. the xmp sidecar files were already in the directory and I had failed to clear down the DOPs and xmp sidecar files before starting the test!
I then repeated the test with option [1] set and using a simple (non-hierarchical) keyword and had 1,000 xmp sidecar files.
I then repeated the test with [1] set and using an hierarchical keyword and had 1,000 xmp sidecar files but because option (4) was set I had the full set of hierarchical keyword combinations which did not match your xmp snapshot.
Finally I set option (3) and added a fourth keyword to the hierarchy and got an equivalent to your snapshot with 1,000 xmp sidecars!
Please note all DOPs and xmp sidecar files were deleted between each test (but not before the first test).
So the procedure I wrote will mean that all metadata will be copied (for all selected images) from the database to the image metadata (always to an xmp sidecar for RAW image files) without the need to force a write by adding a second keyword but both techniques should be unnecessary.
The addition of the second keyword is forcing a metadata write just like the addition of the first keyword should have done, as it did in all my tests except the first test when the appropriate option, option [1], was not set!
While I would say that you appear to have encountered a bug it is not one that I managed to reproduce in three tests with 1,000 images per test?
