I am polishing my simple workflow and would appreciate some remarks.
My inputs are Panasonic RW2 files and the platform is macOS.
1. step: FastRawViewer - first culling of RAWs, colour and star rating and sometimes headline, description edits. I found the import to PSU maintains the above info from the FRV *.xmp but ignores EV correction and WB settings.
2. In PSU I do the 2nd culling, usual tagging, GEO and IPTC edits
3. Then from PSU I call DXO for raw development. What I found the *.dop file rating or reject, tag, untag labels are not read by PSU, but all image related info nicely merged, which is absolutely fine with me.
The method I am experimenting with is not to save additional versions - unless necessary for print etc -, but rely on the sidecar file of DXO. Using the share tool of PSU nicely generates, emails or uploads the DXO edited version of the photo without intermittent versions. If I reopen the same RAW image from PSU and do additional edits and then close DXO - without saving anything other than the auto save of *.dop sidecar file - the edits are updated. The only drawback I found is the thumbnail shows the original unedited viewer image while light table, details, GEO, assign, adjust or preview tabs reveal the DXO edited photo.
What are your views on the above approach?
Some additional remarks:
Occasionally I use Affinity Photo which also opens from PSU, but the edited version has to be saved. Either as *.afphoto or any usual file format. Luckily AP version displays perfectly and cooperate smartly as a placeholder. Other piece of software that I use is AuroraHDR which also opens from PSU but the *.auh file is a container file that contains the original HDR input files and PSU opens this container file - when e.g., verify folders or files command is fired - and adds the files to your catalogue creating duplicate images with different names. I discourage anyone to feed AuroraHDR files into PSU.
Sidecar - workflow findings
Re: Sidecar - workflow findings
As a DxO user I can confirm your 3rd finding; DxO seems to write non-standard metadata.
More generally, there's a thread on different workflows that may be of interest at viewtopic.php?f=57&t=23786
More generally, there's a thread on different workflows that may be of interest at viewtopic.php?f=57&t=23786
Re: Sidecar - workflow findings
Every time this comes up, I am again flabbergasted that the user base, of a popular tool like DXO, accepts that mainstream metadata is written in DXO proprietary files. That while the entire world in 2019 is using industry standards (XMP or even classic IPTC-IIM) for such data. For DXO users that means that if they opt to write such metadata to the proprietary DOP files only that they can not access that information outside of the DXO "eco-system".endre wrote: 29 Mar 19 23:243. Then from PSU I call DXO for raw development. What I found the *.dop file rating or reject, tag, untag labels are not read by PSU, but all image related info nicely merged, which is absolutely fine with me.
Please request them (remind them, because they know) to write such information in the format that the whole world uses.
This is a user-to-user forum. If you have suggestions, requests or need support then please send a message
Re: Sidecar - workflow findings
There have been several requests for DxO to adopt XMP - for example this thread today https://feedback.dxo.com/t/option-to-pr ... ars/7324/3 and this from November https://feedback.dxo.com/t/xmp-implemen ... l-dam/5672 - so they may eventually get around to it. They never have moved quickly.
It doesn't bother me personally as I only use DxO for image processing. But it will become a bigger issue now that they're starting to add some basic DAM-like functions to their product - particularly for any users who later want to move to a proper DAM.
It doesn't bother me personally as I only use DxO for image processing. But it will become a bigger issue now that they're starting to add some basic DAM-like functions to their product - particularly for any users who later want to move to a proper DAM.