Copy paste error, was a different subversion. But this does not matter, the bug came in somewhere after DPL 5.1.
Update:
DPL 5.1.3.55 is working as expected
DPL 5.2.0.56 is exposing the issue already, I also noticed that progress with rendering thumbnails pauses for a few seconds at the image in question, before rendering the remaining images. No warning or comment is given though. Can’t see any obvious logs or loge entries too.
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 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!
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.
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.
The RAW file seems to have a clear enough lens description in the MakerNotes,
according to what I can see withExifTool. Why replace something that looks correct with something that is incomplete and wrong?
Maybe that ExifTool is better at recognising lens types than the “thing” DxO is using to read MakerNotes, assuming that DxO doesn’t use ExifTool.
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?