Attn @Musashi : DPL 5.2.2.65 does NOT fix this issue.
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.
1 Like
…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!
1 Like
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.
2 Likes
This issue seems to be fixed in DPL 5.3.1.69 indeed. Thank you!
Note: other issues persists
- While EXIF shows the correct lens in the RAW file,
exported files present a different, generic lens - Note the swap of pixel dimensions from RAW to exported file
(dimensions are not swapped in DNG exports, thanks)
Exif in RAW
Exif in exported JPEG or TIFF
Notes:
- I think I have reported the lens issue in an other post, but I seem to be unable to find it right now…
- DPL 5.1.3.55 did not write any lens info to JPEG and TIFF
- Dimension swap is probably a design decision rather than an issue.
LrC always shows dimensions as horizontal x vertical in RAW and non-RAW
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…
- 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?
I’ve uploaded the file (again) at 17:48 ct.
Uploaded a new image, straight from the camera at 18:04 ct.
I just checked the image, and it’s working as I described. When you first load the RAW image in PhotoLab without having downloaded the module, you’ll see the same lens description as you see in the exported JPG. As soon as you download the module, we use the name from the module to have a better representation.
It’s true that this could be improved with the lens name from the Maker Notes, as it is clearer, but it’s also not always consistent in all images, and sometimes not even present at all. We’re currently discussing it internally to see what we can do about this.
@kettch, when I extract tags with exiftool -G -a -u, I see two entries of the correct lens description in MAKERNOTES. I can’t imagine that exiftool is checking the presence of DxO modules, so the complete description must be in the original file.
20140626-8376.cr3.txt.zip (4.7 KB)
I think it would be best, if all possible lens tags were checked. As ambiguities need to be resolved by the user (I’m okay with this) anyway. You could try to resolve ambiguities automatically, but I’d really prefer to decide it myself. Manual module selection has been requested in the forum before too.
While it might be better to do something wrong instead of being inactive in theory and a few fields, I feel that module selection is not one of those fields. After all, DxO is after “correct”. Getting it wrong seems to be the poor choice imo 
Yes, there are two correct entries of that field, but as I said, not all bodies and all manufacturers are filling those fields properly either. So yes, with that specific image and body/lens, it should work, but we also need to consider all cases, which is why we’re looking into it and discussing it, in order to try and improve it.
1 Like
Thanks for doing this. With all the proprietary RAW metadata formats (meta-dada), I feel that keeping a wider perspective should help. Nice, if one size fits all, but if it doesn’t, I’d go for asking the user. There is no shame in that. Only super heroes are on top of everything all the time…but we are only human and can relax, once we can admit it…
1 Like