@roj The act of opening a directory while “browsing” in DxPL automatically imports the images in that directory into the database, i.e. it is an implicit import rather than an explicit import. It was one of the reasons I purchased DxO OpticsPro11 since it cut out the whole explicit import process!
But with that automatic (implicit) import comes the associated automatic render every time an image is “selected” even if that “selection” is simply traversing over a thumbnail to get to the image you really want to access.
It would be good to retain the navigational working of PhotoLab but with the ability to select whether that directory should be imported or not. In addition it would be good to be able to select when images are rendered to speed up navigating over 1,000 images to get to the one you want!
While this would add an element of complexity to the simple interface, the current method could be retained for absolute simplicity, while offering selective importation and selective rendering to enable increased speed of browsing/navigating and reduced power consumption!
@roj why do you suggest that the database cannot be transferred? I do not know the exact circumstances you are referring to nor the platform you use.
I believe that the limitation on Mac systems is that the location of the database is fixed? Whereas that limitation does not affect DxPL(Win) users.
I can copy the database between any of my three Windows systems and open them in a copy of PhotoLab with the only real issue being the fact that the database is upwards compatible but not guaranteed to be backwards compatible (that certainly applies to DOPS and I believe also to Presets).
But if I open that database without the correct disks being present then DxPL will essentially ignore any database entries where the ‘UUid’ (Partition Id) does not correspond to an entry in the ‘Folders’ structure and re-import the images (and DOPs etc.) again!
This creates potential problems for ‘Projects’ (Win & Mac) and ‘Advanced History’ (Mac only - Windows has no ‘Advanced History’ retained across sessions) which will still be in the database but referring to now “missing” images.
This is a major problem with my fixed disk subsystem even though the drive letters and drive layouts are identical (certainly as far as my image library goes) but no real problem if I take the images over on a USB drive, i.e. it is possible to carry images from a laptop to a bigger home “beast” on portable media and transfer the database along with them, either located on the same disk or transferred via the same disk to be located in a fixed DB location (Mac) or a preferred location (Windows)!
This certainly becomes a problem if you want to use both systems at the same time unless/even if you are scrupulously diligent.
Moving the database with the images ,which must be on a portable device (or prised out of one system and installed into another), should be fine. For use by DxPL(Mac) the database must reside on the system not on the (portable) disk on a Mac (I believe).
Having the database on the same media that is being moved between systems and then used directly by DxPL(Win) is possible on a Windows system. Even if that disk is given a different drive letter the ‘UUid’ I referred to above as a “problem” means that DxPL(Win) can locate the disk in the database and all should be fine (please see Test comments below).
Moving data between systems with a DxPL database on each runs the risk of having the DOP UUid not matching the database ‘UUid’ (under certain circumstances) and causing “Unwanted Virtual Copies”!
But @roj what scenario are you referring to in your comment and what platform do you use?
Please note a DxPL(Win) database cannot be used on a MAC and vice versa.
To confirm what I had written was accurate I took and old USB3 SATA SSD I used for tests some months ago which contained the database and the data and added them to my main system (PL6.9.0), selected the database on T: and navigated to the ‘Projects’ and attempted to open the first project and DxPL hung @DxO_Support-Team!
Task manager was used to terminate DxPL and I restarted it and the first project was now O.K. but the second project Hung DxPL, so it was terminated.
3rd. restart and the first, second, third, …seventh Project were O.K.
I attempted to repeat the test on my Test Machine (PL6.6.1) and could never get the ‘Projects’ to successfully open, the machine hung every time!
On to the third machine (PL6.7.0) and that was a repeat of machine 1 and the system was fully operational on the third restart where the drive letter is D: (not T: on this system)!
So, ignoring the bug, I can move the data and the database between machines with different drive letters being allocated with no problem(!?) whatsoever on DxPL(Win), but only if the data remains on the same disk with the same UUid (Partition ID, or Drive number or whatever is the correct term for the identifier)!
PS:- Both sources of edit data are on the same drive in this scenario so backup the database regularly to an alternative drive. However, DxPL does not provide a solution that allows a drive with the same folder structure and images to be “matched” with the database in the event that the data is lost.
I have documented a “kludge” in another post but DxO should provide a cleaner mechanism!