CR3 files shown as EXIF corrupter/not editable in DxO after IMatch Metadata writeback

Good morning,

Yesterday I started trialing with IMatch as an extension for Mylio.
I let IMatch index many of my photos and it wanted to change “xmp: dc-subject” in the files. I let it do the changes.
Afterwards I checked file opening from IMatch in DxO PL3 and noticed, that DxO cannot read the CR3 files which were previously edited in it claiming “This image cannot be processed since its EXIF data cannot be read or is corrupted”. PL2 shows the same.
Strange is although, that both Lightroom and Canon DPP can open these files. FastStone Image Viewer is also able to open it.
I have backup of the original CR3s, but I would like to know what happened and where is a change needed.
I posted this also on the IMatch forum, but after seeing that other programs are not having trouble opening it, I decided to post it here, too.
I uploaded one original and corrupted file to as requested on other similar posts using “Bekesizl-Imatch_Dxo_CR3_corruption” as support ticket number.


Hello Zoltan,

Thank you for the feedback and files. I’ve sent the data for the analysis.

Svetlana G.

Hello Svetlana,

are there any news regarding this topic?
I restored my files, but I would like to know, if it is a bug in Photolab or in the other tool.


What happens if you write the xmp changes in iMatch when the folder is opened in PhotoLab? I noticed that when I do so with Lightroom, PL correctly updates its database with the changes.

Otherwise you could move/re-name/delete the DxO database file and see if PL can re-index the files in its database.

Thank you for the suggestions. I tried several ways (described in the IMatch forum post) and the real problem is, that IMatch is making a change to the RAW file itself with the help of Exiftool.
It is intentional and a way to keep metadata synchronized according to Metadata Working Group standards across different file versions (JPG, RAW, XMP), as I have understood from the developer. Now in this special case, it didn’t turn out that good, for PL3 can’t open the file after this metadata changes. Other software can.

This is why I ask the question, also to get the conclusion to other IMatch user, where the problem might be. Photolab or IMatch (Exiftool)?

IMatch forum post

PhotoLab IS picky about the raw files not being modified. I have come across some issues with my out-of-camera DNG files (Pentax) where there’s no sidecar file but the changes are written into the xmp section of the DNG file by e.g. Lightroom – I was using Optics Pro 9 at the time and remember it refused to open those DNGs. But recently I haven’t come across that issue with my files (I don’t shoot with that camera very often).

So generally I don’t like it when some software changes the raw file itself in some way, unless I am sure they implement the feature carefully. IMatch and its developer are very careful about these issues, so my conclusion is similar to Mario’s – let’s see what DxO devs say about the original and modified CR3 file.

I’m a long-time user of DxO/PL, mostly using Nikon (NEF files). I exclusively use IMatch (again, long-time user) for metadata additions and changes, including a few specific changes that affect content of the raw files (primarily ‘0’ Rating assignments by Nikon’s newer cameras). I sometimes use LR or other programs but don’t use them for any metadata changes. I haven’t seen any issues with corruption of images in PL.

I’ve also been a very long time user of IMatch and a user of PhotoLab since last March (now with PL3 Elite).

Like jch2103 I manage all of my metadata with IMatch and have never had an issue sending DNG or Canon CR2 files to PhotoLab after having entered my metadata into the raw images.

I do not have any CR3 images to test with.

Hello Zoltan,

The issue (you can see the ID tag in the title) has been created on our side for the investigation. About the further progress you should ask @Marie.

Svetlana G.


we will work on it but it was noticed to late to get the fix in next release (around mid-December).



I was wondering if there is an update on / ETA for the fix of this issue - I recently started using IMatch as DAM tool and when I write back the IMatch metadata changes to the CR3 files taken with my EOS R, those pictures can’t be read by Photolab any longer (error message as described by bekesizl in the initial post).

In Lightroom and FastRawViewer, there’s no issues with opening / modifying the pictures that have metadata updates made in IMatch.

Those were the only fields I modified in IMatch, so nothing out of the ordinary there:

Many thanks for all your efforts, I hope you can get this fixed - as it would be real a shame not to be able to use the best DAM tool in conjuction with the best RAW processor out there when you have CR3 files! :wink:


@Marie Do you have an update on the fix? In your previous message from back in November, you mentioned it was too late to be included in the December release, so I’m kind of hoping it will be included in the upcoming release…

Thanks & regards,


yesterday I installed version 3.1.1 which brought a number of bug fixes, one of them being, as per the release notes: “In some scenarios, images are not hidden anymore in PL after updating xmp files”, which I had hoped would fix the issue raised in this thread.

However after the installing update, those CR3 images on which the XMP metadata has been modified in another software (IMatch) are still not being displayed in Photolab, with the same error message showing as before: “This image cannot be processed since its EXIF data cannot be read or is corrupted”.

So I guess the bug fix did not address this specific scenario… As before, I’d like to hear back if there’s a fix in sight / whether this bug is still being worked on, as had been mentioned back in November 2019 by the DXO staff.

Thank you,

Despite the recent DxO update, CR3 raw files cannot be processed once metadata has been added in another app, in my case, specifically IMatch through exiftool. Other applications do not have this problem.

Glad to hear I’m not the only one facing this roadblock, @peterjhb

Actually, since there were no further replies from the DxO staff on this thread despite my repeated enquiries over the last month, I opened a support ticket of my own a couple of days ago - I hadn’t done so right away when I came accross the issue, as the original poster of this thread had opened one and I assumed the bug would be adressed, based on @Marie’s reply from November 2019:

Anyway, the reply I got from the support team representative less than one day after opening the ticket reads a lot differently:

DxO support, February 12:

All of the modules used in DxO PhotoLab are created using extremely precise measurements of actual output files from specific camera and lens combinations. In order to get full compatibility between your photo files and PhotoLab, as well as insure that you get the best results from the program, no changes should be made to any of the original photo files prior to their use in PhotoLab. Even the slightest change or shift in position of photo data will cause unexpected and unsupported results in the program. From the information you have provided to us, it appears that the IMatch is making changes to the original photo file data, and this is causing the incompatibilities you are experiencing. Lightroom and FastRawViewer do not perform the complex optical processing that is done in PhotoLab, and are not impacted with these changes. Therefore, we recommend that for those photo files you want to use in PhotoLab, that you use the files directly into PhotoLab and then store the processed file on IMatch. Keeping in mind that your original files will need to be stored in a way that they are not altered in any way from what is created by your camera. You may also want to contact the manufacture of IMatch to see if they can provide a way of not changing the original photo file information.

So I got in touch with Mario, the developer of IMatch, who confirmed that his software, which uses ExifTool to write metadata to the raw files, does not change any image data, or any other fields than those metadata fields the user wants to update in general:

ExifTool is modifying the metadata sections only. It does not touch the image data. The files can be processed without problems with other leading applications, including the very picky Adobe Lr, Photoshop ACR etc. It’s only DxO which refuses the files.

While I’m waiting on further feedback from the support team, it would be nice to get some clarification on whether or not this is being investigated, because while Marie’s reply here reads like “We’re working on it, fix to come sometime soonish”, the support team’s answer can be interpreted as “That’s how it is, deal with it” (but maybe that’s just a canned reply from support, not being aware of the bugs being looked into by the devs?)

Sorry if I sound a bit bitter, but getting any kind of feedback on this issue has been a pain - it almost feels like such uncomfortable bugs are being ignored, but since all the new Canon cameras being released going forward will use the CR3 format, I don’t think it will just go away by itself, so in the long run it should be in DxO’s best interest to get this solved, considering IMatch is a popular DAM solution among Photolab users…


Hello philou,
I can understand your concern. I have been working with Expression Media, Media Pro and now Photo Supreme as DAM. I have always been writing into to raw file - never an xmp sidecar and have never had any problems with DXO. The proposed workflow from support is not acceptable.
I want to key word, label, geo-tag etc… my raw files and then work with them in DXO.


1 Like

Thanks Sigi, and agreed - it really should not be an issue to modify keywords and a few other standard metadata fields such as copyright information and geo-tags in a dedicated DAM tool before and still being able to process the images in Photo lab; particularly since PL’s own DAM capabilities are only just being built up, so it’s not like all of this can be done in PL directly.

I geotag my raw files regularly without having issues in PL. So this is not a problem which is always caused by PhotoLab.

Now there are two software packages not totally interoperable. Which one is to blame? In lack of standards (raw files are proprietary), that’s hard to tell.

Perhaps you could find out which manipulation exactly done by imatch causes the issue. Exif tool may help in this analysis. Then it may be easier to argue with both software vendors to resolve the specific situation.

Generally spoken DxO promises to handle the RAW file from the camera, not the arbitrary output of any other software.

Thanks Philou. I was the OP in the IMatch thread and noted your contribution, so decided to have a go at DxO as well. Let’s hope that DxO corrects this anomaly.

Thanks Christian - I agree, it seems like Photolab is having this issue when IMatch is used, and apparently not some of the other DAM programs out there (as also pointed out by Sigi), but on the other hand it is only Photolab that’s unable to read CR3 files after any changes to the metadata were made using IMatch, while Lightroom & co. don’t have any issue with reading those files.

Also, since this issue is limited to CR3 files, I assume there is some kind of weak point/sensitivity to any unexpected changes in the process of decoding those files (process that DxO had to reverse-engineer since Canon doesn’t share their recipes for that).

So yes, I’ll try to compare the CR3 files before and after the metadata writeback using IMatch, but I’m not 100% positive that ExifTool will show all the potential changes in the data structure… And honestly, appart from not necessarily having all the tools to investigate this, I don’t think it’s the customer’s job to do so, even though yes, I’m happy to help out when I can, but at some point some feedback/intervention from the DxO staff will be required… hint! :thinking: