@ianc - If you move everything within PL5 using the Library window and the folders on the left, all correction parameters are retained.
@platypus - agreed, but the interface is really basic. It doesn’t handle folder manipulation at all, you cannot create or delete folders, and in the Library view, the moved files still appear in the film strip until you re-sync.
This speaks to an incomplete implementation of the Library functionality. I was kind of happy when it first appeared back in PL3 or PL4, but its clunkiness kept me from using it, so I went back to the OS. Now I have to use the Library.
I can live with the h/a library if I am not forced to use it. But DxO really need to fix “Import Sidecars” so that it imports everything in a sidecar.
Thanks, I will try that. I’m guessing that it means that PL needs to keep track of where all the files are ?That means it storing info for all my pictures (many GBs that I may not look at again for years), and not be able to move file around on my NAS outside of PL. It does seem inconsistent that some image metadata is stored in sidecar files and some not.
I have just finished building a new Win 10 PC and am installing software on it. After reading this thread I’m very concerned about losing my PL4 & 5 edits.
I don’t use any database features in PL and had planned to just copy all of my photos to the new PC. I have installed PL5 on the new PC but haven’t copied any photos to it yet. I understand that the issues mentioned above can be avoided if the files are moved by PL5. In my case though I will be using a new PL5 on a new PC and I don’t see how that could be accomplished.
You’re using the database whether you realize it or not – it’s not something you can enable or disable on a whim.
If you maintain your database from the old machine to the new, you should be ok. There is an option to export a DB, and a corresponding option to import one. I’d try that on a few images at first and see how well it works for you: export from PL4, import to PL5.
When I migrated from PL4 to PL5 I don’t recall taking any special steps for DB migration, which may have been part of my problem.
Thanks for the reply Rex. To be clear I am not migrating from PL4 to PL5. I previously did that on my old PC. I am going to move my photos to a new PC with PL5 on it.
I will look for the DB Export & Import options. My concern though is that the new PC will have a partially different folder structure than what PL5 is currently running on the old PC. So I wonder if the imported DB wont be lost trying to find the files that will be in different locations.
Yes this will definitely be a problem. The PL5 DB knows which folders your images are located in, and if that changes without PL’s awareness, the image corrections are lost. I’ve complained about it quite a bit, but I see some new PL versions coming on-line, so I will hold my tongue for a bit until I can verify those new versions.
In your case, I might suggest implementing the new folder structure on the old machine, if at all possible, by moving the files around under the PL “hood” so to speak. Then when satisfied, take the export, and move everything over to the new machine.
The other part of this that is IMHO annoying is the clunkiness of the PL5 move operations. About half the time the files fail to move at all, and every time, the images I have moved still show in the from-folder until I re-sync. And I’m sorry, I promised to hold my tongue…
Anyway good luck. You have two machines and what apparently looks like some ability to verify everything before you decommission the old machine.
Copy a bunch of pics with their associated dop-files on a stick and put it on your new machine.
With a brandnew database you loose star ratings and keywords.
Otherwise try the same thing, but first copy the old database to your new machine …
You then still can start from scratch.
…yes, or move the old structure + database over and reorganise on the new machine, which might be more powerfull and less impregnated by leftovers…
2 Likes
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
30
The Photo Library is to be considered being 1.0. It is first in version 5.x that we got something that looks like an Image Library at all. In fact I was pretty surprised that it’s as good as it is despite it lacks a few things.
This discussion here I think is a little bit unfair too. I don´t think there is one single library software that is comfortable with people moving folders and files outside the application. If you do things like that you have to act to resync and the discussion would be more fruitful if we could have a discussion about the tools in Photolab to resync.
There are a few ways to solve metadata issues: either have a consistent way of storing the edit changes and IPTC-metadata in XMP-sidecars along RAW-files or writing it all into the XMP-headers of XMP-compatible files like with JPEG:s (TIFF:s that doesn´t really have an XMP-header) and DNG:s. Depending only on a proprietary metadata database like in Lightroom is to ask for single point of failure crashes. In PL the problem is the opposit. Here we have XMP-sidecars, DOP-files and a database - and not to be surprised all sorts of syncproblems instead.
For most RAW-converters the RAW-file integrity is holy but not for Sony for example because they write edit data straight into even the RAW-files in their software Imaging Edge. Bad? Well I can see one advantage with that aproache. All the settings made in their cameras like settings in their style sheets e.t.c. are all saved into the files and are read by their converter.
Personally I´m not at all pleased with this mess. Ideally I would prefer that they would be writing both editing data and IPTC and EXIF metadata both to XMP (to sidecars or into the files) and EXIF too for compatibility reasons (because some old software like for example Windows is not compatible with XMP and prefer old fashion EXIF since it doesn´t read the EXIF namespace in XMP). If they had done that and someone had moved a folder outside the application it would have been fine just to just reindex that folder/folders. After a reindex the new search path would be written into the files XMP instead of the old. They could still update the corresponding DOP-file/files in the same reindexing process of pure compatibility reasons but since DOP is as proprietary as the Image Library database the master has to be the XMP-data since that is the only ISO W3C-standard we have to lean on.
In the new version 5.2 there is supposed to be a conflict resolution tool at least.
If they could migrate all this metadata to XMP as a metadata master the only thing we should have to do would be a reindexing of the folder/folders we have moved - even the ones moved outside PL. Even a metadata system like the one in PL has to have one master source and not several as we in practise have today. There also has to be possible to chose if Photo Library in PL or an external application shall own the data because that decides which direction the workflow shall have. It´s never a good idea the use bidirectional metadata workflows. That is also to ask for problems when data might get forked differently in the different directions.
Even if we use PL and Photo Library today we always have to be prepared for the day we have to migrate of some reason and today and for the forseable future XMP is the only standard there is to secure a smoth migration. DXO has not solved these problems yet when we use proprietary RAW but with DNG I think it should work since there all the changes are saved booth into the DNG “RAW”-data and the baked in JPEG that might even be in “full size and quality” and so is the XMP-metadata.
Rexblock, Wolfgang & Platypus. Thanks so much for your thoughtful responses to my dilemma. The last couple of days I’ve been knee deep in taxes. Hopefully i will finish that tomorrow and then can again properly focus on the fun stuff.
As much as I appreciate all your suggestions I am spooked about the problem of losing PL corrections when I move my file from the old PC to the new one. Thus I sent a request a few days ago to DXO expressing my concern and asking them how they recommend doing it. I sure hope they will give me an answer. Once they do I will share it here.
Rod
Please do let us know what DxO recommend for transfer to different environments. I expect that a simple database export/import across platforms will verify and that your corrections will be intact.
Please do let us know what DxO recommend for transfer to different environments. I expect that a simple database export/import across platforms will verify and that your corrections will be intact.
I sure will Rex, and will be very pleased if it’s as simple as your suggestion.
This works as expected (I do this on a ± regular basis) … unless images are moved to other directories or folders with something that is not PhotoLab, which is to be expected. After all, no inventory system can keep track of goods stolen from a shop…
Unacceptable. All changes to image processing should be in the .dop, all changes to metadata should be in a .xmp file or in the worst case in the .dop (although it would be much better and more compatible to record them in standard form in an .xmp file).
DxO so close, yet so far, from allowing file portability. At this point, I’ll just have to abandon DxO’s metadata features as the information is not portable. I don’t fancy having to redo metadata from scratch or try to extract it from jpegs three or five years from now.
The approach I’ve been using, for a long time now, is to rely only on sidecar/.dop files.
I invoke PhotoLab via a “wrapper” (see below) that starts by deleting the database, before calling the PL executable
A new database is created by PL for the current session, which is then deleted next time I start PL.
This doesn’t cause me any problems at all, because;
I only ever use PL within a “work in progress” folder, containing only new images. Once processed, the RAW file plus its associated sidecar/.dop file is moved off to my structured file-storage system.
The only information stored in the database that’s not also stored in the sidecar files are related to projects (virtual collections of images), ratings & keywords (in which I have no interest at all) and (for the Mac version) multi-session history of corrections (which is no great loss, IMO) … All image corrections are held in the sidecar/.dop files.
That’s actually not the case at all (see above). Provided you generate sidecar/.dop files and keep them with the RAW files to which they’re associated - then ALL your corrections will be safely retained.
In fact, it’s much safer working this way than expecting (hoping!) the database will never be corrupted.
That’s pretty much how I work too.
See above (top of this post).
You’re not losing any of your corrections - They’re ALL safely stored in the sidecar/.dop files.
Yes - I can confirm this too … I have never experienced loss of any correction data whatsoever.
Yes, that’s true for some non-correction type “things” (see above - at top of this post). However, my daily experience with deleting the PL database, and relying only on sidecar/.dop files, proves that absolutely none of any crucial correction details are lost in this process.
All good, Ian; You can safely continue working that way.
That’s a good point, Mr.P … OR when PL is not running; otherwise, PL can get a bit confused.
To completely avoid that potential problem, you might consider deleting the database between sessions (since, like me, you’re obviously not interested in projects, ratings, keywords and correction history).
Here’s how I do that; DeleteDxO(PL60)ImageCache&database.zip (445 Bytes) … where this zip contains a cmd file that I use as source for a cmd-to-exe compiler. Caution: Executing this will delete your database.
Which implies you’re still dependant on the database (as it now records the new location of the images). Personally, I prefer to rely only on the sidecar/.dop files - - with caveats outlined at top of this post.
Regards, John M
PS - Clarification: By “multi-session history of corrections” I’m referring to the minutiae of all the step-by-step adjustments made in achieving the final result of your corrections. This does NOT refer to the final result itself (which is always retained in the sidecar/.dop files).
The simplest and safest approach would be to copy your image-storage file structure from the old-PC to the new one. Then open those folders with PL on the new PC … and PL will build a fresh, new database.
Which implies the following assumptions;
You have sidecar/.dop files for all your images (as they will contain all corrections for their images, which PL will use to create the new database).
You don’t care about some non-correction stuff that’s not stored in sidecar files … See the top of my previous post for a list of these.
The simplest and safest approach would be to copy your image-storage file structure from the old-PC to the new one. Then open those folders with PL on the new PC … and PL will build a fresh, new database.
Which implies the following assumptions;
You have sidecar/.dop files for all your images (as they will contain all corrections for their images , which PL will use to create the new database).
You don’t care about some non-correction stuff that’s not stored in sidecar files … See the top of my previous post for a list of these.
John M
John - Thanks very much for posting all you did on this and also for sharing your cmd file. I think this should be most helpful for people like me that don’t want PL to be involved in any metadata or to use PL as a DAM.
My first thoughts:
[quote=“John-M, post:37, topic:25664”]
The only information stored in the database that’s not also stored in the sidecar files are related to projects (virtual collections of images), ratings & keywords
[/quote] Are the keywords you mention here only those applied by PL, or, could they be ones that were previously placed by a separate DAM? If it’s the latter that could be a problem for me as my keywording is very important to keep. I’m not very concerned about losing Ratings because I generally don’t apply those until the editing is done.
You and others have suggested copying my photos to the new PC with the file structure intact. Is that because of keeping the DOP files in the same folder as the original? That isn’t a problem to do, but the files will be on a hard drive with a different drive letter. I had also planned to change some of the Upper level folders names, but not the name of the folders where the photos & DOPs reside.
In using your cmd file where do I place it? In the same folder where the PL .exe resides? Then when I want to use PL I should use a shortcut to that file?
Now that PhotoLab has IPTC data, I’d very much like to use PhotoLab as one-stop finishing of headline/title, caption/description fields as well as keywords and location data.
PhotoMechanic is not yet optimised for M1 architecture (and it may still be awhile) and PhotoMechanic is more than I need for my simple titling and captioning needs. On the other hand, if DxO does not safely store metadata in sidecards (either .dop or .xmp, I’d prefer .xmp), I won’t be able to use the PhotoLab metadata features and more or less no one else who values their time and the metadata enough to enter it, should either.
Very sad. The metadata feature is surprisingly well executed. To be let down on a structural flaw like this is deeply disappointing.
