Just copied the folder over to laptop and both PL and PS open them OK.
My flow is weed with quickview (so slow with PL), open with PS to add keywords and geotag then open in PL. Export as jpgs to see results and remove the unwanted ones. Then again run PS as there are always ones that get removed. So I never have both programs open, always looks to me to be asking for trouble to have two programs open on the same folder being worked on (and came from the time that memory was limited so used to closing anything unneeded!).
At least doing it this way and rotation actually working in PL it ends the problem of PL rotation not copying over as PS rotation does!
The orientation tag can be understood like this: Take RAW image and do what the tag says.
Now, if landscape orientation is “normal” and the image is rotated 90 degrees clockwise, we get the portrait oriented image shown…but why should the tag be 90CW in a landscape oriented shot? Beats me, but is maybe Samsung style or user modified?
So, you never open the folder in PL before working on the images in PS? Because as soon as PL has seen the folder, it tends to index it and will store the orientation in the database, which will then affect what happens the next time you open PL after changing a file elsewhere.
Why are you exporting to see the results when all the edited images are visible in PL?
And, as I have said previously, the exported JPEGs will all have the “normal” orientation, regardless of their original one.
Not opening in PL normally, I know the problem of PL not reading from existing files and on an odd occation I copy them deleyte in PL and copy back to get PL to read everything.
I export them as fastview can compare up to 4 imiges and zoom in. I have vision problems and coparing like this has always been, I have found, the easist way esp as denoising cant be seen in PL.
@joanna@John7 I haven’t had a chance to look at this in great detail so I apologise if I am talking out of turn but
The ‘Rotation’ is metadata (which you know better than I) which now resides in the image metadata (embedded or sidecar) not the DOP (except for a PL4 DOP which will be read and accepted by PL5 and the PL5 DOP which will be updated with changes made in PL5 but never read and used in PL5!)
However, the PL5 DOP can be used for tracking what is in the PL5 database, allegedly, i.e. checking the value of ‘Rotation’ in the PL5 DOP shows what should be in the database, regardless of whether this metadata has been flushed back to the image or not!
In addition any change to ‘Rotation’ will be stored in the image by Photo Supreme and by PL5 if it is allowed to [AS(ON)] or forced ‘Write to image’ change should be detected but depending on the AS(ON) AS(OFF) switch and except for the first discovery of an image in a directory which will always result in a ‘Read from image’ either explicitly or using equivalent code, at least on Win 10!
If there has been no change made externally to any of the metadata then there is no need to refresh the PL5 metadata, if there has been a change made externally then with AS(OFF) a ‘Read from image’ is required to refresh/re-align PL5 metadata.
PL5 should always read the metadata successfully, albeit I have had occasions when testing when it has failed to capture the change successfully but if the changes are all made prior to discovery by PL5 then that comes as a surprise to me. My recommendation would be to do all the copying without the directory being open in PL5 and then navigate in PL5 to discover the images anew!
I do a similar thing when testing using both FastRawViewer multi-windows with the “sharpness” options, either, none or both displayed but my preferred approach for my own purposes is export (from RAW) without NR to be able to quickly flick from one version to another to compare alternative edits “instantly”, avoiding any the render time delays!
My own testing:
From what I understand it seems that Photo Supreme rotations were not recognised by PL4 so you rotated again in PL4 and exported the rotated image for comparison. The photo and the DOP could then be carried anywhere and re-introduced to PL4 and all was the same!
With PL5 the DOP is no longer used as a source of metadata but the image is and the rotations undertaken have gone because PL5 cannot recognise the Photo Supreme ‘Rotation’ values. Your changes made on one system are no longer carried over via the DOP!
I opened a directory, rotated an image in PS (and changed the ‘Rating’ to make sure I could find the image) checked with FolderMonitor that there had been some update activity and opened in PL5 and ‘Rating’ change located but no rotation!
BUT there was no rotation detected in Photo Mechanic nor in Zoner nor in FasRawViewer, I found some evidence of rotation changes in the metadata in Beyond Compare but they are not being recognised by any other software that I used (the way that I have set up that program, at least)!
In addition I rotated in Photo Mechanic and inverted a JPG image (recognised by all the other software) but Photo Supreme continued to show the rotation as a quarter turn!
I repeated the test with a new directory and a dedicated PS image and the same thing happened. The problem appears to be with the way PS is handling rotation, or all the other programs are wrong or I am testing incorrectly (certainly possible, I don’t use PS Lite much) or all of the above!!
I am afraid your little “cheat” is no longer working because of the DOP change but the truth is that Photo Supreme 'Rotation" appears not to be compatible with other software.
If what I have said appears to be correct then we need to see if there is a “cheap” strategy that might work but it is breakfast time so bye for now!
Let’s make sure that we’re talking about the same thing.
Rotation is mostly used to adjust tilted horizons.
Orientation is about whether an image was taken in landscape or portrait orientation.
Sure enough, DxO calls orientation “Rotation” in its .dop files and gives the tag integer values between 0 (camera grip right as seen from the photographer) and 3 (grip up). DOP files are for PhotoLab “internal” use and are ignored by other apps.
In XMP, orientation keeps its name, but the values are different, including values that allow mirroring an image vertically or horizontally. The values tell us, how the image from the sensor should be treated in order to display “correctly”, e.g. sky over land, not left of it.
@platypus & @john regardless of the semantics of the situation and given that just about every piece of software I have refers to ‘Rotation’ for the act of flipping an image around, I found the little arrow symbols showing how to “turn” images and that is what I pressed!
@john sorry but I have forgotten what platform you are on, I know @platypus and @joanna are Mac and I am Win 10 (I think) but I have forgotten what you use. Photo Supreme is both, FastRawViewer is both so no clues there!
What it is called does not change the “problem” but does at least give me a another search word to use when looking for similar issues etc…
The following doesn’t really help a whole lot either!
Test:-
Opened JPG image in FastRawViewer and did a ‘Rotate 90 CW’ (another package that has got it wrong!)
The following detected the change
PIE shows a 'Rotate 90 CW)
PL5
Zoner
Exif Pilot shows an ‘Orientation’ of 6
Photo Supreme
The following did not
Photo Supreme - removed
Photo Mechanic
FastStone Viewer
ACDSee
XnViewMP
Adobe Bridge
Affinity
ExifPro
I then repeated using FastStone Viewer ‘JPEG Lossless Rotate’ (!?):-
Found:-
PL5
Photo Mechanic
Zoner
FastRawViewer
Affinity
Adobe Bridge
ACDSee
XnViewMP
Photo Supreme
Not Found:-
PIE
Exif Pilot
Photo Supreme - Removed
I should repeat the experiment with other software doing the rotation (sorry re-orientation) but it is lunch time!
However, I think that the major takeaway is don’t rotate/re-orientate/orientate your images until you have checked what might or might not be detected by other software in your work flow!
EDIT 01:-
Sorry but there are errors in the above. Photo Supreme leaves the displayed thumbnails alone but double clicking to access the additional image editing options then detects the change in the images.
PL5 changes appear to be detected by all programs!
This statement needs to be amended as shown
“However, I think that the major takeaway is don’t rotate/re-orientate/orientate your images until you have checked what might or might not be detected by other software in your work flow and understand how that detection shows itself!”
Im W10 and I found oftern PS leaves thumnails wrong (but not always). I was told “Best is that you correct the wrong orientation tag in the Image Details->Technical.” Its more constant but odd range of rotations
As I use FastStone Image Viewer to do my inital weeding I tried rotation in that. Its intresting as its not effecting the thumbnail in W10 or Affinity Photo but in PL5, FastRawViewer and Photo Supreme 5 thumbnails were correct as were full screen displays. Using Photo Supreme the W10 thumbnails were right (correcting through Technical). So for me it looks like doing corrections at my inital stage with FastStone would be woth doing as I don’t have many to do so the very miner inconvenace of W10 incorrect tthumbnails isn’t a problem. Its more constant that changing in PL5 that requires me changing the orintation again when copied to the 2nd PC as I found the change in PL5 wasn’t carried over when copying between PC which is why I started this query on rotation
There are clearly a multitude of varying ways the programs are righting this things and reading in many cases just some of them.
Out of intrest I have copied the test to the laptop and W10 is showing it correcty rotated
@platypus FRV seems to want to produce xmp sidecars in all cases at the “drop of a hat” but this can be prevented by selecting the following in the ‘Customisation’/‘Preferences’ option
@John7 thank your for the update! We just had a rain shower here so I “amused” myself by using Photo Mechanic to “rotate” all images by 90 clockwise, as you do, and the outcome was as follows;
PL5 missed one update in the middle of the group! The display initially showed an ‘invalid image’ and the directory contains 4 orphaned DOPs related to the way that PM makes updates - please see PL5.2.1.4737 (i.e. PL5.all releases) on Win 10 has Metadata change detection issues! for a ridiculously long description of how this happens!
Photo Supreme also got caught out and wound up with some of the thumbnails on display being intermediate temporary JPGs created by the Photo Mechanic update mechanism.
Once PL5 fails to detect a change @sgospodarenko that is it! Try not to have PL5 open on the directory you are changing at the same time you are making the changes, I never follow this advice when testing because I am looking for the timing holes in the software so that I can “vent my spleen” and have a good moan and try to persuade DxO to build a better product, one day it might work (and “pigs might fly”)!
After all the testing that I have been doing I am thoroughly disillusioned by how many software companies manage to code metadata handling with so many variants and create so much havoc! DxO had (arguably still have) an opportunity to get it right but I am running out of patience and other more pressing matters need attention.
This is one of the matters that needs my attention, I started chiselling out an area that looked like it was rotten below the paint surface and wound up removing half of the timber sill. The repair now needs to be completed, re-pointed and painted!
I just “flipped” all the images copied to a new directory with FastStone and file manager shows all the JPGs flipped, FIV did object to trying to change the one RAW in the directory!
@joanna why PL10 in particular, it isn’t going to take that long to finish that particular job and we need to have moved long before that!
Or are you using it as a metaphor, i.e. that every time I start digging into a “problem” with PL5 it gets bigger and bigger, until half the product needs replacing, which fortunately isn’t true!
The rot (in the sill) actually extends for most of its length and it looks as if the bitumen damp course under the wood has failed but having dug out a small area and then discovered another hole from the top the holes all joined up, so out went half the sill and in went a new piece of wood screwed and glued in place (PU glue actually likes, i.e. is activated by, damp).
The new part of the sill needed to be remodelled and rotated, sorry, orientated, actually rotated (slightly) is probably the correct term before being glued, clamped and screwed in place.
Or …??
and a new release of IMatch is installing as I write, it is all too …!
→ all original RAW files came up with Orientation “normal” in XMP and Rotation “0” in DOP
exported sidecars, duplicated them and renamed the copies to “AsShot”
adjusted the orientation in DPL so that the scissors pointed downwards (normal gravity here…)
exported sidecars, and renamed them to “Orient”
Summary: DPL stores Rotation/Orientation changes in both sidecars under the conditions outlined above.
What I learnt:
A shot taken with the camera held “belly up” lists as taken in “normal” orientation
Maybe it’s best to switch off automatic rotation in camera, if possible?
→ all shots will list as “normal” and might necessitate manual re-orientation.
Interesting, I have found no problem with RAW only jpg and I fear my phone doesn’t have any orientation options. In PL rotation was OK , but this wasn’t displayed in PS or when copied to anther laptop in PL. I at least now know to ignore rotation in PL but do in at the initial weeding stage in FastStone whose rotation works in PS, PL and my other programs and even in the W10 thumbnail’s usually AND it works copied between my PC’s in PL
@platypus this statement is nonsense and I have stated more times than I care to mention (and again in the post above Rotation not kept in dop’s why? - #25 by BHAYT) that ‘Rating’ and ‘Rotation’ previously stored and read back from pre-PL5 DOPs are still stored in the DOP by PL5 for all copies of an image, the [M]aster and the [1], [2] etc Virtual Copies but will never be read back from the PL5 DOP by PL5 for the [M]aster (frequently the only copy).
Time and time again I have used the WOM term, Write Only Memory, when referring to this but thank you for confirming that I have been correct all along!
The storing of the data is only half of the story and there is no change between PL4 and PL5 in that respect except that the DOP now holds a lot more metadata fields than before. The big change is in the reading of that data which for PL5 is now replaced by reading such data from the embedded or sidecar metadata for the [M[aster copy and not from the DOP! The Virtual Copies continue to rely on the DOP for storage and retrieval of metadata.
Indeed I started this asking how to overcome rotation not working with copies on another pc. Clearly for some odd reason V5 isn’t reading all the data in dops. Now with PL rotation needs to be done befor the imige is opened in PL by another program. Hope if ever they sort out this stupidity they will inform us but untill then really users are best to not use rotation in PL. As it impact on using PL I still regard it as a bug even if DxO for some odd reason see it as a improvement.
