Hi John, I mean the opposite. SSD are very fast so there’s no need to store information in a database (theoretically faster than reading two hundred .dop and .xml files for a total of six hundred files read to show a folder of two hundred images). Thanks to SSD high I/O transaction threshold there is very little performance penalty here other than loading the preview images, which happens whether or not the XML info (star ratings, flags, copyright info, headline/title, description, coloured labels – last three not available in the Photolab EXIF editor currently) is stored within the XML file where it belongs and not in the Photolab .dop file where it does not belong. DxO is breaking standards here.
It is almost criminal that DxO refuse to store metadata in the XML and only in the .dop file. It breaks photo application interoperability at no benefit to DxO users. DxO does so much right and then they sneak something like this in which frustrates existing users and makes non-users think, oh this might not work with my existing workflow. Worst of all it wasn’t always like this. DxO Optics did not try to bury info Wrong, issues with playing well with XMP files have bogged down DxO for the better part of a decade. In the past, DxO refused to even read XMP file ratings and Optics had its own rating system.