Is there any way to use the search function to find all images with a particular tag (picked/rejected/untagged)?
Specifically, what I want to do is periodically check that I have deleted all rejected images, with the search over all projects.
I can kind of do this at the moment by using a script to identify rejected images, but it is a pain when wanting to review what is marked for deletion (in case of any stupidities, eg hitting ‘x’ with several images selected by mistake).
@Mark2 As far as I can see not in DxPL, at least not all, but it is possible to show them on a directory by directory basis via the ‘Filter’ as follows
Yes, the filter works. But if you want to check that you have deleted all rejected images you need to rather tediously go through every sub-directory one by one!
@Mark2 I did say that in my post, i.e. it is only a partial solution.
The DxPL interface is directory driven and you are looking for a solution to your specific issue that is “global”, i.e. spans directories, which is quite a lot of work for a niche (but potentially useful) feature.
The Flag is in the DOP and in the database so
Put up a Votable post and see what support it gets from other users and then wait to see if DxO decide to provide the capability.
Or create a workflow that ensures you can find the “rogue” images directory by directory.
Or write your own program to go through the database (or DOPs) and find all the “rogue” entries and delete (or move) the files. Going via the database is the quicker solution.
or all of the above
The database looks like this
0 = Picked,
1 = Rejected,
2 = Untagged in the DOP and sometimes in the database!?
Null = Untagged in the database
and updating my DB counts program we have
i.e. via this code
If OpenDatabase(#sqlite,SrcDBFile$, "", "")
DatabaseQuery(0, "SELECT count(*) FROM Items where StorePickOrReject = 1")
While NextDatabaseRow(0)
Debug GetDatabaseString(0, 0) + " Total of Rejected Images in Items"
Wend
EndIf
FinishDatabaseQuery(0)
Querying the database is the only solution, because the DOP files do not have these signatures (selected/ rejected)
The DOP has the information at the tail end i.e.
It is held in the “ShouldProcess” field, providing you remember to write DOPs !
The Uuid after “ShouldProcess” is the field that must match between the database entry and the DOP entry for the image. If they don’t match then instant VC!
Perhaps we have not understood each other. In DOP files there is no information whether a file is selected or rejected. This has also been confirmed to me by the support and unfortunately they have not changed it in version 8 either.
@RobiWann If that is what DxO support is saying then they are … about as low as they can go in my estimation!
If you are talking about the red/green “traffic” light system then the field I have identified is the field in the DOP used for that purpose, i.e. “ShouldProcess” (Yes =0, or No =1 or not used by the user = 2, the starting value for the field in the DOP.)
The field is essentially a DxO construct, but a copy of an equivalent in LR I believe, it does not find its way into xmp sidecar files but does find its way into the DOP.
PS:- If you look at the snapshot of the images in PL8.0 you will see that I have allocated, “red”, “green” and none in sequence repeated across a number of images.
These are the DOP endings for the first three images.
I am talking about the 2 symbols marked with arrows in the screenshot.
And I have to disappoint you - there are no fields for this in DOP.
Why don’t you do the following test - create an empty database. Copy two RAW files into a directory. No XMP, no DOP.
Start PL with the new database and visit the directory. Now give one file the green icon and the other the red icon. The DOP files are written. Now close PL, delete the database and create a new one. Visit the directory again - neither of the two files has one of the symbols.
Maybe you are on Mac and it’s different there?
With PL8.1/Win11 it is as Bryan described it:
ShouldProcess: 0=Picked (Green), 1=Rejected (Red), 2=Unset
This is per Item parameter. Do not confuse it with ‘ProcessingStatus’.
What values of ‘ShouldProcess’ were written? DOP files are not updated synchronously with your edits.
Those are the field I have set in the PL8 snapshot and the DOP values track the values I have suggested for the settings exactly.
So
Items (Images) Table - empty:-
The Items Table after the discovery:-
Preference Settings:-
If you are not getting the same results it is you who are doing something wrong not me. I have been writing about this in posts in this forum for years!
Agreed but typically they might be as much as 20 seconds or a little more at most behind and the database is updated immediately.
I am using a Mac, and the ‘ShouldProcess’ property does correctly reflect the picked/rejected/untagged state of the image.
Maybe this is not official because there may be other things that set the status? (Although it seems to work the same even with RAW files that are not supported by PL8).
@Wlodek, @BHAYT
I am sorry. I was wrong. I should have checked it again. It is indeed the case that this field is the indicator. When I was looking for an indicator for selected/rejected a few months ago, I couldn’t find any difference in the DOP files.
Thanks for your persistence. Now I can definitely improve my workflow with DxO.
Thank you for the post. As far as I know the setting has been in the DOP for many, many, many releases.
Why DxO support made the erroneous comment to @RobiWann I do not know!!??
@RobiWann I was going to offer to write a PureBasic program to isolate any images in the database with the “rejected” status and work out a way to safely delete them, safely in that the process could be stopped at any point up to the final deletion.
However, I already wasted time re-doing a test from the past in an attempt to convince you that what I was saying was the truth and fortunately you finally realised that it was the truth.
Thank you for the apology.
@RobiWann did DxO support actually state that the DOP did not contain the flag?
The whole point about the DOP is that it is the database entries externalised and made portable, why would an important field simply be omitted?
If you traverse the DOPs you will actually be processing in the same way that you currently do in DxPL but automated. But you can tailor the scan to avoid processing every DOP every time and it is an automated function so can be left to run unattended, once you are happy that it is working.
It might be possible to select (or ignore) directories using timestamps to speed up the process.
If you use the database you are targeting only the entries that meet the criteria but will need to process every entry in ‘Items’ because there is currently no index on that field.
I have an outline design that should work using the database but ultimately if the entries are not removed from the database then they will be discovered on every scan, only to be ignored when the physical image entry cannot be found.
But the “dead wood” will increase and “corrupt” the counts from programs, like my summary count program.
The problem with removing database entries is that it might be acceptable for my databases but not really acceptable for a program that might be used by others and provide a potential “excuse” for DxO support to ignore any fault reported.
While it is easy to copy the database as the first action of such a program, and that is built into the programs I am writing, ultimately those amended databases need to be used as the “real” database for the processing to be of use to the user.
Regards
Bryan
@BHAYT - #441299 (my DxO Ticket)
Translated answer (I’m German) from Support
Thank you for your patience.
The developers confirmed that this standard is not currently implemented in PhotoLab, but that they are considering it for future versions.
Truly weird because it is part of the ethos of the DOP i.e. that it is an external container of the data in the database.
Any lag in updating, actually rewriting, the DOP, the 20 seconds, or thereabouts that I mentioned in an earlier post, which is probably the only useful bit of information I have ever got from DxO in response to a direct enquiry from me (!?) appears to be part of a batching process for writing DOP updates but they sometimes exceed that by a little but can be written to disk much sooner than that.
All pending DOP writes should be completed during closedown but some might be missed if DxPL crashes. Whether there is some form of continuity/consistency test after a failure I am not sure.
The one inconsistency I noticed in my tests is that for the DOP all unused/unselected entries get assigned the value of 2 but typically get a value of “NULL” in the database, but one that I changed in DxPL and then returned to “unselected” was assigned a value of 2.
However, without an audit trail it is impossible to determine exactly which action caused any specific field assignment. Using DB Browser it is possible to closely track the reactions but the screen requires an ‘F5’ to refresh, it is not refreshed in real-time.
At least I think the German support is bad. Anthony Morganti also complained in a video 1-2 years ago that the support is bad. This was probably followed by comments that the quality seems to vary greatly from country to country.
@RobiWann Arguably much of what I have learned either from others and from my own experiments is knowledge that many software writers may consider unnecessary to share and that certainly seems to be the case with DxO.
There also seems to be some “friction” between Support and Engineering with Engineering being the “Gods”, a very unhealthy attitude (if it actually exists) and I sometimes wonder where the User sits in this “hierarchy”!?
I believe the customer should simply pay as often and as much as possible. No matter which company you choose.
Great support is always expensive and no one will pay for it.
