Search: Implement "comprehensive" search (search by name fragments incl. numbers OR persons OR places etc.)

[dinoschachten]

Hi,

I noticed that in Photoprism's main search it is currently not possible to find files by their file name.
For instance an original such as DSC01273.ARW can't be found by searching for "1273" (also not by entering the entire exact filename). This search will yield "no pictures found" even though this absolutely exists in my library.

Working with my photos outside of Photoprism as well, but treating Photoprism as my single source of truth, I regularly need to retrieve a specific original from my Photoprism library. For instance when I present a client with JPG versions so that they can select a photo they want edited, I will typically get the number of the desired photo from them, go back to Photoprism in order to find and download the original and make an edit. Currently this workflow doesn't work in Photoprism as I can't find the specific file by the number in the filename.

I hope I didn't miss anything here, feels like I must be doing it wrong, but this behaviour persists in Build 240403-...

Not a huge deal in my opinion, but definitely something that should be included 😊

[lastzero]

While the default text search only finds pictures with related words (not numbers) that have been indexed, you can use the filename (full file path) and/or name (only the name without path and extension) filter to find files by name, for example:

• https://demo.photoprism.app/library/browse?view=cards&order=added&q=name%3A%22IMG_2%2a%22&public=true&quality=3

Here is an overview of the search filters currently available:

• https://docs.photoprism.app/user-guide/search/filters/#filter-reference

[dinoschachten]

Aaah, okay, sorry! Thanks a lot - continue to overlook these manual filters, my bad!

If I recall correctly there are plans of incorporating those into the GUI, so the only question that remains is:

Are there objections to including filenames in the default text search?

I would say definitely (and change this issue accordingly), but I'm sure there are other valid considerations/opinions on this.

[lastzero]

Words in filenames can generally be found, it is just that numbers are not indexed as words. First because they are numbers, not words, but also because many filenames in practice include random numbers or sequential numbers counting from 000 to 999. So that would clutter the index and could have a performance impact. When you want to search for filenames specifically and only, you may also not want to see search results related to the generic text search. Other than that, it could be done.

[dinoschachten]

Yes, being able to filter strictly is definitely great and necessary in certain cases.

Not sure if I understand the point regarding cluttering the index - I assume the fact that I can search for filename (using the filter) means they are stored in the index anyway?

I admit I (and certainly many users) have really learned to appreciate search functionalities where I type a string of characters that is a fragment of the name or contents of the thing I am looking for - without needing to remember to select/type the appropriate filters to use (unless I want to filter very specifically). I think it would make the (pretty impressive) capabilities of Photoprism much more intuitively accessible...

The problem I see with the current implementation is that search results are currently misleading unless you understand a little bit about how and why the search works the way it does: I could find some photos by words from their filenames, while some were unfindable by fragments of their filenames (which happened to be numbers), leading to assumptions like "My index is broken" or "How come I don't have that in my library?"

So I would definitely still vote for including the "name" filter (with an implied wildcard before and after the search term) in the search by default (or whatever the best implementation is to achieve the same result).

Maybe an alternative could be to implement controls in the settings for what the search should include by default (if no dedicated filters are set)?

If you agree, should I rewrite this issue accordingly? And if not: What should we do instead?

[lastzero]

Not sure if I understand the point regarding cluttering the index - I assume the fact that I can search for filename (using the filter) means they are stored in the index anyway?

Filenames use a different index than the regular text search. So we would need additional lookups to perform the search, and the filename index cannot be used if you search for words/strings that are not at the beginning. For example, DSC01273 and DSC0* would work, but *01273 would not (well, it will work, but it requires a full table scan, so it may be slow).

[dinoschachten]

I wanted to do a bit of testing regarding the performance of the behaviour of the main search that I proposed (which is to (optionally or by default) include more/"all" resources in the search for a particular term).

In order to simulate this behaviour, I wanted to use the OR operator like this:

dino | name:"*dino*" | person:"*dino*" in order to search for images that include Dino anywhere in their name, words, or depicted person.

It appears to me that currently the OR operator is only supported within any particular table, such as person:"Dino Schachten|John Doe", right?
I realised that the wildcard generally does not work in persons - which is a minor inconvenience, just a side note in this context (though it might be a relatively low hanging fruit to implement).

So it seems my desired behaviour cannot be accomplished "manually" with one single search as of now?

A bit of good news: On my ~95k library I performed the searches for person (~1s), partial name (~2s) and words (~2s) separately, and I'm quite happy with the fact that this combined OR search should take no more than approximately five seconds.

I do realise that there are labels, places etc. that could also be included, which is why I would suggest this:

A toggle near the search bar which allows users to switch between the current (I'll call it "indexed words") search, and a comprehensive search that incorporates all available tables at a performance penalty? For users such as myself that sometimes need to check if there's anything at all related to a particular term in the archive, this would be an absolute charm.

[lastzero]

It appears to me that currently the OR operator is only supported within any particular table, such as person:"Dino Schachten|John Doe", right?

Yes, that's correct.

A toggle near the search bar which allows users to switch between the current (I'll call it "indexed words") search, and a comprehensive search that incorporates all available tables at a performance penalty?

You're right, we should definitely implement UI/UX improvements for the search to make the available filters and features easier to use. Right now, you'll need to read the docs for anything beyond the regular text search and the dropdowns we offer when you expand the search form in the toolbar.

Here are some related issues (you can probably find more and @graciousgrey has a better overview than I do):

• UX: Add photo/video/both switch to albums and search results #2200
• UX: Searchbar + Filters within Albums/Moments/Calendar/Folders #651