Add an option to PhotoLab to turn the database functions on or off

[mikemyers]

I don’t want to add to the old thread about this from last year, so I am posting a simple request here in a new thread. I would like to see a “switch” in PhotoLab that allows me to use the program as a simple editor, and ignores all the current database functions.

All that I want from PhotoLab, are the original image file, and the “.dop” file, (and if more information ought to be saved, it could go into a “.xmp” file). I have no need for the database - when/if I want to get involved in DAM functions such as searches, I plan to use the PhotoMechanic tools I already have access to.

By doing this, I can easily copy image files back and forth between my various computers. Providing this “switch” would mean no changes for people who use the database, and would simplify things for users who don’t use the PhotoLab database.

(It doesn’t need to be a “switch”; it could be a setting that is turned on/off during installation.)

[platypus (Canon & Mac (Intel and M1))]

Don’t forget to vote for your request, @mikemyers.

PhotoLab uses the database for all kinds of things and is therefore needed while PhotoLab is in use. Running DPL without database would require a major rewrite of the application. I’d not like to have to pay for that and after all, we don’t tell our mechanic how to hold a wrench.

If we want to start DPL with a clean slate, we can always delete the database files before launching DPL. Other posts describe, how the DB files can be found and deleted.

I suppose that a preference/setting will do, that tells DPL to start with an empty database and archive the last “n” databases as backups.

[mikemyers]

@platypus

I suppose that a preference/setting will do, that tells DPL to start with an empty database and archive the last “n” databases as backups.

What you wrote would accomplish what I’m asking for, with minimal new code. Thanks!
That simplifies my request.

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@mikemyers I drive a PHEV and your suggestion is like me going to the manufacturer and asking for the petrol engine to be removed! In fact my particular model from 2014 can’t even be forced to use electric when it is available , i.e. my model chooses what to use and the “electric only” button only arrived with the 2017 model.

Rather than asking DxO to rip out the database engine what is needed is a set of selection switches.

While @platypus’s scheme would work it seems somewhat over kill for what needs to be achieved but would certainly help while we are testing.

However, for users who have experienced problems moving data between systems and who don’t want the database “trashed” everytime they want to move data back to a system after processing on another machine a less destructive approach would be, well less OTT!

Surely what is required is a switch (preference) that indicates whether the database or DOP is to be considered the “lead” data, i.e.

1. An option ‘Lead data’ = Database or = DOP or = ‘Ask’ (with the current “option” being ‘Database’, i.e. there is no option)

There are then a number of options that could be provided (particularly with 'Ask) or not

e.g when a DOP clash is detected present timestamp data and let the user choose (with a single or all option) which to accept as the [M]aster. This could be implemented with or without the above option but would fit well with ‘Ask’!

So when a DOP clash is detected retain the entry in the database or make the DOP the [M]aster as indicated by the preference or by the above (‘Ask’) dialogue and then either

1. Discard the other entry

OR

2. Make the other entry a VC

or any permutation that is deemed appropriate for a larger audience of users who might want to move data between systems but not discard all the other data in the database, which is effectively throwing everything away for the sake of importing some potentially duplicate data!?

In the meantime consider using the procedure at Avoiding "Unwanted Virtual Copies" when copying Images and DOPs between systems until something better arrives.

[MikeR]

@mikemyers

By doing this, I can easily copy image files back and forth between my various computers

You basically already can. Just make sure these two checkboxes are checked.

Also there are a few caveats… Like some metadata like ratings and IPTC data that’s stored in the .dop file isn’t parsed when corrections are loaded from a sidecar, and if you’re on a Mac edit history is only stored in the database. (On windows it’s not stored at all.) There are probably a few other details not properly stored in .dop sidecars. (keywords?) I consider these “bugs”, and hope they could be resolved.

Aside from these caveats, you can more or less ignore the fact that DXO maintains a database.

[mikemyers]

@MikeR

You basically already can. Just make sure these two checkboxes are checked.

Where are those checkboxes located?

I did find this:

@BHAYT

I drive a PHEV and your suggestion is like me going to the manufacturer and asking for the petrol engine to be removed!

I think of my suggestion as being like how to turn off the air conditioning.

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@mikemyers

@BHAYT

I drive a PHEV and your suggestion is like me going to the manufacturer and asking for the petrol engine to be removed!

I think of my suggestion as being like how to turn off the air conditioning.

To use your analogy it would not be turning the air-con off but rather removing it entirely from the car!

Your proposal is effectively completely removing the engine of the product! The DOP is the “sidecar” to the databases “motorbike”. The motorbike can exist and be driven without the sidecar but the sidebar on its own is only any good as a chicken coop except that DxPL allows you to re-attach it to another motorbike but with certain conditions/outcomes.

If you haven’t got those two options in Preferences set then you won’t be getting any DOPs nor any issues when they are moved to another system because they either won’t exist or won’t be imported!

[mwsilvers (Mark - New Jersey, USA)]

@mikemyers

@MikeR

You basically already can. Just make sure these two checkboxes are checked.

Where are those checkboxes located?

I did find this:

Those check boxes are available in the Preferences settings. After all this time since you joined this forum, and after posing hundreds of questions, I think you should consider spending more time independently investigating the options and features of PhotoLab.

Many posters here are very generous with their time. Most of the people who answer your questions are able to do so because they have already spent a significant amount of time on their own figuring out how PhotoLab works. It is certainly acceptable to ask questions about things that you don’t know about or understand, but at a certain point, I think you need to put a little more skin in the game and not depend on everyone else to teach you how to use this product.

Mark

[MikeR]

@mikemyers

Where are those checkboxes located?

On windows, in the preferences dialog box:

[mikemyers]

@BHAYT

Your proposal is effectively completely removing the engine of the product!

Then I worded it incorrectly. From now on, consider my proposal as just a way to tell the database to not do anything, perhaps as suggested up above.

@mwsilvers

I think you should consider spending more time independently investigating the options and features of PhotoLab.

Great idea, but to me, PhotoLab is just a tool, an editor, just like a wrench is a tool to a mechanic. Yes, I’d like to understand it better, but I struggle with learning it, and the bottom line is I mostly want it to do basic edits to my photos.

@mwsilvers

I think you need to put a little more skin in the game and not depend on everyone else to teach you how to use this product.

Valid point, except that I seem to be too busy doing other things that eat up my time.

I don’t want to learn how to use the database for keywords - all I want to do is the basic edits to my photos, that people here have helped me with tremendously.

I own PhotoMechanic, which has two parts, the “image transfer” part, and the “DAM” part. One of these years I’ll learn about the DAM; for now, I ignore it. Similarly, I want PhotoLab to edit my photos, and ignore the database stuff. Re-setting PL5 each time sounds like a great idea to me, if I can’t turn it off.

I’m sure others feel very differently.

I don’t have to know how all the components work in my car, to use my car to get me places. (I like to learn anyway, but it’s not necessary). Ditto for my video system. Set it up once, and forget it. Ditto for my bullseye guns I train with. I don’t need to learn all the components, in order to hit the bullseye. Yes, it’s worth while to learn them, and I try, but when I get to a bullseye match, I just need to know what to do, and how to do it well.

My memory sucks, and while I used to know Windows quite well, I’m lucky I can still spell it. I guess I’m spoiled, because Mac made so many things so easy…

[mwsilvers (Mark - New Jersey, USA)]

@mikemyers

Valid point, except that I seem to be too busy doing other things that eat up my time.

Yet you somehow found the time to create over two thousand posts and have no problem eating up other people’s time when they try to assist you.

Mark

[MikeR]

@mikemyers

Valid point, except that I seem to be too busy doing other things that eat up my time.

It’s about priorities…

And perhaps a bit of thought and even the slightest bit of self investigation. These kinds of settings are only accessed in one place. You would have found them faster than typing the message if you simply tried to look.

I think that’s Mark’s point.

And you don’t need to know how an internal combustion engine works, or how am electric motor turns electricity into motion. But you do know how the turn signals work, how the gear shifter works, headlights, wipers, air conditioning, etc. perhaps you even paired your cell phone with your car or programmed your favorite stations into the radio. Perusing the Photolab preferences is a good thing to spend, like, 2 minutes on. There aren’t that many.

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@mikemyers If you use Photo Mechanic then I believe there is no database but if you are using Photo Mechanic Plus, Capture one, Lightroom, Zoner, ExifPro, IMatch, ACDSee, Photo Supreme and PhotoLabs then there is an SQL database lurking underneath the product, except for ACDSee which appears to be a derivative of DBase!

Photo Mechanic, FastRawViewer, @Joanna’s product and Adobe Bridge read the data direct from the image.

Do you need to know how PhotoLab’s database works and the answer is NO, can you remove the database or make DxPL ignore it’s existence and the answer is also almost certainly NO! Does that matter and the answer is also, most of the time, NO!

Except for the one time that you decide to carry an image from one DxPL system to another, make edits and try to bring the file and its new DOP back to the first system, with the same name and still in the same directory. If that DOP is indeed shiny and new then there is a problem because the original system decides that it does not match the entry in that systems database and it will only “attach” the new sidecar as a nice new shiny Virtual Copy!!

This issue has been the topic of countless posts in a number of forum topics and still it seems to crop up. Would removing the database or not using the database prevent this problem and the answer is yes, except that nothing else would work because the database is the central storage entity of the product.

So there are two courses of action to avoid the problem, i.e.

1. Delete the database avoids the check failing but also destroys all the data in the database which for some doesn’t matter but for others would matter a lot!

2. Use a procedure like the one that I have written down that avoids encountering the problem which is so straightforward that I feel that it is a minor inconvenience to use it (except in the case of huge directories, perhaps).

Is it annoying, for a number of users very annoying but it can be avoided.

Is there a fix, well the solution I proposed earlier in this topic is not very complex to develop, essentially it just “flips” the process so the incoming DOP is taken as the [M]aster instead of a Virtual Copy and the existing database entry becomes a VC or is abandoned.

It would work and would leave the database intact, I would call that a win, win situation BUT I cannot write it, I cannot force/persuade DxO to write it and it appears that no matter how much I have written about this topic and presented a detour, the database is once again “the culprit” and I wonder if anyone has actually read any of my long posts!?

So for the last time here is the procedure to use that avoids Virtual copies and allows data to be carried from one system to another and back again and across again and… as many times as needed.

Copying from A to B where the directory and file names are on both systems and in both DxPL databases.

1. On destination system B change the name of the target directory with DxPL, e.g. to “-Original” or “-OLD”.
2. Copy the original directory from the sending system, A, (via a LAN using mapped drives, in my case) or via a USB stick or drive retaining its name (the original name) onto System B.
3. Navigate to the newly copied directory on the target system, B, and re-discover the original named directory
4. The renamed original directory can be deleted once the new copy has been checked!

To check it out I did the copy in the opposite direction taking a directory “Test - 02” back from B to A via a USB3 stick

1. Copied the original directory to the stick using File Explorer, dismount USB3 drive from B and unplug.
2. On A, open PL5 and navigate to “Test - 02” and change the name using PL5 to (e.g.) “Test - 02 - Original” or “Test - 02 - OLD” etc.
3. Plug in USB 3 drive and copy “Test - 02” from USB3 stick and paste to the correct location on the mirror disk structure on A using File Explorer
4. Navigate to “Test - 02” with PL5 (which was open all the time) all good and no Virtual Copies
5. Delete the old directory as and when appropriate.

The overhead is the additional swing space needed for a “duplicate” copy of the directory on the target system.

Apart from the directory name change and subsequent deletion (which would also have happened if the copy had been over the target directory) this is identical to a normal copy except that no Virtual Copies will be created!

[mikemyers]

@BHAYT

but if you are using Photo Mechanic Plus,

Yes, I upgraded to “Photo Mechanic Plus”, with the eventual idea of using it for a DAM some time in the future.

@BHAYT

Except for the one time that you decide to carry an image from one DxPL system to another,

When I travel, I take my laptop, and when I return, the files eventually get copied to my main computer with two large displays, which I have been doing for decades.

@BHAYT

except in the case of huge directories, perhaps

My Mac’s “Photos” folder contains all of the photos I’ve taken since I started with my old Windows computers decades ago. I use PhotoLab on any of these photos as needed, so I guess the database is huge. (I usually delete the photos on my MacBook once they are on my main computer.)

@BHAYT

Copy the original directory from the sending system, A (MacBook), (via a … drive retaining its name (the original name) onto System B (Desktop Mac).

Both MacBook and desktop have PhotoLab, including edited photos. PhotoLab on the desktop seems to open the photos properly. (But after all this reading, I suspect the database is confused). Long ago, I did this back when I was using Lightroom.

(As I recall, I used the tool in Lightroom to write all the data to files on my disk, rather than having it only in the Lightroom database. I’ve assumed that the .dop files contain all that data, and my newer Mac Mini works as expected with the images that came from my MacBook Pro.

@MikeR

And perhaps a bit of thought and even the slightest bit of self investigation. These kinds of settings are only accessed in one place. You would have found them faster than typing the message if you simply tried to look.

This discussion wouldn’t be going on, had I not been trying to convert images to a Windows-friendly environment. As far as I know, two weeks ago all was fine. Then we started talking about the “pipe” character and Windows.

To my way of thinking, this discussion seems like my owning a car with an accessory that is causing my problems, and which I neither need or want. One answer for that might be to disconnect the power to this accessory, such that it doesn’t do anything. In my mind, this is like the PL5 database. I’ve been told I can reset that database any time I want without causing problems. Since I can’t disable the database, based on what I’ve read here, maybe my answer would be to reset the database every time I run Photolab.

Regarding the original discussion here, I send my finished images to lots of people, some with Mac, and others with Windows, and none of them have had problems viewing my images. From what I learned here, my friends with Windows can open the photos with no problem, as that “pipe character” is ignored. This has been going on for a very long time now.

I plan to allow @Joanna to view my MacBook Pro, and watch what I am doing to remove the pipe character, and it’s probably some stupid thing that I am doing wrong, but who knows. That should solve the pipe problem.

As to the database, I eventually will be using PhotoMechanic Plus for the DAM feature, which I have not yet even looked at. I’m not aware of any reason why I can’t eliminate the PhotoLab database, and since it’s apparently impossible to turn it off, but it is easy to reset, I see the database reset as a valid option for as long as I continue to use multiple computers.

[Stenis (Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))]

@mikemyers I think there is an even more simple solution and it is just ignoring there is a database, because you don’t really need it.

I don’t have any real problems today using Photo Mechanic together with Photolab. Just do all the metadata job in PM and the editing in Photolab. Never ever update any metadata in Photolab.

I have a long time suggested a switch that determins if PL or an external metadata editor shall own the metadata. The key is really to help us inaktivate the metadata interface in Photolab if we use an external metadata editor in order to avoid unessessary confusion. Just turning of the database will not be sufficient to avoid the confusion.

…also the problem with the rating occurs mainly because it’s not IPTC but EXIF.

[MikeR]

@Stenis

I think there is an even more simple solution and it is just ignoring there is a database, because you don’t really need it.

I agree. Just ignore the fact that there is a database… Problem solved.
I do wish the caveats I mentioned above would be fixed for those of us that want to manage filestructure outside DXO and don’t use other tools for ratings and IPTC. These omissions should be fixed.

[platypus (Canon & Mac (Intel and M1))]

@Stenis

The key is really to help us inaktivate the metadata interface in Photolab if we use an external metadata editor in order to avoid unessessary confusion.

On Mac:

• uncheck the box in the green circle to keep DPL from overwriting XMP
  (you can still do it manually if you want - use the respective command(s) from the file menu)
• check the boxes in the magenta frame according to your needs

[John-M (Melbourne, Australia - Win10)]

@mikemyers

@platypus

I suppose that a preference/setting will do, that tells DPL to start with an empty database and archive the last “n” databases as backups.

What you wrote would accomplish what I’m asking for, with minimal new code. Thanks!

In which case, why not simply do this for yourself (?)

I assume that Mac has a similar feature to Win10’s Batch/Command function (whereby you can execute a series of command-line instructions to carry out any operating-system-level function) … I do just that, to first delete PL’s database (and cache & thumbnails) before invoking PLvX itself.

It’s a simple (and effective) solution to your requirement.

@Stenis

I think there is an even more simple solution and it is just ignoring there is a database, because you don’t really need it.

That wouldn’t work for me - as I regularly move images (plus their related sidecar/.dop files, of course) between folders, and rename image+sidecar pairs (from outside PL), “willy-nilly” … and that would cause all sorts of problems (and inefficiencies) if I did not delete the database before each new PL session.

John M

[Stenis (Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))]

@platypus What I mean is to inactivate the metadata interface and block the possibiliti to enter data into the metadata elements/fields. They should not be open if we prefer using external editors that own the metadata.

[Stenis (Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))]

@John-M Photo Mechanic manages to move Raw+XMP+DOP without loosing any of the files in a set. When you move files it’s easy to reindex the folders you have updated. I don’t think that is a problem if you know what you are doing and I don’t think I can blame the system whråen I myself violates it. Because I think it is a violation breakibg the rule of data ownership.