Can such pictures be found somehow? (Sure with a grep on all DOP files, but otherwise?)
Not that I know; grepâing on dop files is how I identify them.
DxO has shown no interest in fixing this Mac/Win incompatibility. However, they have removed statements from the User Guide claiming that âMac and PC sidecars are cross-compatibleâ, so I guess thatâs their solution.
âŚshould be possible by looking into the database. I have no idea what to search for though. Maybe @BHAYT can help with his knowledge of such things.
as @asvensson writes above, there are a few things that can spoil the joy of migrating DxO between platforms.
- DxO doesnât provide means to do so
- Apps have (slightly) different features
- LUTs, DCPs etc. are not embedded in the settings sidecars
- Possibly other things
Workarounds for the above
- None, except DxO or somebody does something about it
- Take whatever works and forget the rest
- Copy the stuff to the new computer and reconnect it - if you have the .dop files
- Take your money and run?
Now, if, like what I understand from @RobiWann , one has played around mostly, the best approach imo is to just start overâŚBUT: In the middle of migrating to a new platform, evaluating new apps etc. being too bold and too demanding could result in shooting oneâs own foot. And while weâre at it: DO NOT use Apple Fotos, but DO MAKE REGULAR BACKUPS!
@platypus Thank you for that, I felt that the day was dragging and I needed some sort of challenge!?
The SQL guys are better equipped than I at the syntax to put into one of the DB Browsers that can wander through an SQLite database, but at the moment I am not sure what field in the database indicates that a DOP has been produced, if any such field actually exists, i.e. you could then search on an entry in the database that doesnât show that a DOP has been written!?
The only structure that is really a candidate is the âItemsâ structure or its Mac alter ego and the fields available are
DB Items Mapping - Columns =
0 Id
1 CreationDate
2 ModificationDate
3 Name
4 StoreRating
5 StoreSettings
6 StoreProcessingStatus
7 Uuid
8 StoreOrientation
9 StorePickOrReject
10 StoreFormat
11 InputItemId
12 StoreProcessingDuration
13 SourceId
14 ItemTypeDiscriminator
15 StoreMetadataVersion
16 GpsLatitude
17 GpsLongitude
18 GpsAltitude
19 StoreShotDate
20 StoreShotDateOffset
21 StoreLabel
22 StoreColorLabel
None of which look a likely candidate to indicate that a DOP has been created or even that the data in the database originally came from a DOP but for every âItemsâ entry there is also a âSourcesâ entry.
So I turned off auto load and auto save in âPreferencesâ, loaded a directory and applied a preset to the third image only
and looked at the âSourcesâ entry for that image, looking at the field âSidecarNeedsToBeSavedâ in particular but it remains âNullâ !
So I canât find any field that would indicate that a database entry exists but a DOP entry doesnât, sorry.
No worries. Had looked into the DB and found nothing that looked promising at first glance. Somehow, the info must be in the DB, possibly as a link to a list of edits that will get written to the âoverridesâ part of the .dop.
Overrides = {
ColorLookupActive = true,
ColorLookupPath = "/Users/platypus/Documents/LUTs and Profiles/Fuji ETERNA 250D Kodak 2395.cube",
ColorRenderingActive = true,
ColorRenderingDCPMode = "Adobe",
ColorRenderingDCPProfile = "/Library/Application Support/Adobe/CameraRaw/CameraProfiles/NegativeLab Camera Profiles/Negative Lab - Canon EOS 5D v2.3.dcp",
ColorRenderingType = "DCP",
},
@RobiWann (note that LUT and DCP are referenced with links. If you used LUTs and DCPs, this info will not go to the new DB unless you edit the .dop files)
@platypus The edits are held in âItemsâ in the field âStoreSettingsâ and this looks like this for Image 3, sorry only joking, or rather it is here
Settings from a DOP.txt (9.8 KB)
and the DOP looks like and it exists because I used a previous test directory which had a DOP PL8 didnât read or overwrite, oops.
So I created a new directory of 3 records and edited image 3 and checked and the field was not set and a DOP was not created.
PS:- I then changed the options so that both are set, made no edits and shut down the database and no DOPs suddenly appeared and they wonât until I either export or make another edit to image 3.
So I closed the database and re-opened and, after checking for a DOP,
I exported the image and got this eventually, i.e. after the 20 seconds it can take for DOP writes to occur.
Anything that lives only in the database, so Projects and (I think) persistent Advanced History on Mac.
@asvensson Correct and of course all the data you may or may not want to search on which can be recovered, as described earlier, by an indexing operation, a non blocking operation on the Mac (I believe) but these days it is a âblockingâ operation on Windows, i.e. nothing can be done until the indexing is complete or âCancelledâ, where once upon a time the user could have continued to edit, export etc. while indexing took place.
When it comes to searching on metadata, Mac users can profit from the Finder advanced Spotlight search it provides. Almost anything you can think of from camera and lens metadata can be used.
1 Like
Spotlight can do many things, but I donât think I lean out of the window too far by saying that it will not find files customised in PhotoLab when there are no .dop files.
Happy to be taught otherwise.
Good point - Thanks.
I see. I apply a flat linear DCP profile with optical corrections and denoise to every new RAW, and this explains why images get broken so often.
@platypus , @RobiWann The short cut I was looking for doesnât appear to be an option so the only way to check for missing DOPs is as follows and involves programming of one sort or another
1. Create a list of all the Directories (Folders) in the database:-
Turn the âFoldersâ structure from a linked list of individual folders back to the original directory structure.
Create an entry in a database with the reference number of the final directory alongside the full OS name. This provides a list of all directories that the user has visited or indexed in PhotoLab.
2. Determine the Images that are in the Database for each Directory entry just created:-
Access âSourcesâ one entry at a time, each entry represents an image that has an entry in the database, excluding Virtual Copies which share the [M]aster image entry (and related DOP) .
Use the directory name created at step 1 that is pointed to by the âSourcesâ entry, add the image âNameâ from âSourcesâ and add â.dopâ to create the actual name of a DOP, if one exists.
3. Check if the DOP exists:-
Do an an existence check for the DOP on disk, if it does not exist then add it to an output report of missing DOPs that then need to be created manually using the list for reference.
I want to create the part of the program to build the list of Directories referenced by the PhotoLab database anyway but while not incredibly complicated for each level in a directory there can be a lot of next level directories to be processed, right the way down (or up) to the final directory !
Currently I have no plans to pursue this further, except the code to âflattenâ the âFoldersâ structure to retrieve actual OS names
@platypus Could you do me a favour when you have time and send me a copy of a Mac database with a few image entries, some VCs plus with keywords and some IPTC data added.
I can then use that to explore just how complicated it would be to migrate from one platform to the other. There is no urgency but it might be useful, thanks.
This lack of a fixed location causes lots of problems
With windows I made the mistake of using folder in my user folder only to find with a new laptop the user name was instslled as a diffrent one allowed in the earlier onstall. The only way round was to creat a folder with the same name in users much to Windows displeasure to enable the old imiges to open in PL
When this was originally done support said the developers were going to finish of the development so this would be no longer a problem, but nothing was ever done
A known directory in which profiles could be placed (like there are for workspace definitions, presets, and more) would make the feature usable across multiple computers. As is, the UI says âimportâ when selecting profiles, but thereâs no proper import: all thatâs recorded is the path to the selected profile, and paths arenât portable.
I really donât understand DxOâs resistance to fixing things like this. In the DCP case itâs now been 6 major releases since the support was introduced in PL2. (I started complaining in PL4, I think it was.)
1 Like
Lightroom referenced photos RELATIVE to the database location (as far as I could tell) because I used to backup my annual photos along with the database to a USB drive and I could still open the database on the USB drive and access all my photos also on the USB drive. Perfect backups in manageable sets of photos.
Just wish DxO could have something like this. But then there isnât even an option to open different databases - we only have one unless we move databases around and trick PL into opening other databases.
A workaround I occasionally use is to switch databases by restoring a backup with the desired contents⌠or by editing the preference file. DPL on Mac does not list the location of the DB in the UI.
Note that itâs not necessary to create backups via the menu. DPL imports databases in their original form too.
@KeithRJ You have me confused because your name tag shows you as a Win 11 user, what do you mean exactly by not being able to move databases around?
On Windows you can set your database location to wherever you want using the âPreferencesâ option so in my case I could move it to my NVME (N:) or the E:\ or F:\ or ⌠any drive that is present on my system, even a removable drive which I could then detach.
Changing the drive in this way does not cause DxPL (Win) to look for a database at that new location and if not present create a new one, it actually copies the database you were using to the new location.
The database name must (will) always be the same i.e. PhotoLab.db
and I just tested it and it had copied the database I was using at the time to the new location. I havenât fully tested it to check whether the db is copied immediately or at the termination of the current editing session but I believe it is the latter.
If you are happy with the location but want to swap to another database then you can use the âRestoreâ function. This will copy the database the user selects to the currently designated location as âPhotoLab.dbâ.
You do lose the original identity of the database at that point, that is certainly true, it becomes âPhotoLab.dbâ and it is up to the user to remember is original location and identity to create a backup as and when required with the ârightâ name in the ârightâ location.
Is this latter point the one that you were making, i.e. that the database can have any name that you like as long as it is âPhotoLab.dbâ?
Can I see somewhere if DxO is finished with the index? After more than 36 hours, no new entries are written in the tables ZDOPSOURCE and ZDOPFOLDER but the blue bar is still moving. I donât want to let my computer run through another night because of the stupid software.
@KeithRJ - on MacOS you can edit the path and database name in the corresponding *.plist file. Works great here.
On Windows I had my own database name in different location. Itâs not a big deal.
Of course LR, C1 are here more flexibel., and this lack of flexibility will be more and more DxO problem.