Which writing metadata to undocumented raw file formats most definitely does not.
Then maybe you’ve passed the collection on to the wrong people.
Or until that undocumented format is no longer read by the software of the day.
I understand the problem, but embedding metadata, however standardised, in undocumented file formats is still the wrong solution. If you want to ensure that your metadata survives future technology shifts and software evolution then you’re far better off sticking to standardised formats all the way. Who do you think is going to spend time on our ancient raw file formats with no documentation after we’re gone if the software of the day doesn’t handle it, which it very well may not if there are possibly multiple variants caused by different software writing in different ways over the years and no one know which is “correct”? I wouldn’t bet the farm. Even with TIFF there are occasional problems with files written by one application not being readable by another so why make it even more difficult by starting with raw file formats that have zero public documentation at all?
For longevity, I wouldn’t bank on raw files being usable at all, I’d stick with a format like TIFF. Also more reliable for rendering. Every PL upgrade so far has introduced small changes in the rendering of existing sidecars, so even if there is a PL 104, I wouldn’t bank on it rendering my PL4 sidecar identically to PL4.
Writing on the back of prints is probably better yet though.
I would expect them to read current sidecars, but I wouldn’t assume that those sidecars will be rendered identically in future versions of the PL, unfortunately. As I mentioned in my previous post, every PL upgrade so far has introduced small changes, and even if they’re small from one version to the next (eg. I had skies that were slightly more saturated in PL3 compared to the PL2 I’d edited in) and DxO does try to minimize them, it’s seemingly best effort rather than a more formal guarantee. There’s no process version like you can find in some other applications.
I am very disappointed to learn that there even is a database. One of main things (I thought) I liked about PL4 was that all of the information was in the sidecar(s)–no databases or catalogs like Lightroom & Capture One–that can become bloated and potentially corrupted.
My preference is to kill the database and put whatever is needed in sidecars where they are obvious and manageable by me (the owner).
That’s my approach/perspective too … and it’s excellent that PL allows us to work like this (a database is still maintained, but just for operational efficiency purposes).
So far, PL has always been backwards compatible, in the sense that each new version is able to read/absorb sidecar/.dop files from any previous version - but, there’s no guarantee that the results will be identical ! For example, somewhere along the way, changes were made to Smart Lighting that did not produce exactly the same results as the pre-change version.
No need to be disappointed ! - If you prefer to rely only on sidecar/.dop files (as I do too) then you can simply ignore the presence of the database … in which case, it simply provides some operational efficiency.
To work this way, you just need to ensure you have these Preference settings ON:
… … For the Win version.
In fact, I invoke PL with a self-written “wrapper” that deletes the database (and the cache) each time before it starts-up PhotoLab … where I am able to delete the cache without performance impact 'cos I’m using a work-in-progress-folder approach (I don’t expect PL to wade thru 100s or 1000s of images).
There are some implications of this approach to note: Project details, Keywords and inter-session History (when it becomes available in the Win version) are not held in the sidecar/.dop file.
That is precisely why I am disappointed. I want the full history of all my images and never wanted or expected the PL4 would maintain a database.
I have already done as you suggested, but never realized that moving a file with sidecar(s) was not moving all of the adjustments made to that image.
However I do appreciate your reply, but hope that DXO takes a long hard look at this and changes their strategy. As a long time developer, I know a database is not necessary to accomplish this, so long as users are informed about the value of those sidecar files.
If DXO insists on offering a database to hide some data from users, that should be clearly delineated and explained opt-in option, not the default.
I am not qualified on the subject of the fine points of databases vs. the rest–I just know that I do not want to be forced to use a database akin to Lightroom. I like using the folder structure on my hard drive as I periodically remove images through deletion or backup to an external drive and don’t want any function searching for removed items. Keep it simple and/or give users the option right from the start. I gave up on a software that added a database which activated on start up after install/update.
I imagine there are users who want a Lr style database–but there are others who do not, like me.
Thanks.
It certainly could be. Almost all computer programs store data the user is not intended to access. That is for the the user’s own good and some nefarious plot.
But, IMHO, the db is unnecessary and the data should be out in the light day.
This is the main reason that I’ve never used Lightroom. As soon as I found out that under normal operation, all photos had to be imported into a catalogue that had to be constantly updated in order to use the editing functions, I said no thanks.
You’re misunderstanding, Ajoe … That’s exactly what the sidecar/.dop files contain (all your adjustment details, related to its associated image file). And that’s why the database can be considered as being redundant (by those who choose to rely only on sidecars … like me).
No, there’s nothing “sneaky” about the database - - at very least, it provides some intra-session operational efficiencies.
And you don’t need to, Nikki - - You can choose to ignore it (as I and many other PL users do) … in which case, its only purpose will be to provide some intra-session operational efficiencies. More details above.
Note: There seems to be some general confusion about the PL database … it’s NOT a “bad thing” because it’s not essential for PL to work … You can happily delete it, with no repercussions (assuming you have directed PL Preferences to use sidecar files - and assuming you don’t need PL’s DAM features).
I would like to see explicit options related to database management – mainly location and backup control. In addition, it seems desirable to have a process for checking the integrity of the database.
I appreciate having the sidecar files with all of the current edit settings and wouldn’t want to lose that option.
Remove deleted items from the database
I checked the database and found copies of a file, copies that have been deleted in reality, but persist in the database. At times, the deleted objects are shown in PhotoLibrary…
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
83
Isn´t it just what “Index a folder” will do? You can do it for just one folder or every single folder under “the top folder” of your whole folder hierarchy (if you have one)
… For the Win version.
