I’ve just checked a few applications and this appears to work correctly for me so far (both, the new image listed as an “edited” variant in the related files popup and it replacing the original in the workspace if it was the first edit). In order to track this down, can you specify the following points?
Which editor(s) in particular triggered the issue for you?
Is the edited image an original (JPEG, RAW or JPEG+RAW pair?), or an already edited variant?
Does an edited variant for that image already exist?
Did you close the editor application immediately after saving the image, or did it continue to run for some time after?
I am using Lightroom Classic v13.1 at the moment.
The edited image is a copy of the original jpeg file, when I use the option “Edit a copy” in Aspect (which makes a copy of the jpeg, adding “- variant” as a suffix and then sends that one to lightroom).
There was no edited variant already existing before that.
I let Lightroom run after the export, and simply waited for Aspect to detect the new file created in the folder it watches.
To try and help show the problem, I recorded a short video with explanations:
Thanks a lot for the detailed reproduction! We do see the same issue when setting things up this way and I’ll aim to include a fix in the next release.
Okay, so 1.0.0-rc.27 fixes this in part. In part, because there are multiple issues at play here. The main issue was based on the fact that in the specific case where the file format and the exchange format configured for the editor are the same, the original file gets copied verbatim instead of re-encoding it. Before 1.0.0-rc.27, the copy was missing the “OriginalDocumentID” metadata, which is required for linking it to the original. This part is generally fixed now by also writing an appropriate XMP sidecar file.
Unfortunately, Lightroom ignores the XMP file and instead generates its own “OriginalDocumentID” when exporting the editing image. For the specific case of JPEG, this should be easy to fix by writing the metadata into the file directly and I’ll implement that for the next release. But for any other file format we still require the sidecar file approach (or would have to fall back to re-encode the file), at least for now, so Lightroom can potentially still be an issue there.
Another (known) issue that can play into this is that the whole variant detection and metadata/variant fix-up logic is only active as long as the “waiting for editor” activity is shown within Aspect. However, if Lightroom has already been started before Aspect, there is no (sensible) way for Aspect to know whether Lightroom is still running after handing off the list of files to edit, so “waiting for editor” will not be shown at all. We are still thinking how to change the approach so that the logic can always be active, regardless of whether Aspect starts the editor or not. The problem is that this can easily lead to images being detected as variants that really aren’t, and this needs some very careful consideration of all the different cases to minimize the chances for this to happen (internal issue #1588).
Ultimately, in the case of Lightroom Classic, we should probably write import/export plugins for Lightroom that perform the hand-off between Aspect and Lightroom seamlessly (internal issue #1589). And at least for fixing the variant relationship after the fact, the requested manual variant management functionality would also help.
The variant detection logic has now been revamped for 1.0.0-rc.28, so that new variants are always being detected, regardless of the “waiting for editor” state (which is also not shown anymore). Also, the “OriginalDocumentID” is now written directly into the JPEG file when JPEG is used as the exchange format. This fixes most of the remaining issues for this Lightroom setup.
