[Mac]Photolab 2: "This image cannot be processed because of an unknown error. It may be corrupted or in an unsupported format"

PhotoLab 2.1.2 seems to work fine on El Capitan (10.11.6). I would be very unhappy to see DxO drop support for 10.11 for the next couple of years. All my work computers are on 10.11 which is stable and fast and reliable and doesn’t have any changes to the file system. I understand that Apple makes it difficult for developers to support more than current OS + 2 back, but forcing DxO users to update (Apple OS updates are not upgrades any more) to use PhotoLab would show a lack of respect for users’ time.

Give what we pay for PhotoLab I’d hope that DxO will respect our time.

This is not “DAM error”, whatever that should mean. I saw the same issue sometimes in PL1, especially when moving pictures to a folder currently opened in PL.

The workaround has been described: rename the picture or the folder. That forces PL to reread the file and it doesn’t match it to its internal database/cache anymore.

To avoid it in the future do not copy pictures into a folder currently visible in PL.

I believe the root cause it that PL tries to read the file before it has been completely written. Then it remembers the file as broken.

1 Like

I reckon this is probably due to the image-name being held in the PL Database file - but with different associated folder-location info from its current actual location.

Try deleting the database file (assuming you use Sidecar files and, therefore, don’t care about the database). See the General tab on Edit/Preferences for the location of the database file(s).

Regards, John M

The scenario you suggest of not putting files into existing folders is absurd. If I put my Spitfire images into a folder called Spitfires, then take more photos of them, where do you think I’d be wanting to put them? This only happens with PhotoLab so it is a problem with the software. The fact that no image was in an un-recognised format, nor corrupted, shows that something is wrong with the way PhotoLab is managing the folders. To rename it then rename it back again just so their database can work is not a viable work-around long term. Perhaps someone from DxO would like to step in here and comment?

1 Like

So whatever you are not doing is absurd? I shoot when I shoot, I edit pictures when I edit pictures. Before I edit pictures I copy the RAW files. Only then I start PL. Is this absurd?

That’s exactly what I did as well, we both work the same way. However, to not copy new RAW files into an existing folder with the same subjects, before editing them, is what I disagree with. For that folder to be un-recognised afterwards is a PhotoLab problem, every other software program can see them perfectly. I do not want 20+ “Spitfire” folders on my computer just so that PhotoLab can see them, I want one folder that I put my “Spitifre” images into. Now imagine every other aircraft type, insect, animal, landscape etc. that could have their own named folders; keeping multiple folders for each subject would be too much to manage.

1 Like

I am not sure if I understood it right, but what I did. I opened a folder in PL2 and while those images are shown in the image browser, I dropped another picture into the folder and the image browser just updated and showed this picture too. So for me here no problem.
I also already have pictures destination open in PL 2 while importing from my card with Nikon Transfer 2. Never a problem. The pics just appear while being imported.

If I understand above correctly then there must be another issue. I have never had problems of files appearing in DXO when I added new files into an existing folder.

I have not yet tried to import any new files into an existing folder, I commented that not to do so would be un-workable. However, the original start to this thread was because all sub-folders in my Z6 folder were not recognised by PhotoLab until I renamed the folder. This is the problem that I encountered. It seems like a PhotoLab database problem as no other software has a problem. Once renamed the sub-folders were fully recognised so there is no errors in the image files.

Peter - Your observation reinforces my suspicion - - Did you see this post ?

Regards, John M

Thanks John, I’ve seen your post and done it.



Did that solve your puzzle ?

John M

Seems fine for now thanks. I’m going to be putting many Z7 images on my drive next weekend, I’ll see if any further problems occur.


That’s excellent news, Peter.

I’m pretty sure that your problem was due to (something similar to) the following;

  • you imported your RAW files into a folder
  • PL “saw” these files, and added them to its database
  • then, somehow, the files were moved to a different folder - with PL being unaware of this.
  • PL was then directed at the new folder location … but, it had the filenames in its database with association to the original/different folder - and it “spat the dummy (pacifier)” !

This explains why, as you said, all other software was able to see/find the files … because they’re NOT using PL’s database to determine their location.

By deleting the database you are forcing PL to see the files (in your new folder) as new, not-seen-before images … and it will add them to the database with their new location details. All good !

Regards, John M

Even though this causes problems for some who are moving RAWs around - it is how a DAM should work.
You do not move files around. They stay and perhaps you add some more of them. But database and metadata does the job.

When DxO PL is trying to sustain a DAM db and some of us is pulling the rug from under its feet, it’s understandable it gets confused. :slight_smile:

As some other have voiced, an option to active/deactive the DAM would be a great option.

Personally I do not use the builtin PL DAM but instead I run Photo Supreme as a stand alone DAM and open all RAWs with PL but from within Photo Supreme.
Exported versions are saved back into the storage and then PhotoSupreme does update its db and all metadata, xmp etc.
This works as perfect as it could.


Excellent article.I really like this.Thank you for sharing tutuapp

I have had the same problem a couple of times and am not aware of having moved files - they have stayed in the same folder all the time. It happens (of course?) only to files that have been processed. Changing the filename (adding an a in my case) solves the problem, PL then removes the dop file and probably changes its database (haven’t checked that). I may even change the filename back afterwards, but it is certainly a strange workaround and shouldn’t be necessary. I haven’t tried the database, will try that next time, if it happens again.

Just got my Z6 and had the same problem. For me, the NEFs are saved as DSC_xxxxx and were not recognized by PL. Of course, as others have noted, other programs did not have any difficulty. When I deleted the “_”, PL2 read the file correctly. Seems kind of dumb - why should I have to do this? The only reason I use PL is for the raw conversion and lens corrections that both seemed better than Lightroom. Honestly, with the Z and the 24-70 f4 there isn’t much difference between LR and PL

I prefer the arrangement of the PhotoLab tools – they make more sense to me than Lightroom. I also prefer the design of PhotoLab: it looks the way I like an interface to look, elegant yet information dense and to the point. Design is important to me. In terms of processing, after comparing PhotoLab, C1 and Lightroom closely, PhotoLab’s big advantage is with high ISO images. PhotoLab literally offers two extra stops of attractive ISO with Canon files (Canon 5DS R image quality remains excellent to ISO 6400 and very good through its high ISO of 12800). The advantage is probably only a single stop with my Sony A7 III files (which only look okay at 12800 and fall apart at 25600 regardless of program). No Canon shooter should be without PhotoLab.

The other area where PhotoLab excels is sharpening.With the Lens Sharpness tool one can eke out more high quality and still natural looking detail than with any other RAW converter.

In terms of workflow, the nonsense with a database imposed on us really has to stop. The only sensible way to work with PhotoLab is to enable the .dop and .xmp sidecars. This offers two benefits: sessions are portable (move between laptop and main computer easily) and in the case of database corruption, all of one’s edit information is safe.

DxO has some of the best developers in the world and some of the poorest product planners.

Got same issue: Copy new photo in directory currently opened in DXO => Corrupted image.
Applied same solution: Exit DXO, rename directory, Open DXO → Fixed !

Thank you for the tip.

1 Like