I admit I do not fully understand exactly what the cache / database holds, or what it’s function is, so my comments below may or may not be relevant (apologies if not).
My personal workflow and preference is that I do not use Projects, Key Words or History, and I have no interest in having a digital catalogue or DAM in my RAW editor or any other photo editing tools. I store my files by year, quarter, date and folder subject name, and would rather DXO concentrated their efforts on improvements and innovations to the RAW development and editing process.
I very much like sidecar DOP files and keep them with my photos (even if I rename or move folders), and I hope DXO maintains compatibility and the ability to read the sidecars over many years (e.g. in 5 or 10 year’s time if I decide to go back to one of my photos for a re-edit, then the original edit with all the settings appears on screen for me to adjust according to taste).
My concern is that any changes do not have a negative or destructive impact on the many thousands of DOP files contained within hundreds of folders, I’m happy with the system taking a bit of time rebuilding the file cache periodically, and possibly deleting cache data if it’s over 12 months old (which would then need to be rebuilt when I next access that folder in the future).
I would not like any RAW developer or editing program to change the original RAW file in any way, indeed, if I knew this was happening, I would probably make the RAWs read only. The RAWs are my original archive files, I do not want them changed in any way.
The first feature missing on the Mac Version, is the ability to move the datebase.
The second feature, very important, is an automatic backup of the database. Advanced users need preferences ti adjust it with precision and other users need a backup completly invisible.
The database being a central element of the software, it must be considered that it is impossible to delete it and its integrity must be ensured in all circumstances. So, we need integrity check and optimizing functions.
Antother thought about images data. The most important thing with images is metadata. If I loose the development work, can can redo it (it’s very easy and fast with a software like PhotoLab). But, if I loose matadata, it is more problemaic. In twenty years, how can I remerber the pitcure taken circumstances ? In this case, saving metadata in sidecar files is not a good idea as it is impossible to keep the image file and its sidecar together FOREVER. Saving metadata directly in the original file would probably be a better idea.
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.
… For the Win version.