My gear is Canon EOS M5 and M6 mark II. I have used my EF lenses with two adapters:
1/ The Canon EF/EF-M, everything is OK in that case.
2/ The Viltrox Speedbooster EF-EOS M2 x0,71 and up to last month everything was OK. EXIF were right, reporting the right lens, the right modified aperture and leading to the indication that no optical correction module was available for these combinations. Now, and it seems that is from PL6 (I’ve removed older versions), in some cases the software tries to use the optical correction module of the lens, then detects it is not the right one, and finally refuse to process the file.
I found that bug when trying to process old files that have first been exported with PL2 (at that time it worked). Now PL6/7/8 refuses to process them.
I have found a workaround, selecting a preset with “no optical correction” solves the issue. But you need to modify the settings of you older files if you want to process them again (with DeepPrime for instance).
The subject is in the hands of the support team…
If you can share a few files, I could check them against PL1 to 8.
For newer versions, I can also check dot releases.
I kept the installers…and would test on Mac.
Use wetransfer or any share you might have.
I had the same problem with old pictures taken with the The Viltrox Speedbooster EF-EOS M2 x0,71.
I have opended already a ticket with the support.
Because the pictures are relative old ones, I didn’t recorgnized the problem before.
Thanks for your posting, now I’m not so alone;-)
My work-around: disabling vignetting and lens-softness.
But I hope for a bugfix.
I’ll do it later. I’m on a PC but it will be interesting. Many thanks.
We are not many using this speedbooster…
I believe they made a change because each manufacturer doesn’t use the same EXIF tag to indicate which lens is in place, that has led to problems with some lenses.
I have little hope that they will solve this issue…
I think the problem is, that they look at a not defined value in the correction table for this lens. Maybe in old PL-versions this didn’t throw an exception. Now the software works “correct” and we have the problem;-)
Here it is:
I’ve tested:
M5:
- after installing the moduls I get:
(Cannot get BxU value for XY position.) - deactivating the vignetting:
same error - activating the vignetting again:
same error - deactivating the lens-softness:
(m_vignettingData.InitWithDxOModule(*compositeModel, intensity, clipping, usePixelUnits); condition failed.) - deactivating the vignetting:
picture is ok
M6:
same
Even with M5 + 50mm?
anyway: there is a bug but we have a workaround.
in this case, PL didn’t found a correction-module, so there is no error;-)
Checked the files against PL versions 6.19.0 and 7.6.0 and 8.2.1
In all cases, DxO Modules were downloaded, except for the M5 & 50mm combo.
Looking at the file’s EXIF lens info with ExifTool,
I see that the M5/50mm with VSB has missing data in the Lens Model Exif tag.
Anyways, said combo has been supported by photoLab since version 1.0.0 according to DxO’s gear checker webpage and images (also of the other combos) should be processable with optical corrections … but they aren’t!
They only export when customised without anything that needs info from a module!
I therefore checked the images in PhotoLab 5.16.0 … and it found no modules at all - which contradicts the info given on the supported gear page.
Well then, it looks like DxO has changed something somewhere that produces the issue described in this thread. But why does the elderly DPL 7.6 that I’ve installed with an installer I had kept since April 2024 show the same issue? The only things I downloaded today are the modules!
Imo and in att. to @Musashi , this newly found issue requires a support ticket that should be handled with priority.
All I reported in this post was found with PhotoLab (versions mentioned above) on macOS 14.7.2 on a 5k iMac 2019.
Thanks.
What surprises meis that it worked in the past.
I think it’s like I wrote in #5: the new software throws an exception, the old one used a undefined value.
Not every bugfix is without side-effects;-)
Thank you very much, once again.
Yes, something has changed, perhaps to fix a bug for another reason…
The right behaviour is not to use the module but to make no optical correction as the Viltrox Speed Booster modifies the optical defaults.
I will put a link to this thread in the ticket I opened with the support team.
…characteristics too.
What surprised me most was, that images with their correct modules had issues.
Looking forward to DxO’s reply. I’ll not hold my breath though…
You shouldn’t be surprised: the modules cannot work when the converter is in place, exactly like when an 1,4x is on.
Well, let’s take a look at the images that get modules… I suppose that they were taken with Canon’s “MOUNT ADAPTER EF-EOS M”, a tube with different mounts and the necessary electronics to exchange info between the lens and the camera body - and without any optical elements. The combo of an M62 with an EF50 f/1.4 is supported by DxO and PhotoLab can download a module. Therefore PL should be able to customise and export such an image. But it can’t.
The only one image that can be customised and exported is the one taken with the Speed Booster which modifies EXIF tags in a way that prevents PL from loading a module.
The simple fact that PL 8.2.1 and other versions cannot export images customised with module-based settings contradicts the very purpose (and promise) of DxO PhotoLab.
Just for kicks, I tested with PL 4, which worked as expected.
I found a somewhat similar issue when trying to reprocess older files.
It transpired that DXO had changed the syntax of a line in the .dop file.
I that specific case a line had a quote mark changed from " to ’ (or vice-versa) and the new version would not read the info.
Try renaming the .dop file so it is ignored. If the issue goes away, that may be the reason.
Tech support found the problem for me, they may be able to do it for you.
Richard
Sorry, I can’t understand what you are talking about. All pictures are taken with the speed-booster. Only the M5+50/1.4 combo isn’t recordnized as the original lens, so there is no correction module used.
All other use the correction module of the original lens with the not defined parameter, which throws the exception - our problem.