As of today, DPL 5 stopped processing an image that never gave any problems so far.
DPL4 processes the image in question without issues.
You’ll find the image(s) on your server under my forum name.
Here’s the message I got:
Note: DPL 5.1.3.55 exports the imag(s) without issue.
Tested some more and found that all files exported as expected, when I
On the other hand, when I change the preset and undo it, the “offending” file does not export.
This means to me that the issue is not caused by export, but by the application of the preset.
Note the it does NOT matter, which preset I use.
DPL 5.3? Interesting 
Copy paste error, was a different subversion. But this does not matter, the bug came in somewhere after DPL 5.1.
Update:
I checked it and was able to reproduce it. It’s being taken care of with another team, so we’ll ping back when there’s news on that.
It seems like it’s linked to the lens field in the EXIF that may have issues.
…that’s what I thought too. The lens ID is unknown to the firmware of the camera,
but up to DPL 5.1.3, PhotoLab was able to work with the file without any issue.
att. @kettch: ran another test with that file and was able to export as DNG with DPL 5 on macOS Monterey on Apple Silicon MacBook Air 2020. Other tests on the iMac have shown that JPEG and TIFF export does not work, DNG does - and I just found out that it’s probably because the corrections are NOT applied to exported files here!
I’ve just found out, that the handover to Nik works, when I switch metadata off in this dialog:
The same in DPL: Switching off metadata exports makes the image processable…
More tests: Switching off EXIF is enough to make the export work. All other items can be left on:
I ran a few more tests and found, that DPL (as well as Lightroom Classic) did not seem to work with the full lens specification that is available in the file’s makernotes. Both Lightroom and PhotoLab exported wrong lens info - along with the correct lens info “hidden” in the makernotes.
Maybe that reading info from makernotes is considered “difficult”, but why can ExifTool give me the correct and full specification and the other apps don’t?
What’s more: In DPL, I specify the correct lens in the lens ambiguity window. This seems to be used for module selection, but not for metadata, what a waste!
This issue has just been fixed on our end. The fix will be available in an upcoming version, we just don’t know which one yet.
Thank you for taking the time to prepare the update. Hope it makes it out soon, so that I can move on from version 5.1.3.
reminds me of the confusion I’ve seen in two “statistic apps” (Statistica and Excire Statistics): In the beginning most of my images didn’t contain the lens manufacturer as Sigma uses another EXIF tag than other lens makers. Woth this mess created by various participants of the “export/import meatdata” workaroundflow it’s no wonder that DxO doesn’t want to bother about a DAM. 
It took its sweet time, but the fix is coming! This should be release in version 5.3.1, in the coming days.
This issue seems to be fixed in DPL 5.3.1.69 indeed. Thank you!
Note: other issues persists
Exif in RAW
Exif in exported JPEG or TIFF
Notes:
While EXIF shows the correct lens in the RAW file, exported files present a different, generic lens
This first issue is actually behaving as expected: on original files, the lens name that is shown in the EXIF palette is the one coming from the module name, because it’s usually more descriptive. On exported images, the module is not applied, and so what’s being shown is the actually lens name from the EXIF of the file (which is the one that was also in the original file).
Note the swap of pixel dimensions from RAW to exported file (dimensions are not swapped in DNG exports, thanks)
There might be an issue here, but not necessarily on the exported JPG. The dimensions should be adjusted for the EXIF orientation, and it may not be the case. We’ll be looking into that.
Hmmm…
I’ve extracted metadata with "exiftool -G -a -u* from the original RAW file and exports made by DPL 5.1.3 and 5.3.1.
Archiv.zip (34.9 KB)
I was assuming that it was indeed the one from the EXIF, but if it’s not, then there’s certainly an issue. Could you also send the image through DxO Upload?
I’ve uploaded the file (again) at 17:48 ct.
Uploaded a new image, straight from the camera at 18:04 ct.
