I meanā¦ thereās a lot: PhotoStructure | How to search your PhotoStructure library
Ok, I added a recently-updated item, one with a before and after, a prior search history, and an order-by toggle (that toggles between most-recent photos, least-recent photos, and most-recently-updated)
Maybe having filters like Google Photos do, is a good addition
photos this date past years
I donāt know if you can use wildcards in dates for that
date:*-04-08
In the paragraph āWhatās a search termā the quoting is a bit misleading: You included the punctuation inside the quotes. Iād suggest to drop the quotes here as you did in the later paragraphs.
Thanks! I just made that change.
Thatās not currently implemented, but itās certainly doable, and I like that format!
The way I store captured-at would let me easily do that query, as itās in ālocal formatted centisecondsā: now is 2021050908321200
.
SELECT *
FROM Asset
WHERE Asset.capturedAtLocal/100000000 % 10000 BETWEEN 503 AND 513;
but itād be an Asset index scan.
Iāll get to this after I get first passes at albums and deletions finished.
If youād like to support this, it might make sense to store year, month, day as separate fields (additionally). However, I have no experience how well SQLite supports arbitrary combinations of fields in its queries (bitmap indices maybe)?
Just as fodder for thought, if SQLite performance ever becomes an issue for search performance: In my day job, Iāve had a good experience with using Lucene (or rather Solr, which uses Lucene indices as itās backend) for arbitrary combinations of search terms on large databases (tens of millions of documents). But that has of course its own challengesā¦
Iāll keep that in mind if the performance is bad. I havenāt had to denormalize much of anything yet in the schema: SQLite seems to be doing great, as long as thereās a relevant index.
I actually coded next to one of the inventors of Solr as he invented it (15 years ago)!
For Docker users, this wouldnāt be bad: add a couple apk install
commands and allās well. Docker consumers donāt even seem to care about image size (although I do a multi-step build and use Alpine to keep photostructure/server
as small as possible!)
PhotoStructure for Desktops is cross-platform, and Iām very hesitant to add larger dependencies there, though. Iād love to use Postgres, for example. SQLite is only 2MB, and Postgresā installer is ~300MB. The entire PhotoStructure for Desktops installer is currently half that. Lucene/Solr is similar. Great tool, but a huge wad of code that would come with it.
Sometimes, the world is rather small
Totally understandable. The cost of such an additional dependency and - probably even worse - maintaining an additional index data structure or even replacing the existing database would be quite high.
PhotoStructure could probably get away with using Lucene directly, although this might get complicated if you are using multiple workers writing to the index. Anyway, I didnāt intend to suggest a change here - just wanted to put a little bit of knowledge out there.
You can just have a generated column in SQLite with an index, so you donāt need to worry about inconsistent updates
i dont know how far along keyword search is but i searched dog, kw:dog, kw:party. and these all turned up nothing.
PhotoStructure currently has no ML tagging, so those ādogā or āpartyā tags would need to be in your file metadata already.
Also related:
Hi! Loving the new search!
Currently a search result is a big collection of everything that matches. Would be good if there was some way of organizing the results.
Iām thinking: would it be possible to add a group by
to search results? So, group by whatever keyword you type (or pick from drop down).
For example I could search for:
-
date:2021
and have it group bymonth
-
camera:nikon
and group bylens
oraperture
The above examples make use of your pre-existing keywords but would be good to also group by user-defined keywords and hierarchies
(did you see what happens when you click the search button in, say, tags/Camera/Nikon
?)
Interesting! Feel free to create a new feature request for this: Iād vote for it.
How would you expect it to handle very large groups, though? Would it automatically switch to ārandom sampleā mode?
(did you see what happens when you click the search button in, say,
tags/Camera/Nikon
?)
Not until you mentioned it! I really like it - especially when browsing fs
, which can get quite deep.
Interesting! Feel free to create a new feature request for this: Iād vote for it.
Thanks! will do
How would you expect it to handle very large groups, though? Would it automatically switch to ārandom sampleā mode?
I imagined it would always be in random sample mode. I guess it would surprise me if Photostructure deviated from this behaviour. Each group would just contain a random sample of results like everywhere else in ps
Unless you mean: what if there are so many values to group by? Like what if I want to group by lens, but I own 100 lenses? Good question - I guess Iād expect Iād be able to see 100 groups albeit only popping into existence as I scroll down the page.
Would like to be able to search by video duration. My library has all of these 2-3s videos, I think from my wifeās iphone. It would be nice to be able to screen those out and only see the longer videos. Not sure if this is a possibility or notā¦
Itās totally possible: the duration column isnāt currently indexed though.
World you expect all images to be excluded if you search with something like duration:>2s
?
Yes, I think I would expect it to exclude images if I was searching duration.
I would like to be able to search by filename.
I would also like search results to indicate how many assets are returned.
This would be helpful when there are zero assets (right now if nothing comes up, Iām not sure if itās because my computer is still processing or if there are actually no results). This would also be helpful when trying out different combinations of search queries, to see if your input is actually impacting the results.
I second this. I donāt have nicely curated tags and content. Nor are my file names or folders descriptive of their content.
This is actually the single feature I want most