Nightmare with DOP files

I just updated to the latest version of PhotoLab for MAC and every time I run the program it starts creating .DOP files all over my hard drive, in whatever directory it finds a JPG or RAW file. He has generated 50,000 before I left the program. How can I stop this “feature”?


I can’t help either as with the latest 5.2 on my MacBook Pro Monterey I see no .dop files in folders where I’ve gone until I make a correction.

JUst had this happen when I first used DxO 6. My main input file now has about 1,500 .dop files in it for images that I never touched with DxO. I would have never noticed it until I tried to move some of my raw files in Photo Mechanic and got an error moving the .dop file. Then I discovered that not only were files created that I didn’t need or want, but they were locked by DxO. When I closed DxO, the (useless) .dop file was able to be moved.

I’m currently going to delete all of these files, and hope they don’t get recreated.


DxO are battling over the database or no database approach. By creating a database that means any image theoretically which has ever been noticed by PhotoLab should have a .dop file. Otherwise there is information in the database which is not in the .dop which is what the no-database photographers like me want.

What would help here is if PhotoLab did not create .dop files unless there is a modification made to the image (including rating or metadata, although rating and metadata should go in a .xmp file and not a .dop file, as .xmp is a common standard for rating and metadata, while .dop is PhotoLab’s proprietary processing info). Mixing metadata into .dop is an act of arrogance and guarantee of future incompatibility with other apps and eventual data loss.

I hope DxO will pull up their socks on this and stop mixing image processing data with metadata, and to be honest just give as a version where we can turn off the database completely (which would mean reading the metadata for the whole folder on every load – no problem in these days of ultrafast SSD).


Agree 100%. There are only a few good DAM products out there. IMO, it either is a complete solution or none at all. I left Lightroom for Photo Mechanic and DxO. Photo Mechanic for its speed and superlative metadata handling and DxO for it’s fantastic processing. I don’t do any processing in PM and I don’t handle any metadata in DxO.

1 Like

My dream would be if PhotoLab would add support for PhotoMechanic cropping. Of course, the rule would have to be that if cropping/perspective had been changed in PhotoLab, the PhotoLab adjustments would have priority but in the case of an image where no crop or perspective adjustments have been made, PhotoLab would apply the PhotoMechanic parameters.

Adding a feature like this would be a great sales pitch to existing PhotoMechanic users (Lightroom and Photoshop already work with the PhotoMechanic crop) and quite an easy addition (just reading some parameters and applying them).

I’ve read/heard of a lot of people preferring cropping in PM, but not sure I understand it. Of course, DxO cropping with it’s tiny boxes leaves a lot to be desired also.

Why do you prefer cropping in PM, if I may ask?

As a sports photographer most of the time framing is putting the action in the center of the image (there’s no time for moving the focus points around, the central focus points work best, especially for high speed AF-C). That is not how I shoot non-sports, including theatre or dance, but long experience with sports has shown it’s the right way. PhotoMechanic is a big favourite with sports photographers.

The only framing sports photographers do in camera is zoom level.

Of course great sports images also benefit from wonderful composition. What sports photographers do is add framing in post-production. The first step when culling is to crop. Hence doing that framing while culling means one can make a much better selection of images. Cropping and culling for sports photographers are basically the same thing.

Carrying those crops over to PhotoLab would be a huge help. Since PhotoMechanic crop doesn’t carry over to PhotoLab I continue to use FastRawViewer for culling (it’s simpler and shows more of the RAW potential of an image than PhotoMechanic).

I use PhotoMechanic for metadata. Tried the PhotoLab metadata tools but they are clumsy, don’t include templates and ended up in losing a bunch of metadata and not having it show up in the final published version online – the usual mess for a half-baked feature created by non-experts (PhotoLab’s developers expertise is in RAW development and not in triage/metadata).

Eventually by trial and error the PhotoLab developers will figure out metadata (the first version was better than I expected) but it may take another two or three iterations (I mean full versions, i.e. three years) before it’s ready for prime time and that’s only if DxO prioritise cross-application compatibility (right now there’s some confusion in that PhotoLab follows specs on metadata but that the keywords are not read properly in other applications). I.e. if you value your metadata, better to continue to use PhotoMechanic, as metadata is all that CameraBits do, they’ve been doing it for more than twenty years and their image management software is used by every serious sports publication.

The only tools which compare with PhotoMechanic in terms of robust management of large numbers of images and metadata are usually enterprise only and cost $10000+. It’s a unique niche. While PhotoMechanic is expensive, CameraBits is only on version 6 which means at least three years between paid updates, which are fairly priced as with DxO, but happily much less frequent.

Agree that Photomechanic is top notch, an example of very mature software performing very well indeed at what it does.

Photomechanic support is also amazing, they have responded to me via email in a few mins of receiving my query. Highly recommended.

1 Like