Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
1
Maybe I have missed something very obvious but I can´t find an easy way to see how many pictures there is in Photolab Picture. When I select my indexed top folder that holds my entire folder and file structure it says “0”. Both in Capture One and PhotoMechanic that is very obvious but not so in Photolab what I can see.
Does anyone else have better phantasy than I have to figure this out.
The reason for this need is that I am using three diffeent softwares and want to be able to see that their indexes are in synch.
why are you after that information, i.e. is “just” having a count sufficient or is there then something you want to do with that data? (You actually explained that sorry)
I don’t believe that a count of the images in the database is available anywhere except from the database itself.
It is strange that you asked a question like this because I was considering what to do with “Drive swop” code I have written in PureBasic and was considering release part of it to show the details of what drives are in use in any DxPL database.
If you need the details this minute then download a copy of “DB Browser for SQLite” and install, there are copies for Windows and the Mac.
Then use the “open command” to open the database you are interested in, e.g.
I will try to create a simple program that you can run at anytime but the above might do for the time being.
PS:- It might be ready by tomorrow, I have cleaning and gardening to do today!
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
3
I just want to see how many pictures were indexed when I was indexing my pictures. I just want to be in synch between all my applications when it comes to the count. Both in C1 and PM Plus that is monitored both during indexing and any time I want but obviosly not so in Photolab either during indexng or through the ordinary interface.
Thanks anyway for your answer Bryan I will do it through SQL Lite instead. It will do the job!
@Stenis understood but the code looks a bit like this (changing the database location needs work, as does the output - currently the debug screen) but it works
Perhaps select count(*) from Metadatas where isRaw = 1
would be better (Windows, don’t know about implementation on Macs). Note also that PhotoLab database contains info only on files which PhotoLab has “seen” in the directories which were “current” for long enough to read all the metadata. PL does not look into subdirectories, so there might be in fact more raws there. Not sure, what’s the goal, though.
I think PL updates the database with non-raws during exports and when directory is read with RGB filter enabled. On the other hand, there might be “orphan” entries, if some files were manually removed in a directory which was not read later by PL or if directory was renamed. The DB is used to locate entries in the thumbnails and preview caches and as a cache to metadata, associated module numbers, processing status, etc.
For my purpose, I just use dir /s *.NEF, as I have only NEF raws.
EDIT: In my case there are currently 98649 entries in Sources and Metadatas, 98557 in Items, 92828 in Iptc, and 48930 isRaws in Metadata. I don’t have any reason to work it out, but I think @Pat91 did some research on the DB (e.g. info on orphans comes from him).
dir /s *.nef lists 87487 entries but almost half of them were never read by PL.
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
9
You know we don´t need to overwork this guys. It is not any more complicated than to open the “Items” table and look at de summary in the left corner below the table. That is really all that I need in this case. That number is the same as I see in Capture One too when they are in synch and that is good enough for me.
But I definitely think DXO ought to do at leats two things:
Somewhere, not just display how many pictures there are in the current open folder but also display the total amount that has been indexed by the Picture Library-database. The reason to that is that it is vital info for some people that use external software like PM Plus or anything else that keeps trac of the total ampunt of pictures they are handling. It is vital info that indicates if the systems are in synch or not.
Also add a progressbar that reflects two parallel processes like both PM and C1 does:
First it ought count imports (C1) or indexed pictures (PM) and than the count and progress of preview renderings and the expected time it should take to do the job.
Processing 25 000 pictures used to take close to four hours before we got the brand new version 16.4…4 of Capture One. Now it is so much faster and do it in about two hours. My second database holds close to 50 000 pictures, sp as you might understand that takes even a lot longer. That is just one proof of the focus Capture One has on productivity.
I have worked with cleaning up and harmonising my catalog structures and naming recently because especially Capture One strangely enough could not handle subfolders that had the same name in different main folders of the main database.
For example I earlier had folder called for example “JPEG” or “Full size” or “Print” and that doesn´t work at all for me in C1. Instead of staying under the main folder it belonged to all of those ended up in a pile with all the rest of the “JPEG”-folders and the “Full size”-folders e.t.c. So I had to change it.
I also deleted a lot of old JPEG-filefolders with sRGB-files because I have changed my own standard to Display P3 instead. So I will have to make new ones with the broader color space in order to match the profile of my display. I also converts them to DXO Wide Gamut since the Classic color space I guess might clip part of the P3 spectrum at the export otherwise. So of these reasons I feel dependent of info in Photolab´s interface that just isn´t there today.
Thanks for your united efforts guys - appreciated
To avoid the orphan problem it is just to delete the database in Photolab (if you don´t rely on using “Projects” for example) and reindex the master folder of your folder structure again and doing the same in the other applications you happen to use. Since C1 is twice as fast as it used to be rendering previews, that job is half of the problem it used to be before we got the last update.
@platypus every copy gets an entry in the 'Items" structure so it might be better to use ‘Sources’ (I believe the structures have a prefix on the Mac). Thank you for asking the question.
@Stenis I believe that using ‘Sources’ is a more accurate way to determine the count you want.
So ‘Metadatas’ relates to the original image, as does ‘Sources’
Sorry I was engaged with my chores and trying to wrap my brain around PureBasic and obviously not “firing on all cylinders”.
So when an image is “discovered” by DxPL an entry is created in ‘Items’ and ‘Sources’ (which points to ‘Folders’ so the directory of the image can be located) and ‘Metadatas’ and also in ‘Iptc’ as well.
‘Folders’ certainly contains the original drive details and every component of every image location as well so C:\A-dir\B-dir\C-dir\Image-dir gets 5 entries the first time that image directory is encountered
Any VC will result in an additional entry in ‘Items’ and will have also get its own ‘Iptc’ entry, immediately its created I believe.
I will do a quick test to confirm this a little later.
As both @Wlodek and @platypus have pointed out there is no garbage collection in DxPLdb so any renaming outside DxPL will result in “lost” entries in the database and, potentially “dead” references in any ‘Projects’.
Interesting…but the problem persists, problem that DPL lists all files (supported formats) and that some of these files might later be renamed or moved by Finder or Explorer. This can lead to differences in numbers between different apps, unless they work the very same way as DPL in relation to keeping track of your photo archive’s inventory.
@JoPoV, @Stenis the chance of any real change is close to 0 I believe.
Firstly regardless of how an image winds up in the database, by importing via user directed discovery or by user initiated indexing, the data is held in the database in exactly the same way.
To provide that data to the user DxPL would have to have variables that can be accessed for updating and display and they are nowhere to be seen, or DxPL would have to use the same SQLite constructs that I used to traverse the structure and provide the details when requested, more user friendly than my approach but …
The original indexing approach was as a background task until PL7 when it became a foreground task meaning that undertaking an indexing operation became a disruptive process.
No reason was given for the change.
It would be possible for DxPL to approximate the time to complete a task, e.g. loading an image directory but I won’t hold my breath waiting for such a capability.
Submit a support request citing the features offered by Capture One and PhotoMechanic, although I believe the Capture One would be the only one of the pair seen as offering comparable facilities.
In the meantime all you have is my program, or to look directly into the database, that will become a little more user friendly, e.g. provide logging facilities that are date/time stamped so it becomes possible to preserve and compare results from one run of the program to the next.
PS:-
I am referring to DxPL(Windows) in this statement.
It will do the job!
