of course it depends on the software, but you can search and then select them to work in DxO PL … PL will open only those files to work with … for example in FRV ( I am NOT suggesting to use FRV for that purpose as it is not a proper DAM ) if you select several raw files and open them in DxO PL you will see only those raw files in DxO PL because FRV pass the list of files selected to PL as parameter in command line
granted your DAM might be too DUMB to operate with a 3rd party raw converter like DxO PL in a proper manner, but then why to use such dumb software ? find a proper one
of course once you step outside of the native raw converter functionality you don’t have certain things but why do you need to view a DxO processed image while tagging ? you can see what is in the image and nuances like that it has variants for BW, Color,etc you can just switch back from DxO to DAM app window and tag it over there …
I am looking through multiple folders to find images that I might include in gallery exhibit. Hopping back and forth through two apps trying to match images while I am scanning through multiple folders is not my idea of fun. And, yes, I need to view the processed images.
And sometimes I create a B&W virtual copy and tag only it.
In Bridge, thus i think also in LR, you can mark parents as visible and as hidden.
So
When i click on [birds] which has [animals] as parentkeyword, both are V-ed but only “birds” is visual beneath the photo in the information.
But i can set this hierarchical tree as full visible. (which i don’t have set by the way.)
Yes, i am have often keywords like person this and that and scene kind tag and a event kind tag. So that’s already a lot of visual keywords by each photo. Thus visualise the hole string of each would be a crowded infoblock.
But it could be usefull for homing in a image to start high in the treebranches of multiple parentkeywords and from there fine tune the selection.
Bride can do this as i wrote elseware.
In fact you can create many selections which are stored inside the dxoDB as projects. (named as “externals” ) and i didn’t try it yet but i assume you can then change the external name to anything you like.
I have often bridge and dxopl open at the same time. Aslong as you don’t create a conflict by adding info at both side’s before data sync of both your fine.
Keep keywordmanagment outside dxopl and only add things in iptc fields in dxopl. And i think youre fine.
Only “Bienenfresser” is assign as keyword to photo, but it’s part of hierarchy.
Why only one part here and other part outside? A little carelessness and the whole job is destroyed.
If someone really wants to have order, then do everything outside of DxO PL and only do the image processing in DxO PL
these are test files so i don’t care but for my exported archieve:
i have to clean up this keyword propertie mis writing…
easy by search for “type”, then “select all” then un check “type” done.
( best by some restriction in foldertree to have not too much images in one go.)
That’s why i manage in bridge and only add geotagging in DxO because there i can copy past Googlemaps coordinats and in bridge it doesn’t work. ( wrong type)
rest of iptc fields i manage in Bridge.
I say that because it simply doesn’t work for anything other than single condition predicates or compound predicates that have been ANDed. Try looking for " this OR that" and you will find it is impossible.
What I do is do a metadata search in my software (or any other) - select all the resulting files and then “Open with…” PhotoLab.
Warning
Up to PL5, you did not need to create a project - one would be created automatically, named after one of the folders that contains some of your files.
This has now been changed for PL6 and PL7.
You now need to create an empty project, which you can name appropriately and select, before sending the files from your DAM software.
I can now select which virtual copies I want to keep and delete those I don’t. Deleting from a project does not delete either original files or virtual copies.
Once you have refined your selection, then just do a bulk export of all those that remain.
now i notised some hicups in my keyword structure i have a quick repair:
advanged search in bridge : in each main folder (second after "foto’s)
if they show up select all and turn of [Type] ,all of them are jpegs so made by dxopl.
have to check if dxo plv7.2 now has better understanding of this “drawer label” stuff
My point is that this requirement for ORing is one you have and I don’t. Therefore, a blanket statement that no one use PL for searches is one I don’t agree with. If the ability to OR terms is necessary, then by all means, avoid PL keywords.
If I wanted to find birds by species and color I would use this hierarchy:
Birds > Species > …
Birds > Color > …
I don’t have a need to find, say, all Thrushes AND all red birds.
Interesting. Until yesterday, I didn’t know that PL could open files from the command line and I’ve never created any projects that I know about. I picked images in different folders to see what would happen and all three images showed up in PL. I’ve looked in the database and the Projects table is empty.
Of course, I wasn’t trying to create a project. What I saw looked more like the results of a search. Since I haven’t found the command line documentation, perhaps you were using some option that creates a project from a set of images.
The workflow you are pushing is not one I want to use. Here’s what I would be doing:
Open PL to view a folder.
Note that I have at least one image I want to keyword tag.
Open some other tool to view the same folder. The images would be shown in their unprocessed form.
Go back to PL to find the first image I want to tag.
Go to the other tool to find the image. Like you, I might have several images that look very similar in their unprocessed form, so I’m going to have to be careful to match by filename. Many bird photos are shot in dark environments, which makes the unprocessed images even harder to match visually.
Tag the image in the external tool.
Repeat for the next image.
Repeat for the next folder.
Most external tools don’t know about virtual copies. Perhaps yours does? I have a number of virtual copies whose keywords differ from the source file.
… and that you want to find all images of more than one type of Thrush (e.g. Red-throated Thrush, Black-throated Thrush)?
How do you specify a search for images that contain both or either of those varieties?
With DxO’s current limited search, you could only specify images that contain both, but never images that contain one or the other.
You don’t have to try to create projects. Just firing off an “Open with…” PL7 from your DAM or Finder is sufficient for PL to automatically create one or more, containing the imported images.
For example, I can also search for files using Finder’s Spotlight search…
Wel, indeed virtual copy’s are DB/dopfile only and thus exclusive dxopl ecosystem.
If you use those as variations which you won’t export then you don’t have a rgbfile with the properties (jpeg/tiff) but when you use VC’s to create multiple export of the same rawfile you find those and those point towards the rawfile and command open with dxo will direct you to the VC’s.
So i don’t see a closed in functionality. Unless you use VC’s as non exported image vararities storage which i can’t think of why?
Just to be clear: I am not saying that some people might find the lack of an OR option restricting. I am saying that it’s not a problem for me.
Given your example, I normally would only be interested in a specific thrush or all thrushes. In the last 6 years, I haven’t had any cases where that’s come up. I get that you find this restrictive enough to write your own tool to work around the problem. For me, it’s not an issue.
Good to know. I was just putting files on the command line. As far as I can tell, this does not put them in a project.
Well, I don’t agree that I am “well and truly stuffed”, but yes, my goal is to work in the PL environment for now. I do want to preserve as much as I can should I switch tools, but if I were to switch tools, I would lose a lot more important stuff than keywords from virtual images (e.g. all the image adjustments).
Your path was to create your own tool to work around PL’s limitation. My path is to create a tool to fix database/DOP/XMP/RGB file keyword inconsistencies, which is the problem I am most concerned about. If it works, my keywords should be usable by any external software–except for the virtual images, of course.
Actually, I started writing my app long before DxO started the beta test for PL5 and it was this that allowed me to contribute so much to the discussion on compatibility and cross-DAM working.
Now that’s what I call hard work and, as I mentioned, totally unnecessary.
Your main problem is that absolutely nothing other than PL can read or interact with DOP files or the database.
I have tried to parse DOP files but, as yet, have not completely succeeded as they are not in an expected format like JSON. The nearest I can get is that it might be an implementation of LUA, but finding an API that will integrate with tha macOS frameworks.
I was testing a feature. If I wanted to do this from, say, a PHP script or some other software program, I could use the PL command line to open images in PL. You can’t exactly select a set of files in Explorer and click “Open with…” from a script.
The point is not how I did it, but that you posted this warning:
I have no idea for what cases your warning might be correct, but it isn’t correct when images are opened through the command line—no project appears to be necessary. There may be other ways for DAM software to signal to PL that it should open various images. Some of those ways may require that an empty project exist.
This is not my main problem. My main problem is that PL doesn’t keep the database in synch with what it writes to the DOP/XMP/RGB files.
It is not even true that “absolutely nothing other than PL can read or interact with DOP files or the database.” I’ve currently interacted with the database using a tool called DB Browser and written an SQL query to get access to all of the filename/keyword info. I am now working on tools to interact with the DOP/XMP/RGB files so as to enforce keyword consistency.
For my purposes , it is not necessary to parse the entire DOP file, just the keyword parts (there is one set per item, and there can be multiple items in a DOP).
… and it is a bliss
