I’m working with Photolab 5.1.1 build 52 on MacOS BisSur.
When rotating an image from landscape to portrait,
in .dop sidecar file then occurs a line “Rotation = 3,”.
When the image and the sidecar are copied to e.g. another directory or a backup drive,
and then moving in PhotoLab image browser to this directory, the rotation information
is lost. The image shows up in landscape again, and looking into the .dop sidecar
“Rotation = 0,” shows up. This has the effect that all rotation info is lost in the backup.
The same effect occurs, when the image directoy is renamed.
In preferences automatic import and export of sidecars is enabled.
Is this an already known bug and is there a workaround?
I believe that some data are read and applied only by the database.
PL should take priority data from the side-car * .dop and then the database and all parameters should be in the DOP.
Moving and copying files between folders with DPR5 drops rotation indeed. Looks like a bug to me - and is possibly related to flag and rating loss.
Attn. @sgospodarenko
@ups and @platypus Please remember that I am using Win10 PL5 (not Mac). I have repeatedly written that the ‘Rating’ is no longer held in the DOP! There is a field in the DOP for ‘Rating’ but there is no evidence that PL5 uses it for anything (except storing a duplicate copy of the ‘Rating’ value)!
PL5 now expects to find and also stores the ‘Rating’ in the xmp data for the photo (embedded or sidecar and PL5 only creates such data in the sidecar for RAW photos). I believe that this is common to both platforms.
If you set ‘Rating’ in PL5 but do not have the Sync option set or manually write the metadata and just copy the photo and DOP then the ‘Rating’ will not be available to PL5 because it expects to find that data in the embedded xmp data for JPG or sidecar for RAW and they simply will not be present if they have not been written by the aforementioned actions.
In my tests I rotated a JPG and a RAW photo in PL5, set ‘Rating’ and set the PL5 only metadata field the TAG in directory PL5 DOPs (previously used for another test but not related to rotation).
I created a new directory (__A).
I drag and dropped all photos in the directory to the new directory (from PL5 DOPs to __A).
I checked the new directory(__A) in PL5 and Rotation was present, Rating was present but Tag was missing a bug that I and others have reported (a number of times @sgospodarenko).
Checking the directory PL5 had successfully moved the photo, DOP and xmp sidecar file for the RAW.
The only problem I experienced the first time that I tried this was that the target directory was too far away from the source and PL5 would not scroll down to allow me to get to the directory, disappointing unless it was me not moving the mouse properly.
In that previous test I had also copied the data (photo + DOP and only testing rotation) externally to PL5 and PL5 picked up the data correctly when I navigated to the new directory.
Hence, I conclude that on Win10 the “loss of the rotation” problem appears (according to my tests) not to be present (but the Tag is still a problem) and ‘Rating’ appears to be a common misunderstanding not helped by the various bugs surrounding the issue and the change from PL4 and earlier versions storing ‘Rank’ in the DOP where PL5 now stores ‘Rating’ in the xmp data (but only if instructed to).
@platypus Please read my post and look at the original snapshots which show that this works when all the files are present and the files necessary to preserve ‘Rotation’ for a RAW image are the RAW, the DOP and the xmp sidecar.
The problem encountered by @ups is exactly the same as others have encountered with ‘Ratings’ when that have not captured and/or not preserved the xmp sidecar file (which I did in my tests because I currently have the metadata ‘Sync’ option ON).
The JPG is carrying its rotation data within the photo but the [M]aster photo requires the xmp sidecar file to preserve the ‘Rotation’ data as you stated (‘Rating’ line 11’, ‘Rotation’ line 15)
In the DOP we have ‘Ratings’ and ‘Rotation’ but for the [M]aster image these fields are Write only fields to maintain compatibility with the details stored for the Virtual Copies (if any) but for the [1], [2] etc. Virtual Copies these fields are the only source of that data.
Therefore you need BOTH the DOP (for edits etc.) and the xmp sidecar to preserve the ‘Ratings’ and ‘Rotation’ of the [M]aster photo (probably the only one being handled for many users) and the DOP to preserve those details for all the other Virtual Copies if any.
Hence, my repeated comments about care when preserving the xmp file because without it the [M]aster photo has no ‘Rating’ and no ‘Rotation’ data.
This is not a bug this actually is a feature, the storage of details in the DOP for the master provide consistency with the storage of VC details in the DOP but the xmp is the main source as you pointed out.
My tests work not because I am on Windows 10 but because I preserved the xmp sidecar file.
Yikes! And those of us who were on the beta for PL5 never spotted these “little” but important errors.
I just tried something…
Take an image, shot in portrait, make two virtual copies and rotate the first 90° to the left and the second 90° to the right. Now set the ratings to 1,2 and 3.
Obviously the Rating is that of the (M)aster but the Orientation shows 8 instead of 3 for Rotation. I’m guessing this is a translation from one notation to the other?
Careful: Exif “Orientation” is different from what DPL writes as “Rotation” into .dop sidecars.
Moreover, there is also a “Camera Orientation” tag, hmmm.
.dop Rotation tag: Orientation changes in portions of 90 degrees clockwise, e.g. 0/1/2/3
.xmp Orientation: .dop Rotation 0/1/2/3 corresponds to exif Orientation 1/6/3/8
Somehow, things were easier if DxO adopted the exif tag labels and values, but the .dop files are proprietary, so why not translate things to and fro and then ignore content upon import.
@Joanna Absolutely I did that by accident with one of Mike Meyers photos but applied the rotation to VC [1] instead of the [M] and the penny finally started to drop.
In the move from DOP storage to xmp storage for certain items (‘Rating’ and ‘Rotation’ amongst them) just keeping the DOP is no longer enough to retain that metadata, you must have the xmp data as well (that includes writing it back to a JPG etc.).
The [M]aster (or only data if there are no VCs) effectively mimics the way that the data is stored for those items in any Virtual Copies but is not used for the [M]aster entry.
So we have been complaining about the keywords and ‘Rating’ and ‘DOP’ being present in the DOP but never used (WOM - Write Only Memory) in fact it is there effectively in the same way that it is there for each and every VC but will not be used by PL5 for the [M]aster (or only) copy that will use (and then overwrite the DOP details) the xmp values.
It is both as simple and as potentially destructive as that. All of this could have and should have been made clear at the outset.
DxO please start communicating instead of apparently hiding @sgospodarenko.
PS:- Unlike FastStone which is O.K. for browsing photos and launching programs but not much use for metadata, FastRaw Viewer gives the following result because FRV can handle the metadata and apply it to rotate the RAW!
@platypus I am afraid this is simply the fact that DOP values and xmp values are different and if the DOP values were changed at this stage (arguably it would have been good if they followed rules that already existed when first created) would create an even bigger problem with PL5 trying to read old DOPs with the old set of values versus a new DOP more closely aligned to orientation values (except that it doesn’t actually read any of those values from new DOPs for the [M]aster photo at all, it just writes them!! - for the [M]aster all that data comes from xmp sources).
I didn’t thank you for this comment it also helped the “penny to drop”, particularly when I thought about the results of the first test when I accidentally set the PL5 ‘Rotation’ value on VC[1] not [M] as I had intended!, at the same time.
PL5 shows the rotation of VC [1] and the separate [M]aster photo but FRV only shows the second [M]aster photo as having any rotation at all, i.e. the DOP is providing all the ‘Rating’ and ‘Rotation’ etc. data for all the VCs(if any) and the xmp (embedded or sidecar) provides the same data but for the [M]aster only.
This xmp data is external and can also be viewed and changed by other programs for the [M]aster (but they know nothing about VCs etc. hence the reason it is kept in the DOP for all the VCs)
@joanna being just a teensy bit frivolous can you fix this photo for me? A good display of snowdrops and hellebores at the back of a bed and I manage to get the twigs (rose stems) in focus (and no I was not manually focussing).
@joanna While I could set up a hyperfocal distance for the camera at its widest view (24mm equivalent) I also zoom to reach the back of a flower bed etc.
Even though it was a grey day I went to Highdown Gardens on my way back from the Dentist and was glad to see a lot of snowdrops were in flower and I love to see trees without leaf at this time of the year, i.e. see their “bones” without the “flesh” (leaves, blossom etc…)
@platypus Sorry @ups I was absolutely hijacking this thread but just for a moment, perhaps I felt I had “earned” a bit of “light” relief. Testing can wear you down and I feel that I have got as far as I personally can with the problems of ‘Rotation’, whether we like it or not DxPL has changed more than somewhat going from PL4 to PL5 and caught a lot of people out in the process.
Attached is a PL4 snapshot of two images rotated, one JPG and the other a RAW and as expected (PL4 immutability etc.) neither are picked up in FRV, i.e. all the data for both settings can only be found in the PL4 DOP (until a photo is exported).
Please remember that if you want to secure (externally to the PL5 database) ‘Rotation’ and ‘Ratings’ (and various other fields) when using PL5, then the ‘Metadata’ commands of PL5 must be used i.e. ‘Sync’ or ‘Metadata’/‘Read from image’ and ‘Write to image’ and the resulting xmp sidecar (for RAWs) must be kept with the photo and DOP or the photo itself for RGB images (which contains xmp embedded data) and the DOP, to secure all of the edits.
With PL5 a JPG and DOP is sufficient iff (if and only if) the metadata has been written back into the JPG but for a RAW image the photo, DOP and xmp sidecar must be secured and will be sufficient iff the metadata has been written back to the RAW (actually into the xmp sidecar associated with the RAW).
Having just the JPG or even an xmp sidecar is not sufficient if the metadata write did not occur for the items we are discussing, i.e. they were never actually externalised from the PL5 db; an obvious statement I realise but the timings of these read and write operations could be critical).
@joanna Please do not respond to the off-topic elements of this post here simply DM me if there are any further comments and we can take the conversation off-line if necessary.
Yes it is a consequence of not writing the xmp data
Ever
When a change has been made in PL5 but not written back to photo
When a change to a photo has not been re-imported into PL5
etc. etc.
I am afraid that my preference is now for using the ‘Sync’ option because it avoids so many problems!
So:-
It is not a bug it is a consequence of the changes in metadata handling that have come about with DxO “abandoning” the immutability constraints of the pre-PL5 era and the impact on users who were used to that way of working (because that was all that was on offer - then).
It is the result of DxO not making it clear, scenario by scenario what was going to change and how old workflows could or should be changed.
It comes from DxO not interacting with their UserBase to understand what those workflows might look like @sgospodarenko (sorry I keep using your @ too often, please find me another DxO @ to “annoy”).
It comes from us (that’s you, me and others not always understanding properly and communicating to other forum members) but that could be helped by some (any) assistance from DxO personnel whose help might shorten the long learning and realisation process! In fact we typically work alone on tasks that would be better handled as a team but that has a number of issues and is not easy to organise so lets continue to battle it out as we have been!
It comes from a slightly dysfunctional forum where the same ground is being covered again and again and the message is still not getting across.
It also comes from forum members not always explaining the reasoning behind the recommendations they make etc. etc.
And sometimes forum members actually not describing the problem clearly enough for others to recognise it is the same problem as …
Activating the sync of .xmp sidecars might solve the rotation issue, but you risk e.g. the integrity of metadata that you added in other apps. Sync cannot be set one way as with .dop files and we’ve seen the database ironing over info in sidecars, which does not make me trust in DPL in this area just yet.
@platypus I understand your concerns and reticence over adopting the ‘Sync’ option and currently we have a choice between that option and using the two manual options and in the context of ‘Rotation’ (and ‘Ratings’ etc.) I am concerned that the manually controlled writes will simply not take place, i.e. the user will simply forget to force the writes or will get most but not all!
One problem with PL5 is the lack of icon on the thumbnails like those present with Lightroom and the additional icon that indicates a mismatch of keywords. However, essentially LR can ‘Save Metadata to File’ and ‘Read Metadata from file’ as PL5 can. However, there is a ‘Catalog Setting’ under the 'Metadata, Tab which is identified as ‘Automatically write changes into XMP’ which appears to be an automatic ‘Save to file’ option.
Capture 1 offers preferences for ‘Auto Sync sidecar XMP’ and the choice is ‘None’, ‘Load’ or ‘Full Sync’ and under the ‘Image’ menu item there is ‘Load Metadata’ and ‘Sync Metadata’.
Photo Supreme offers in the ‘Preferences’/‘Synchronize settings’ ‘Only update out-of-sync images (uncheck to force)’ and ‘Store metadata to the database only (uncheck to allow metadata to be written to files)’. For an individual file a right click on the thumbnail offers ‘Save Metadata to File’ and ‘Read Metadata from File’. However, in the ‘Tools’ submenu there are additional commands ‘Save Metadada to File for all Out-of-Sync Images’ and 'Read Metadata to Catalog for all Out-of-Sync Images. I have just installed Photo Supreme Lite on my Main machine which appears to have all of the features of the full product but with a limit of 5,000 images to a Catalog, which is plenty for testing!
Comparing with other products does not help right now but may help guide future DxO development in the “best” direction (if any such development is actually going to to take place)?
There is a question that you or @Joanna can answer for me with respect to database (re-)location on the Mac, can the database be located on a specific directory on a specific drive or can it only be located on/at the default location? The snapshot below shows my current PL5DB location on a USB3 connected SSD designated as T:.
