How to see how many pictures there is in a database

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.

@Stenis I am trying to understand

  1. exactly what you are after
  2. 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.

and the table you are interested in is “Items”, which holds all the main details or every image in the database!

So select the “Browse Data” option and select “Items”.

So for my test database I have 4719 “Items” (Images)

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!

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. :slight_smile: 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

and can be compiled to an exe.

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.

@Wlodek You are ensuring that only RAWs are being counted but in my case that gives

image

so I must have JPGs in my database but for most users the two figures would be identical and if not is it right to exclude images that are not “RAW”.

That has been covered many many time with users who have inadvertently “opened” a directory or got DxPL to index “everything in sight”.

Yes we do need a scope from @Stenis and the result is a simple count which could be a mismatch with other programs for a number of reasons!

@Wlodek but this is a little worrying, I think

or even worse

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.

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:

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

  2. 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 :slight_smile:

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.

A search could do that, Search by parts of filenames that all files share, be it in the name or extension part.

PhotoLab supports jpeg, tiff, dng and raw files…but I don’t know how virtual copies are shown in search vs numbers shown in a DB browser.

Also, the numbers might not be comparable between apps e.g. due to outside operations like renaming with Finder or Explorer.

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.

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

2024-08-03_081140_

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

@Stenis, @platypus, @Wlodek The test I “threatened” you with which starts with 3 images, 2 RW2(RAW) and 1 JPG

image

and the database shows

image

Now add a few VCs to image 1 and we get

giving the following counts
2024-08-03_110822_

at this point the disk files look like this, i.e. DxPL no longer creates DOPs automatically but only after some edits have been made

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.

Just be aware of that, @Stenis

These would be appreciated feedbacks :+1:

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