JPGs exported from external editing software, when done from a RAW file shot in portrait, end up rotated 90deg. Using the bottom button to rotate them also rotates the raw file, so one of the pair is always wrong
Expected behavior
JPGs exported from an external editing software should appear on the same orientation as the RAW file
Steps required to reproduce
Import RAW picture in Aspect (drag and drop)
Right click, Edit with, Develop raw (Personally DxO Photolab and Lightroom)
Do a minor color change for example, no transformation whatsoever
Export from the external editing software, no change in resolution, keep all metadata
JPG now appears in Aspect, rotated 90deg counter clock-wise
Operating system/Hardware used
Windows 10 with Aspect 1.0.0-rc.15
Here is a WeTransfer link to a .RAF file for the example, if that helps:
A quick explanation for why this happens: Before opening the RAW file in the external editor, Aspect generates an XMP sidecar file (DSCF1002.xmp in this example) that includes a document ID used to associate it to the developed version that gets saved by the editor. This sidecar file also includes the rest of the metadata of the RAW file, including the orientation field (which is 90° CW or CCW in this case).
When the external editor now saves the edited image, it will already physically save the image in the correct orientation, without the need for setting the orientation field. However, when it is saved with the same file name as the RAW file (e.g. DSCF1002.RAF and DSCF1002.psd), the XMP sidecar file will now also implicitly apply to the edited image and will thus erroneously cause it to be displayed rotated by another 90°.
This is a fundamental issue with ordinary XMP sidecar files, and to solve it, we’ll have to deviate from the usual DSCF1002.xmp naming scheme and move to DSCF1002.RAF.xmp instead. The problem with this approach is that only a few programs support this kind of sidecar naming scheme, which would hurt interoperability quite a bit. Most likely, the best approach here is to only fall back to the more explicit naming scheme when there actually is an ambiguity.
Things get more complicated, though, because in the case of a RAW/JPEG pair it’s actually desirable for the .xmp file to apply to both at the same time, so that edited metadata stays in sync between the two representations of the original and also to maximize compatibility in this common case.
For now, the main workaround is to choose a different name for the edited file (e.g. DSCF1002 edited.psd). I’ve added an internal ticket (#1551) to keep track of this.
Ah I see, thank you for the detailed explanation (and such a fast one!).
Maybe I should make a new topic for this, but in the case of adding suffixes to a file, is there any way to tell Aspect that it is a variant of the raw?
From my tests, Aspect only detects variants if it exported the jpg or dng itself, or if it has the exact same name, in the case of an export from an external editor.
Adding a suffix would be a great solution for me, as long as it is still detected as a variant only, therefore keeping the rating and all characteristics applied in Aspect, instead of appearing as an independent picture.
I think when using Photoshop/Camera RAW for RAW development, together with the “Develop RAW” menu entry, the resulting file should be properly associated with the RAW file. However, when using Lightroom, no .xmp sidecar gets generated for the RAW file and Lightroom instead just assumes a certain document ID for the RAW file. Unfortunately we don’t know the method for determining this document ID and thus cannot associate the resulting file with the RAW file.
I’m not sure about Photolab, but I’ll recheck how it behaves. Looking at the file name could actually be a good heuristic to make this work.
I agree an additional manual control over variants could be a good ‘safety net’ to handle exceptions from certain editors, even though it will obviously mean more work for you guys, and the file name seems like a strong enough option to me.
Personally I always keep file names consistent with the raw file name, and only append suffixes if I have to export dng, psd or whatever file derived from that raw file. Only the client export gets renamed for their convenience. It seems to be a broad, natural convention that you don’t rename things until they’re shared, and even then, anything that I share in my name keeps the same base name, because there’s simply no need to change.
Anyway, thank you for these explanations, I understand it’s out of your control and that different editors work in different ways, you can’t safeguard every single possibility.
And thank you very much for bringing Aspect to life. I’m only a few days in, testing every possible workflow that I need and see how to adjust myself to it, and it works wonders so far. I didn’t think I would actually take pleasure in using a DAM at some point, and yet it’s happening.
I’ve opened a ticket for implementing the file name based association now (#1553). Thinking about this again, it seems like this would be a big improvement without much risk of being harmful, so it definitely makes sense.
And thank you very much for bringing Aspect to life. I’m only a few days in, testing every possible workflow that I need and see how to adjust myself to it, and it works wonders so far. I didn’t think I would actually take pleasure in using a DAM at some point, and yet it’s happening.
Really happy to hear that! I wish I had more time for some actual photography these days and to play around with some possible new workflow ideas. There are definitely some neat organization approaches being made possible by the collection bar/shortcuts and taxonomies. And we really need to make a few videos with some examples.