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

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

5 Likes

On windows, in the preferences dialog box:

2 Likes

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.

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.

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…

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

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.

@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!

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

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.

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.)

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.

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.

@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.

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.

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

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.

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

@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.

@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.

@MikeR Would you like a Ratings to be included in the IPTC? I don’t think that will ever happen when it hasn’t in decades. The problem is I guess that different software handles the problems differently. Some “forks” the Ratings-data one or two ways and others not. That is a mess deceloped for decades.

No. The rating is already stored as metadata in the DOP file. Not in the IPTC section but elsewhere. But this rating is ignored when PL discovers a raw file in a new location with a sidecar present.

It’s stored in EXIF by most programs. Is it really stored in .dop too? That’s unessessary redundance if that is true and also a non standard proprietary solution.

DXO never modifies the raw file…

So if you rate in DXO your rating cannot be stored in the raw file.

1 Like

well, look at it like this: The .dop file is kind of a(n almost synchronous) backup for what’s in the database, which is also the basis for what is writtten to XMP. If you loose the database, the .dop files can save your bacon…but DxO will have to do a thing or two until we’re there.

As for non-standard/prorietary: The .dop sidecars are DxO’s - and they can put into them whatever they like. .dop sidecars are not meant to exchange information - except between DxO products.

2 Likes

So v5.3 is out and seems to directly address this deficiency. Need to check this out.

… and that is a problem too because some write and read EXIF to and from the RAW or to and from the EXIF namespace of the XMP-files.

DXO have to make up their mind about their XMP-support.