I think this is correct. The only thing missing from sidecars that would allow full recreation of the database info is the advanced history for that image and that image’s project membership.
If these two elements are added to the sidecar then the database truly becomes a cache used to manage previews and search capability and fast display of metadata.
This also solves the whole database dependence on the serial number of the hard drive.
Good idea. Unfortunately I’m not that clever… don’t know how to do that on a Mac. Ideally DxO will consider giving us that option.
Absolutely, no database mode should be built into PhotoLab and not depend on a hack. There should be no option to develop features in PhotoLab to require a continual database.
DxO went seriously off the track when they started to talk about library features and metadata management. The results are better than many of us predicted but still mediocre at best. While DxO have been dithering with image processing improvements, the competition have caught up with both super resolution and high quality noise reduction.
PhotoLab is used (when it is used) by professionals for its image processing prowess and high ISO ability. We don’t want to use PhotoLab to manage our images. We want to process our images with PhotoLab.
Improving colour processing would have been a much better use of DxO programming time than fuddering about with the library.
@Bavago I don’t share your concerns about the database and believe that attempting to remove the use of a database from PhotoLab @uncoy would make the development man hours used for keywording as nothing by comparison.
The current issues over ‘Projects’ being lost when the database is “lost” is an unforgivable omission of appropriate facilities in PhotoLab, whether it is resolved by using the DOP, e.g. the redundant ‘Album’ entry in the DOP and/or a utility to dump and restore the ‘Project’ data that capability should have been in place before the ‘Projects’ facility was released @Musashi.
The issue of Drive identity changing and rendering database entries and, thereby, ‘Project’ entries redundant could be fixed with very little effect from DxO @Musashi.
Instead of automatically detecting and taking the current course of action (executing a new re-discovery) the user should be provided with an option to instruct DxPL to accept the new id as a “replacement” for an existing drive. Currently using back-up recovery drives is a non starter with DxPL, i.e. a database full of detritus and useless ‘Projects’ is currently inevitable.
Similarly the ‘Unwanted Virtual Copy’ entries could also be resolved with some simple coding to stop when such a situation is detected and request user assistance. This could then provide options to add the DOP as a VC (the current action), add the DOP as the [M]aster retaining the current data as a VC (slightly more complicated if the image has VCs already) or replace the current image ([M]aster or [.] VC database entry with the “new” DOP Data.
This feature could be controlled by a Global ‘Preference’ option to allow users to continue with the current VC creation option without interruption, if so desired or be provided with this new option, either way this feature has been long needed @Musashi.
My current strategy when testing is to backup the database, if considered appropriate and then instruct DxPL to load a blank database! Using that strategy means that @platypus could continue with the completion of batch of editing before simply loading an empty database.
Here is an empty PL6.7.0 database for Windows users. The databases are not compatible between Windows and Macs so a Mac user needs to undertake the same work to create an appropriate completely empty database
PL 6.7.0 - Blank DB for Testing.db (71 KB).
The advantage is simplicity and the disadvantage over @John-M,s “wrapper” is that it leaves the cache and thumbnails etc. intact.
The only thing that I believe is actually practical is to add a close/Exit option.
This could be like other software suggesting that the user might/could/should backup the database but could add an option to “discard” the database, at which point the software could choose to take a copy before re-initializing the database for the next session.
But please add the time to the Backup feature @Musashi
I have more patience for your posts than most Bryan, but there’s no simple solution which you cannot meet with exponential complexity.
Maintaining an option to run PhotoLab in .dop mode only would not be particularly difficult at all: load data when a folder is selected. End of story.
@uncoy I apologise because I thought you had an intense dislike of having a database at all rather than simply using the database as temporary storage for the duration of a “session” and then starting afresh each time. I personally don’t like it working that way because I would like to be in control of when I consider a “session” has ended and the “life” of the database with it!
The post was long to highlight the issues I believe exist with a database that is expected to be used from “session” to “session”, i.e. if the issues I stated are fixed then most of the problems that have been encountered by users over the years would “vanish” or be controlled and the need for most to abandon the database would “vanish” as well.
The solutions I proposed are not an exponential increase in complexity at all.
The use of a blank database is simplicity itself and one I use before starting most tests!
The exit options are simplicity itself to implement, albeit I would add one more “Exit, Backup and Discard” to cover all bases in one option. I prefer them to your proposed option simply because it allows the user to determine the “end of life” of the database, rather than losing it after every shut down.
Removing the database whenever one feels like it (and with DPL not running) is easy…nevertheless, an option to zap the DB could be added next to the “delete cache” button in DPL’s settings. We’d then have a) easy access and b) the possibility to delete the DB at any desirable moment, e.g. at the end of what we choose to be a session.
More complexity, Bryan. Simplicity is a mode without a database. Potentially with folder-based loading of some data into RAM as you point out to improve loading speed. Even opening a new folder would start a new session.
Closing and reopening PhotoLab creates a new session. A PhotoLab crash also results in a fresh start (all data should be in .dop files).
Those who want a database can live with the consequences of a database and deal with its manual deletion. I want a PhotoLab mode with no database at all. Everything in .dop and .xmp files (.dop for developm,ent info, .xmp for metadata).
@uncoy way to extreme for me Alec and I fear you are the “zealot” that I suspected.
So I will stick with using ‘Backup’ to secure my personal database and ‘Restore’ my empty database when I feel I need to run a test and then ‘Restore’ my personal database as and when necessary.
I like what PhotoLab offers I just wish that they had finished certain elements properly.
I have no wish to use Lightroom or Photo Mechanics, I will stick with PhotoLab plus FastStone Image Viewer, XnViewMP, FastRawViewer and learn to use IMatch (or not) and try to use Affinity 2 (or not).
I think this is an academic exercise really, for those of us intimately familiar with the workings of PL but come on, really? Do you think for one minute DxO would provide an easy way to nuke the database? Can you imagine the flood of average users who would get themselves into serious trouble? It’s an edge case not relevant to the vast majority and it’ll never find its way into any kind of menu that can be reached without serious nous.
DxO have hitched their wagon to a photo library approach, rightly or wrongly, and that needs a database.
If I’m wrong I’ll eat my SQL browser.
SELECT * from [dbo]Chances where given = “0”
It’s not zealotry. It’s power through simplicity. There’s no software which won’t be slowly ruined by the approach you advocate. It’s throwing more and more code and more and more complicated routines, which sooner or later fail. Reliability is power.
There’s two useful approaches:
There’s no reason that DxO cannot offer two modes: mode 1 for those who want a a RAW developer and mode 2 for those who like to argue on forums about what broke their database and why their metadata is corrupted.
Based on your entire history of exponentially complicating any technology with which you come in contact, you are clearly a candidate for mode 2. You will relish those painstaking forensic conversations about why you’ve lost half your metadata and a third of your corrections.
Ah well, there is grey between black and white! Why not do both?
BTW, how’s Photo Mechanic’s database doing? No divergences yet?
PhotoMechanic does what it promises, all the time reliably.
PhotoMechanic is very complex and painful to learn and manage but as it keeps in its lane, it works. If DxO wants to be successful at managing photos, it’s a whole new application, even more independent than FilmPack. The photo library is a separate part of Lightroom and probably the least successful. Never ending issues and slowdowns and corruption issues over the years. There’s a huge team just working on the Lightroom database and they are more or less failing.
Never had any issue with Lr’s Library module and database. I’ve read that other people have had issues, maybe I was just lucky. But Lr has a few things that keep the database sane and aligned with what is on the drive. It checks consistency and creates a compressed backup. I’ve restored from backups…all went as expected…and I’ve been using Lr since 2007 too.
Nevertheless, adding at least one option to delete the database could make many of DPL’s users happy. I don’t understand why DxO is so reluctant to add such a function, specially in view of the standard support replies I got with early OpticsPro versions: “Delete the database…”
If you didn’t have issues with the Lightroom library you probably had smaller libraries and/or more reasonable demands and/or you were not that fussy about performance. The issues happen when photographers add 100,000 50 MB RAW images and expect the same performance as when they had 6000 12 MB RAW images catalogued.
The issue is not an option to delete the database. The issue is an option to run PhotoLab without the database. Add and delete, add and delete is complicated. PhotoLab does not need the database and should not impose it on end users. Many PhotoLab users, perhaps even a majority, want all data stored in .dop and .xmp files.
I take that as your opinion. As from its start DPL (and OP before) was designed to run with a database and I’d rather have decent database housekeeping in DPL than a new version that works without DB - hopefully works because this change would, imo, take considerable effort to implement. Anyways, the DB is just a means to an end, but it has to be maintained or it is not more than a quirky cache.
As for expectations…they are probably one of the main reasons for disaster, but that is an other topic, and I’ll not cover it in this forum.
You want your database, keep your database. Those of us who don’t want the database pay with our money for PhotoLab and there’s no reason for us not to ask for what we want until we get it.
There’s absolutely no reason that PhotoLab can’t run without a database. There are users here who manually delete the database on every blasted open of PhotoLab. It works fine, better than running with a database. That, my good man, is not an opinion but grim reality.
Why should we have to do handstands to run PhotoLab without a database?
Alec,
I completely agree with that sentiment. I have always been a proponent of “If you don’t ask, you don’t get”. However, I suspect DXO will never give users a choice about the database regardless of how often members of this forum ask for it.
Mark
@uncoy How do you know what my “entire” history is, what arrogance? My history on this forum has been to try to help users who encounter problems and the resolution to some of those issues is to request DxO to make changes, i.e. add options to replace their current automatic actions!
My history in the IT industry you have no specific knowledge about at all!
Sadly, the chance of DxO doing anything about that and this
are extremely unlikely, if it is not on the DxO marketing plan it is not coming in!
As @platypus has stated the database has been part of the product since OP4. I have been using it since OP8 and still have databases from 8 and 9 on the system and they differ from OP11 so there was a change in DB architecture along the way.
My DxPL involvement has not been one of seeking to increase the complexity of DxPL incrementally let alone “exponentially” but rather to try to help when users trip over the “cracks” left by the DxO development.
Impossible and that was what I tried to intimate in my “polite” response, the one before the “zealot” one! DxO updates the database always and the DOP optionally not the other way around and the coding to change that would be astronomic.
Because it would be a colossal waste of resource to remove it! That doesn’t change your right to ask but I for one want all the bells and whistles but implemented so they work properly!
@mwsilvers Agreed, ask away but it isn’t even on my list of changes I would like to see, but making it easier to destroy the database makes sense.
I would move my commands from the ‘Exit’ list to the ‘DXO PhotoLab database’ menu. Your option @uncoy has disadvantages, I believe, but one major advantage, if set in ‘Preferences’ then DxPL could warn that the DOP write option at least should be set, although without any database continuity the read option should also be set.
Could I offer you some French cheese and crackers with your post?
Otherwise, I’ve made my case for simplicity and a simple binary option: work with database enabled between opens, or work without database enabled between sessions. With that simple choice, those who would prefer to occasionally blow up their database could just go and do it manually as those who prefer to work without a database have to do it on every open and close.
The binary option would allow DxO developers to optimise performance for both plausible scenarios: working with continuous database and working without continuous database. There aren’t many options important for them to toggle but there are no doubt a couple which it would be useful to build in.
