Searching For Photos Based On Tags

[bostonman]

I had an odd idea, that after some brief research, seems more popular than I thought because various types of software exists (and it can probably be done in Excel).

My thought is to tag several images (JPGs) and create a way to search for them based on a criteria. Unfortunately I think it will be too time consuming but wanted to ask if such a program exists that anyone is aware of.

The idea I had was for a collection of family photos comprised of about 2k pictures. I thought to create a program where I could check boxes that would filter the pictures. The check boxes could be customized so they could be a check box for: mom, dad, brother, sister, aunt, uncle, car, vacation, etc...

As I check each box, it narrows down the pictures. Say I wanted every picture with mom and car (maybe I have several of mom standing by a car). Then it will give me only pictures with mom and a car whereas I may have a picture of date standing by a car and those would be ignored; unless I checked only 'car'.

I think the part of creating filtering software would be easy, however, tagging each photo individually would be extremely time consuming. Each photo file name would need to go into a database, and associated with the tags. Each photo would need to have a tag for each check box in the software. So I'd have to view a picture, and somehow enter into the database filename1.jpg has 'mom', and 'car', filename2.jpg has 'dad' and 'mom', etc...

Just curious if anything like that exists, but, as mentioned, I think it would be a time consuming process that's not worth it; unless I wanted to take several hours creating the tags.

[Analog Kid]

I actually started to write such a program myself (Windows GUI), that would allow photos to be tagged and retrieved in a database. Ended up with just a picture viewer. I'll have to go back and take another look at it.

It's definitely a non-trivial undertaking, but one that would be doable and quite useful.

Hard to imagine that there's not already some software out there that does just that, but I don't know of any.

[bostonman]

Wow, so someone else had a similar idea.

As mentioned, I honestly doubt associating every picture with tags to be filtered would be easy. The idea I had (which isn't any easier) is:

The (as you suggested and I visualized) GUI would allow someone to create their own criteria list because everyone would have different needs. Maybe one person wants to use it for family photos (mom, dad, etc...) whereas someone else wants it to organize photography (trees, mountains, etc...).

To simplify it, let's say the criteria is two (mom and dad), then the program displays the first picture and asks: mom y/n. The person selects 'Y' for yes stating the picture contains 'mom' (or 'N' for no) and then displays the second picture asking the same. After it goes through all (say) 2k pictures, then it asks: dad y/n and starts showing all the pictures again.

This would repeat for however many criteria options the person has. If the person wanted 20 options, then they'd have to go through every picture answering Y or N 20 times. If it were 2k pictures, it would be 40k (2k times 20), so most likely few will do this.

The other option would be to display all the pictures in thumbnails, select criteria "mom", and click on every picture you want associated with "mom". Then uncheck "mom" and check "dad" and click on every picture associated with "dad". This would repeat for (as the example above) the 20 options.

I imagine to make it less blinding with the thumbnail options, one could move maybe 25 pictures into a directory and do 25 at a time, then combine them into the one directory (or directories) again.

[tooki]

I loved the hierarchical tagging in Apple’s long-defunct pro photo management program, Aperture. You could make entire hierarchies of tags, and searches would correctly include the photos with subordinate tags.

For example, you could have:
-People
- - Friends
- - - …
- - Family
- - - Parents
- - - - Mom
- - - - Dad
- - - Siblings
- - - - Bro
- - - - Sis
…

(Actually there is a separate face tagging function too.)

So if you did a search for the keywords “family” and “Argentina” (assuming you’d made a similar hierarchy for one’s travels), then it would also find photos that didn’t expressly have those keywords but does have subordinate ones, for example a photo tagged “Mom” and “Buenos Aires”.

I still have my DSLR photo library managed in Aperture running on an old Mac Pro. Apple never provided a truly good migration path from Aperture to anything else. :/

[DiTBho]

BeFS on Haiku/OS is a "relational filesystem" and can store "tags" in metadata.
I think this is the perfect use for its unique feature! 

[Nominal Animal]

I implemented this as web pages back in 1999 with the backend in PHP, for an interactive exhibition at Kiasma museum in Helsinki, Finland.

Nowadays you could do that easily as a static web page, with the images in a subdirectory, plus a simple Javascript file describing the images, basically along the lines of

Code: [Select]

const images = [
  { thumbnail: "IMG_20250801_000000-small.jpg", thumbwidth:400, thumbheight:300,
    original: "IMG_20250801_000000.jpeg", originalwidth:3264, originalheight:1840,
    title: "Mom with her car in 1995",
    keywords: [ "mom", "mother", "car" ],
    description: "Long text describing the image." },
// above structure repeated for each image
];
I'd generate the thumbnail versions automatically using command-line tools like ImageMagick, and automate the pixel size fields leaving title and keywords empty, and populate those by hand.  Note that the file containing the images array object does not need anything except as shown.

This way, you could open the "gallery" on any computer with a browser, even on a cell phone; either locally or from a secured web site.  (The Javascript says the same regardless of whether you use it locally, or from a web site.)

The coding part is easy; the hard part is making the user interface nice, easy, and intuitive enough for others to use it, making it worth implementing.

The keyword search and image title search (same text-based search, with +required and -disallowed prefixes and double-quoted exact search terms, with checkboxes to limit the search to keywords, to image titles, and/or to long description.)

It is possible to interface to Excel and other spreadsheet programs using CSV format, although parsing it in JavaScript is a bit annoying.  More useful would be a feature that allows one to add new (local) images to the data array with an easy interface –– but when saving, the user needs to select the correct file and name to save it over, because it uses the browser save/download feature; it cannot be made easier than that.  (The user needs to create the thumbnail versions themselves, and move the image file to the images directory, and know the names of the files when adding the metadata; I do not believe it is feasible for the browser to scan the directory contents.)

As a web service, if you have a web server or web hotel, all this is trivial, except for securing part (which itself is also standard stuff for secure web services).

[abeyer]

There's lots of tools out there that do this... many now also will do the tagging for you based on object and facial recognition ML models, and are getting pretty good at it. Most of them tend to be aimed at photographers and creative agencies. The search term you want is "Digital Asset Management (DAM)" The commercial ones can get quite fancy and expensive, but there are some open source alternatives too.

[Analog Kid]

Wow, so someone else had a similar idea.

As mentioned, I honestly doubt associating every picture with tags to be filtered would be easy. The idea I had (which isn't any easier) is:

The (as you suggested and I visualized) GUI would allow someone to create their own criteria list because everyone would have different needs. Maybe one person wants to use it for family photos (mom, dad, etc...) whereas someone else wants it to organize photography (trees, mountains, etc...).

Just for giggles I went ahead and mocked up part of a program that might do what you described:





The first dialog builds the list of tags, just a simple list of text strings that can be used for tagging pictures.
The second one tags pictures with selected tags.

Rather than have separate lists for different people using this, I assumed just one list where everyone could just add whatever tags they want to the pool, assuming no privacy issues.

This would all go into a database containing the filename of the picture and the tags selected for that picture. It would be pretty simple to go through a folder and pull out all pictures that had certain tags set. (That would be another dialog which I haven't mocked up.)

All this is doable, but there's a major problem that I don't know how to solve:
Say you've gone through all your pics, tagged them and created this database. Fine and dandy.
But then you decide you want to rename some of the pictures. And move some pictures to a different folder, or a different drive altogether. Now the database you've created is out of sync with the computer's file system. And that's a major problem.

So I probably won't be trying to actually implement this anytime soon. But I was curious to see if this was anywhere close to what you had in mind.

[Nominal Animal]

Note that all JPEG file formats (SPIFF, JFIF, EXIF) support custom or description chunks you can store UTF-8 encoded keywords/description in.  You will want to copy the information to an index for more effective searching, though.  One commonly used approach is to keep such an index file –– perhaps an SQLite database, perhaps something else –– in the image archive directory, so that if the directory modification timestamp is newer than the index file modification timestamp, the index is stale and needs to be rebuilt.

[Analog Kid]

Note that all JPEG file formats (SPIFF, JFIF, EXIF) support custom or description chunks you can store UTF-8 encoded keywords/description in.  You will want to copy the information to an index for more effective searching, though.  One commonly used approach is to keep such an index file –– perhaps an SQLite database, perhaps something else –– in the image archive directory, so that if the directory modification timestamp is newer than the index file modification timestamp, the index is stale and needs to be rebuilt.

I wouldn't want any picture-indexing program to modify any of the picture files. Those should be off-limits, read-only.

[Nominal Animal]

Note that all JPEG file formats (SPIFF, JFIF, EXIF) support custom or description chunks you can store UTF-8 encoded keywords/description in.  You will want to copy the information to an index for more effective searching, though.  One commonly used approach is to keep such an index file –– perhaps an SQLite database, perhaps something else –– in the image archive directory, so that if the directory modification timestamp is newer than the index file modification timestamp, the index is stale and needs to be rebuilt.

I wouldn't want any picture-indexing program to modify any of the picture files. Those should be off-limits, read-only.

I'm suggesting the exact opposite.

When you store an image to the collection, you add whatever description, title, and keywords associated with it.  This does not affect the image data at all, and is similar to e.g. comments stored by photo editing software.  Tools like ImageMagick do support stripping these off, and do so by default when the image is resized or edited.  Essentially, you only modify the image files when you modify the associated metadata.  The indexing application never modifies the image files, only the cached index; and it can detect whether the cache is up to date by comparing the directory modification timestamp to the index file modification timestamp.

Also, it is perfectly possible to do such editing in a way that ensures the image data remains intact.  (In fact, not doing so is one of my buttons: my data is invaluable, and tools that do not respect the integrity of my data, or do not report errors that might endanger that, are less than worthless to me; they're utter shite to me.  I despise programmers who leave "implementing error checking for later, when they have the time", because that never ever happens; and also programmers who consider checking errors that are possible but rare "useless" or "paranoid".  Paranoia is my friend, when it comes to security and data integrity.)

Note, however, that my first/primary suggestion was a separate database file.  That is not only more common, but often a better approach, exactly because the image files (possibly excepting for cached resized preview/thumbnail versions) are never ever modified.  For browser-based stuff, you can use either a plain JavaScript object declaration file (whose format is quite human-friendly), or for example JSON (which basically all browsers nowadays can parse very efficiently using the built-in JSON.parse() static method.

Modifying the image file metadata (including title, description, keywords, and possible GPS data) makes more sense only when the metadata is intrinsic part of the purpose of the images; say like recording the location, date and time, and full names of the people in an image.  For a company imaging their products, the corresponding information might be the image license, date and time, product name and version, perhaps even serial number of the product.  That way, even if the image is transferred (and in some cases modified, although as I mentioned the extra data is stripped off when using conversion or Save As... functions in photo editors), the metadata is retained.  For example, one might add such metadata before publishing, or before archiving the images on some long-term read-only media, perhaps as part of inspecting, cropping, rescaling, optimizing the photos involved.

[bostonman]

I wouldn't want any picture-indexing program to modify any of the picture files. Those should be off-limits, read-only.

I agree.

The issue of moving files, renaming, etc... I guess it could get quite complex trying to maintain it.

Years ago when newsgroups were big, a group of collectors posted pictures, thousands and thousands daily. They were pictures posted from stuff around the world, but, more common were Playboy collections. Someone created a program called Pic Check or something like that (I probably still have it somewhere).

It was maintained by a group I believe (don't quote me as I'm improvising a bit) and created a CRC for every picture maintained in an Excel sheet.

You would go on the newsgroup, download whichever category (or categories) of pictures you wanted by the 1000s (or a single picture). Now you had a directory of say 10k pictures that may or may not be legit, edited by someone, wrong names, not organized, comprised of several categories, etc...

A few maintained websites who created Excel spreadsheets (CSVs) comprised of the file names and a CRC for pictures that were legit. You'd download the CSVs, and it wasn't that many, maybe one zip file that contained ten CRC Excel files for a collection of Playboy pictures (maybe one CRC for each decade), place them in the Pic Check program, and run a scan.

The program would take the 10k files, and, providing the CRC matched, change the file names according to the CRC Excel file. It would then place them in the appropriate directories. At that point the remaining files were either junk or not associated with a CRC file that you didn't have. Maybe you desired obtaining more CRC files because it was part of another collection, or you didn't care to collect them.

The program also generated a CRC of missing files that the user didn't have but appeared in the CRC. So you could post the CRC to the newsgroup and someone may fill it for you allowing you to download them and run the whole process.

I was thinking for this idea, maybe generate CRC's for the pictures and the program could scan directories that are selected for the pictures. If a file name is different, then it could alert the user and/or ask the user if they want a list of files (pictures) changed to the new name in the directory which would then change the name in the CRC list.

Or you could have it scan a list of selected directories and it would report X files no longer exist (maybe because they were deleted or a name change)  and Y new files exist allowing the user to edit the tags so a new CRC can be generated.

As for getting around locations, I think the program could just generate a list of file names that can be double clicked. When clicked, it opens the picture in the default picture viewer such as Windows Picture Viewer (maybe a preview window in the program, but we are more focused on how to locate pictures rather than turning it into a fancy program). Generating the list can be simple as it would just scan a directory and all the sub directories along with selecting other directories.

So it could have check boxes allowing the user to select: c:\Family Photos, c:\Kid Photos, etc... and it would scan the sub directories c:\Family Photos\Mom, c:\Family Photos\Dad; and then c:\Kid Photos\Joe, c:\Kid Photos\Mary, etc...

[Analog Kid]

As for getting around locations, I think the program could just generate a list of file names that can be double clicked. When clicked, it opens the picture in the default picture viewer such as Windows Picture Viewer (maybe a preview window in the program, but we are more focused on how to locate pictures rather than turning it into a fancy program).

Displaying a picture preview is one of the more trivial aspects of such a program. The mockup I posted above has a window that shows an actual preview (scaled to fit the window) of an image file; I didn't put that image there in an image-editing program.

[bostonman]

I saw the image with the preview pane and was emphasizing that having it wasn't necessarily important, however, I didn't realize it was trivial; it's also a nice feature.

Attached is the (Freeware) program I mentioned. If you look at the dates within the ZIP, it shows 1998 and 2006, so it shows how old the program is.

I haven't played with this program in quite some time (probably since late 2000s). It can create a CRC list from a specified directory, sort, rename, etc... It's not necessarily worth investing time to learn, but more of a reference of how one person sorted pictures. Obviously this is different than tagging filenames.

[DiTBho]

Frankly I prefer a relational filesystem, where you can simply add a tag in metadata and query.

Makes this kind of tasks very simple, even for the GUI point of view.

[peter-h]

ACDSEE (available in countless old versions very cheaply) does all this for you. Image selection by EXIF tags etc.

Even ACDSEE v5, which came on a CD on the cover of Personal Computer World magazine in 1995, works just great under win7-64 And has these features.

[Analog Kid]

Frankly I prefer a relational filesystem, where you can simply add a tag in metadata and query.

What is a "relational filesystem"?
Is it something available to, say, a Windows 7 user?

[DiTBho]

A relational filesystem is a way to store files that combines features from classic hierarchical file systems, relational databases, and content-addressable storage systems.

Windows does not have it.
AIX does not have it.
HPUX does not have it.
Irix does not have it.
RiscOS does not have it.
NextStep does not have it.
Linux does not have it.
MacOS does not have it.
FreeBSD does not have it.
NetBSD does not have it.
OpenBSD does not have it.
MorphOS does not have it.
ArOS does not have it.
XINU does not have it.
BeOS has it.
Haiku/OS has it.

MyFS (my toy filesystem) has this feature 

[DiTBho]

Moral of the story, install Haiku on a x86 mini-pc and make it a relational filesystem + web server 

[DiTBho]

In theory, NTFS supports "extended attributes and alternate data streams", which you could use to do the same thing 

[abeyer]

What is a "relational filesystem"?
Is it something available to, say, a Windows 7 user?

Not sure if that was a genuine question, or a dry jab at microsoft? 

[Analog Kid]

No, it's a real question: I haven't heard that term before.
Of course, I do take every opportunity to jab Micro$oft anyway ...

[PlainName]

Wouldn't a traditional photo database app do this? For instance, Daminion allows user defined hierarchical tags, and then allows selection of super-tags and/or sub-tags as in the aforementioned 'family' super-tag with 'parents' and 'siblings' sub-tags (and sub-sub-tags). You can do searches, such as "parent AND woman" or "car OR bike", so it seems to cover everything requested in this thread.

EDIT: Seems that version of Daminion (standalone photo album) is no longer with us and they've chased the money. The version I have was free for some not excessive use (easily covered my requirements) but I never felt the need to keep it updated. Fortunately. However, I've left the description here to show that this kind of things has been around for a long time.

Another one was idimager, which was great and similar to Daminion (actually vice versa) but the author decided it needed to be done over from scratch, and that turned out as most similar restarts with good intentions do. It is now Photo Supreme and not that cheap, but also illustrates that this kind of thing isn't new.

So... what's the requirement of this thread that the typical photo management app doesn't do?

[abeyer]

No, it's a real question: I haven't heard that term before.
Of course, I do take every opportunity to jab Micro$oft anyway ...

Ha! Ok, it was just funny because of the backstory...

Microsoft had every intention of shipping a relational filesystem for windows... it was a big part of a project called windows longhorn that kind of imploded and failed. The aftermath of that is what lead to shipping vista as a "get something out the door now" mess, and the better parts of longhorn that were salvaged mostly shipped in windows 7 (but the relational filesystem wasn't one of them and was abandoned.)

So, in theory if they'd ever gotten it done, it kinda would have been a windows 7 thing.

[Analog Kid]

So in other words it doesn't even exist. (At least not in Windows-world.)

That's 10 minutes of my life I'm never getting back.

[bostonman]

So... what's the requirement of this thread that the typical photo management app doesn't do?

Seems some have provided suggestions.

The requirements were in the first few messages of this thread. One requirement was that the photo itself doesn't get edited with any tags or whatever.

My vision is a split window with check boxes on the left and a list of files on the right. Maybe the file list is the directory and all its sub directories; and maybe more than one directory can be chosen.

On the left are check boxes with filters that can be edited by the user. The check boxes may be: mom, dad, brother, sister, car, vacation, etc...

The list of pictures have already been associated with the filters (this is the difficult part) and placed into some database.

Say you want to find a picture of mom standing by a car. The file names are already in a database and the user has already taken extensive time to associate each picture with a tag. As each box is check (mom, car, etc...) the list of files on the right decrease showing the pictures that contain those two (or more) filters.

Then the user can double click on the picture and/or click on a picture and use arrow keys to show each picture rather than having to double click each one individually (maybe 100 pictures exist with 'mom' and 'car'; you certainly don't want to double click, close, double click, close, etc...

[PlainName]

That's what the photo managers do. I wouldn't touch one that actually modified a file (including filename) so no problem there - all my photos are flagged RO as they get pulled off the camera or phone, just to make sure.

The advantage over messing with a filesystem is that it's filesystem agnostic - change your system for any reason and the database and files remain just as they were on the old setup. Having relational filesystems sounds cool, but you're locking yourself into compatible systems and future you may find that not optimal.

You suggest the filename is an accumulation of tags (mom, parent, woman, for instance) but you have to change the filename if you add or remove tags. None of the photo albums do that - the tags for every photo are kept in a database separate from the photos. If you edit a photo the original is never changed and instead a copy, which is your edit, is saved. Whether you normally see both versions or just the edited one is typically a user preference. Add or remove tags and the photo files never change.

I am not trying to push you into a photo album app but you wanted to know if such a program existed, and whether doing the tagging was worth it. They do, and many users seem to think so, in that order.

[Analog Kid]

I figured out one piece of the puzzle, which is how to detect changes to the file system (creating, deleting and moving files) so that the database could be automagically updated when these things happen, allowing the photo-finding app's database to be synchronized with the actual state of the file system. (This is through some Win32 functions that I previously didn't know about, specifically one called ReadDirectoryChangesW() that logs all these changes.)

So it may actually be possible for me to put together a rudimentary but working app using this. We'll see ...

[Nominal Animal]

The requirements were in the first few messages of this thread. One requirement was that the photo itself doesn't get edited with any tags or whatever.

My vision is a split window with check boxes on the left and a list of files on the right. Maybe the file list is the directory and all its sub directories; and maybe more than one directory can be chosen.

On the left are check boxes with filters that can be edited by the user. The check boxes may be: mom, dad, brother, sister, car, vacation, etc...

The list of pictures have already been associated with the filters (this is the difficult part) and placed into some database.

Yep; the viewer part you can do trivially in a browser –– the second biggest part is deciding how to present the images; some kind of a preview/book, paged or continuous, preview sizes ––, but populating the database is the biggest task.

If you separate the database modification to a separate browser page –– that is, you have a separate viewer, and a separate image tagger/adder ––, I think I could create an example static HTML+CSS+JS for this (one for viewing/searching, another for editing the database), although I won't make it pretty or nice to use: the visual user interface tuning is the hardest part in it.  You know, CSS finessing like colors and layout, whether the preview images are in a grid or a list, paged or continuous, preloaded and just hidden or the entire list regenerated when choices change.. it's basically best to do that stuff by practical testing on unsuspecting victims.

The basic structure is similar to my Finite Impulse Response Filter Analysis tool page (view its source): it works both online and locally, and will not require any network connection.  (You can save the single HTML file locally, and open it in a browser.  For the FIR analysis, you stick the coefficients in the top bar, say 1 -1 for a high-pass filter, and it'll auto-draw the spectral response of that filter.  The horizontal axis is the frequency, with zero on the left and half the sampling frequency on the right.)
As usual, this would be in Public Domain / CC0-1.0, for anyone to use as they wish.  (I do this because I wish people would use the technique; it works surprisingly well, and is portable.)

The one downside from browser-based tag editing is that it cannot easily scan directories for file names: the JavaScript can only pop up an Open dialog (although it can be limited to image files by default), where the user can select any number of files; Ctrl+A or Cmd+A will select all files shown in any particular folder.  Similarly, saving the modified "database" uses the browser "Save Download" facility, so the user must save the database over the previous database file where the viewer part will see it; it cannot be automatically named, user interaction is necessary.

[Analog Kid]

But with a browser-based solution, you'd still have the same problem as with a non-browser application:
How do you synchronize the picture database with the actual state of the filesystem?
As the user moves, deletes and renames (picture) files, the database will no longer match the filesystem.
As I posted above, I discovered at least one way to programmatically rectify that problem. Not sure it could be adapted to a browser-based app, though.
A browser-based app would be my last choice for such a package, BTW, but that's just my personal prejudice.

[ledtester]

Just curious if anything like that exists, but, as mentioned, I think it would be a time consuming process that's not worth it; unless I wanted to take several hours creating the tags.

I would look at one of the "self-hosted alternatives to Google photos":

https://itsfoss.com/google-photos-alternatives/

I don't have any experience with any of them, but it is clear they keep their own indexes of the photos.

Some even have built-in facial recognition so it can tag people for you. Some even have object recognition, e.g. this post from the immich reddit:

https://www.reddit.com/r/immich/comments/18hudoe/is_it_possible_to_search_for_an_object/

[Nominal Animal]

As the user moves, deletes and renames (picture) files, the database will no longer match the filesystem.

The only reliable solution for that is to add the tags into the files themselves.

There are libraries in various languages that provide an uniform simplified interface across various filesystem monitoring approaches in different OSes (inotify/fanotify in Linux/Android, fsevent in macOS, kqueue in BSDs, ReadDirectoryChangesW in Windows), but the entire approach suffers from the simple fact that moves and renames are rare compared to additions and new image creation via file editing (think resizing and such).

Also note that it would have to be running all the time, too, and monitor all events involving the image folder(s) whenever the computer is running.  The run-time overhead would be small, but not neglible!

I think you should seriously reconsider what you expect from this kind of an application, and whether you really want an always-running service consuming resources on your workstation(s).

A browser-based app would be my last choice for such a package, BTW, but that's just my personal prejudice.

Yep.  Most people today do not realize how efficient an environment it is, especially the JavaScript engines; and miss the obvious benefits like no installation or privileges required, excellent visual properties and theming capabilities via CSS and SVG vector graphics elements, and so on.
(My home page uses CSS and embedded SVG, contained in a single 21,749-byte uncompressed file, and is exactly as sharp on any resolution and device.)

Although it is online-only, just do yourself a favour and explore the online EasyEDA electronics design suite a bit.

There is no technical barriers for something like that to also work locally, without any server or network connections –– and you really don't need to use any external libraries or frameworks either!  The "Save" operations will always pop up a file selection dialog unless you use the FileSystem API and FileSystemDirectoryEntry objects that not all browsers support (and which only works locally, not in a web environment, which are why I do not normally use it).  AFAIK, there is no directory modification notification mechanisms available yet.

[PlainName]

Most people today do not realize how efficient an environment it is, especially the JavaScript engines; and miss the obvious benefits like no installation or privileges required, excellent visual properties and theming capabilities via CSS and SVG vector graphics elements, and so on.

Primary reason why I dislike web apps is because they share the same window as every other web thing. And I don't mean at the same time, but even run separately in their own window.

To explain: when you fire up the browser it opens either to a specific window size (mine) or whatever size it was when last closed (most everyone else). For browsing news sites I prefer a portrait window of 1200x1200 pixels, but for videos I prefer the more normal widescreen format. With a browser it is not simple to achieve that without a certain amount of irritation, whereas with distinct and separate apps it's a non-issue.

That's not to mention other stuff like being able to kill with prejudice one app and not affect any other - tricky when they all use the same browser engine. Oh! I did mention it... oh well

[Nominal Animal]

With a browser it is not simple to achieve that without a certain amount of irritation, whereas with distinct and separate apps it's a non-issue.

True.  Separate profiles for each browser-based application could be a solution, though.  (It'd require one to create a desktop shortcut, naming the profile and the local HTML file to be opened.)

That's not to mention other stuff like being able to kill with prejudice one app and not affect any other - tricky when they all use the same browser engine.

I currently use Firefox 134.0 in Linux on x86-64, and it runs each window in a separate process.  I can always kill an app by closing that window, although if really stuck it can take up to ten seconds for the browser engine to notice and let me kill the process.

Again, a separate profile, with a separate independent browser process group per profile, would solve this.

Granted, it is a pain to create and manage those profiles, and not all browsers actually support multiple concurrent profiles this way.

Browser-based tools are obviously not a perfect solution!  The other one I personally would consider is Python 3 (3.8.20 or earlier, for maximal Windows compatibility) with Qt 5.  It has its own downsides, from not-exactly-native widgets and its own look-and-feel, to difficulty of installing and maintaining library dependencies on some OSes.  (In Linux, it is not a problem at all, because of KDE (desktop environment based on Qt), and all distributions with a graphical desktop having native packages for Python 3 and Qt 5 with PyQt5 or PySide2 Python bindings.)

There are many valid reasons to dislike browser-based tools, but still, I think one should actually check them out first before ruling them out for purposes like this.  (Specifically, I'm envisioning a way of sending your grandma or other not-so-technical relative a browseable tagged picture album on an USB stick.  I can make it as easy as "plug it in, wait for the window to open, then double-click on the icon that says "index" or "index.html" below it.  The same can easily be put online.)

[Analog Kid]

As the user moves, deletes and renames (picture) files, the database will no longer match the filesystem.

The only reliable solution for that is to add the tags into the files themselves.

Absolutely a no-go for me. I don't want any apps messing with my image files unless I explicitly command them to do so!

There are libraries in various languages that provide an uniform simplified interface across various filesystem monitoring approaches in different OSes (inotify/fanotify in Linux/Android, fsevent in macOS, kqueue in BSDs, ReadDirectoryChangesW in Windows), but the entire approach suffers from the simple fact that moves and renames are rare compared to additions and new image creation via file editing (think resizing and such).

Also note that it would have to be running all the time, too, and monitor all events involving the image folder(s) whenever the computer is running.  The run-time overhead would be small, but not neglible!

I think you should seriously reconsider what you expect from this kind of an application, and whether you really want an always-running service consuming resources on your workstation(s).

True, it would have to be running pretty much all the time (as an auto-starting "silent" process), and it would take some resources, but hardly any from the little testing I've done; it would basically be calling ReadDirectoryChanges() in an endless loop, and this function takes almost zero CPU cycles and very little memory while it's waiting for something to happen with the file system.

(This is under Windows; I don't care about any other OSs like Linux.)

[abeyer]

With a browser it is not simple to achieve that without a certain amount of irritation, whereas with distinct and separate apps it's a non-issue.

True.  Separate profiles for each browser-based application could be a solution, though.  (It'd require one to create a desktop shortcut, naming the profile and the local HTML file to be opened.)

I don't think you even need a profile... in chrome if you do the "Install page as app" option, it creates the shortcut for you and automatically tracks things like window size/position separately for the app than for vanilla chrome windows.

[tooki]

As the user moves, deletes and renames (picture) files, the database will no longer match the filesystem.

The only reliable solution for that is to add the tags into the files themselves.

There are libraries in various languages that provide an uniform simplified interface across various filesystem monitoring approaches in different OSes (inotify/fanotify in Linux/Android, fsevent in macOS, kqueue in BSDs, ReadDirectoryChangesW in Windows), but the entire approach suffers from the simple fact that moves and renames are rare compared to additions and new image creation via file editing (think resizing and such).

Also note that it would have to be running all the time, too, and monitor all events involving the image folder(s) whenever the computer is running.  The run-time overhead would be small, but not neglible!

I can’t speak to the other OSes, but in macOS, the whole point of FSevents is to not need to constantly check for changes, but to have the filesystem issue events when changes happen — and that includes files being added to or created inside the watched directories. macOS uses fsevents for numerous things itself*, so it’s always running anyway, and from using fseventer (a utility to visualize filesystem changes in real time) the overhead is tiny. (As I understand it, a program essentially “subscribes” to changes within a given scope. FSevents only tracks that anything in a directory (including metadata) has changed, but not what the changes are. So if the FSevents log says that a directory changed, you still need to go back and see what changed.)

For real-time interception of file accesses, macOS also uses kqueue, since it is a BSD.

*one of the biggest uses is Time Machine: it uses FSevents to keep track of all the directories that have changed since the last backup, so it doesn’t need to scan the whole disk for differences, just those directories.

[Nominal Animal]

in macOS, the whole point of FSevents is to not need to constantly check for changes, but to have the filesystem issue events when changes happen — and that includes files being added to or created inside the watched directories.

That is exactly what inotify/fanotify in Linux and kqueue in BSDs do/are used for.  inotify does not allow interception. fanotify supports open()-time interception, either allowing or denying the open to proceed as-is.  For full interception and examination of filesystem operations in Linux, one must use either the audit subsystem or a seccomp filter in all intercepted processes.  At the library level, interposing fopen()/open()/openat()/creat() etc. in dynamically linked processes is also possible.  For individual files, the owner user (or sufficiently privileged user) can place an exclusive lease on any local file (will not work over NFS etc.), so that any other process opening the file will be blocked while a signal is delivered to the lease owner.  There is a time limit, during which the lease owner can release or degrade the lease, but there is a time limit (on the order of seconds to a minute, typically) after which the kernel allows the open to proceed.  It is not possible to replace the inode to be opened this way, because the block occurs only after the opener gets a reference to the inode.  The lease also does not block any other process from hardlinking some other inode over the same filename, i.e. replacing the entire file/inode with another.

It is only Windows that requires polling to detect changes have occurred.

In Linux, the CLOSE_WRITE inotify/fanotify event is particularly useful, because it indicates that a process that had a file open for write has now closed it (with the event even naming the entry in the watched directory).

[PlainName]

It is only Windows that requires polling to detect changes have occurred.

Long time since I did low level Windows stuff, but literally 5 seconds on t'web brought up this:

https://learn.microsoft.com/en-us/windows/win32/fileio/obtaining-directory-change-notifications

An application can monitor the contents of a directory and its subdirectories by using change notifications. Waiting for a change notification is similar to having a read operation pending against a directory and, if necessary, its subdirectories. When something changes within the directory being watched, the read operation is completed.

I reckon that's waiting for an event rather than polling.

(And this is just the first hit in my search - there are equivalents for files, discs, etc.)

[tooki]

It is only Windows that requires polling to detect changes have occurred.

I’m pretty sure that’s incorrect, actually. https://learn.microsoft.com/en-us/windows/win32/fileio/obtaining-directory-change-notifications?redirectedfrom=MSDN

One thing I have realized over the years is that Windows actually can do a lot of things, but that for some reason, a ton of Windows developers simply aren’t aware of those APIs or calls, so they don’t use them, and instead either go without or write some nasty hack.

For example, Windows developers have the habit of saving paths (whether absolute or relative) to files, rather than saving shortcut data. Consequently, practically all software on Windows loses track of files if they’re moved or renamed. For years I assumed this was because Windows simply lacked the API calls. (And before Win XP, I believe it did.) Then (years ago on either Vista or 7) I was rearranging stuff on my work PC, including moving or renaming my iTunes media folder. I assumed I’d need to re-target iTunes, so I opened its preferences, only to discover it had already updated on its own. I did a bit of research and discovered that the Windows Distributed Link Tracking (DLT) service is designed just for this type of thing: when you first create or open a file, you ask Windows for a an object ID, and you save that instead of (or in addition to) the path. I vaguely recall there was also a way to do this using the shortcuts API, since shortcuts contain paths, DLT object ID, and more. Then you use the DLT or shortcuts API to resolve the file’s current location when you need to use it. The DLT service can track a file even if moved from one disk to another, sometimes even across servers.

Again, this was my work PC — at my job at a software company that developed a Windows application. File paths were a huge source of support calls, so I asked the lead developer if there’s a reason we didn’t use DLT. Blank stare. He’d never heard of it. Neither had any of the other devs. And it’s not like it was anything new, that API was many years old by then.


This also relates to one of the little things that continues to annoy the hell out of me on Windows: the inability to move or rename an open document. On the Mac, provided you’re staying within the same volume (partition), you can move or rename a file while it’s open, and most applications silently update the title in the document window and merrily continue on. This even works on the Mac version of Microsoft Office. On Windows, depending on whether the application set a file lock or not, it either doesn’t let you move/rename the file, or it lets you but the application doesn’t realize, and then either malfunctions or saves another copy of the file under the old path and name… 

[Nominal Animal]

It is only Windows that requires polling to detect changes have occurred.

I reckon [FindFirstChangeNotificationA is] waiting for an event rather than polling.

Sure, but I was referring to the cross-platform compatibility libraries.  The ones I've looked at specifically mention ReadDirectoryChangesW and polling in Windows, and inotify/fanotify/kprobes/fsevents (and thus notifications) on other OSes.

My underlying point is that when one wants to write a proper application, they may need to choose between Windows and non-Windows portability, because the libraries providing portable abstractions make some serious compromises and simplifications.

(I find especially portable serial libraries to have unacceptably poor Linux implementations, as they usually follow Windows paradigm, and do not and cannot properly map stuff to termios.  Plus, they typically assume untrue things in POSIX, like "short reads and writes never happen" (often as "writes are atomic and never short, as long as I don't try to write too much at once"), because that may be true in Windows.  Sure, they work for most users most of the time, but that just isn't sufficient to me: I need reliability, at least the library/abstraction layer to reliably report any errors and issues to my own code, not ignore them as "improbable".)

If you really wanted an OS independent abstraction, you'd have to start from scratch, creating an abstraction that does not start from anything existing in particular to map to, and instead handles the full capabilities of all OSes.  The end result is something like the browser environment in JavaScript –– and as discussed, some have pretty strong prejudices against that.

[PlainName]

If you really wanted an OS independent abstraction, ...

As an end user, I would much prefer a native application. Something that fits all destination is bound to be compromised, and why would I put up with that when I only want to use it on my system? That would be like having to use a tractor to blat down the motorway because some roads are quite rutted and muddy and it's a fit-all vehicle.

[Nominal Animal]

If you really wanted an OS independent abstraction, ...

As an end user, I would much prefer a native application.

Sure, why not?

However, I already explained that if I were to create something like this myself, I would want it to be portable simply because I'd expect I'd be sending such tagged albums to relatives and friends, or perhaps put them online.

That is, for this particular case, tagged and searchable photo albums, portability across OSes seems a desirable feature.

Unless, of course, you're one of those "everyone uses Windows, and if they don't, they should" religious zealots.

[PlainName]

Unless, of course, you're one of those "everyone uses Windows, and if they don't, they should" religious zealots.

AIUI, nearly 'everyone' does use Windows (more or less) but it tends to be the non-Windows ones that might be recognised as zealots. Personally I don't really care so long as I don't get preached at for my choice

You want zealots? Check out the W10 anti-7 fanbois on Steam.

(OK, some contradiction there, but Steam is a small niche in comparison to an OS user base.)

[Nominal Animal]

AIUI, nearly 'everyone' does use Windows (more or less) but it tends to be the non-Windows ones that might be recognised as zealots.

Ah.  So, if I don't use Windows, I'm recognized as a zealot.  Therefore, portability outside non-Windows is zealotry, and completely unnecessary.  Got it.

[PlainName]

AIUI, nearly 'everyone' does use Windows (more or less) but it tends to be the non-Windows ones that might be recognised as zealots.

Ah.  So, if I don't use Windows, I'm recognized as a zealot.  Therefore, portability outside non-Windows is zealotry, and completely unnecessary.  Got it.

Don't be daft. That's not at all what I wrote. And don't forget that you wrote:

Unless, of course, you're one of those "everyone uses Windows, and if they don't, they should" religious zealots.

I could easily have done what you've just done and taken that as meaning you're saying I'm a zealot.

Read the damn thing again, why don't you. To paraphrase, I wrote that of the zealots, they tend to be non-windows users. That IS NOT in any shape or form saying that all non-windows users, never mind you specifically, are zealots. Sheesh.

[SiliconWizard]

 

Anyway, I would have thought that adding searchable tags to photos was a pretty basic feature that has probably existed for a couple decades even just using a "native" file explorer?

[Nominal Animal]

To paraphrase, I wrote that of the zealots, they tend to be non-windows users. That IS NOT in any shape or form saying that all non-windows users, never mind you specifically, are zealots. Sheesh.

In my experience, most zealots are Windows users shouting that everybody else should be using Windows, too, or at least write their code to be Windows-compatible, because "everyone uses Windows, sheesh!".

I always seem to have to explain why I have to limit some solutions to POSIXy systems –– so not any particular OS, not even Linux; I much prefer to be portable between Linux and BSDs in particular ––, but the exact reason, portability libraries being not good enough due to the compromises they have to make, is often rejected with "then use Windows like everybody else does! Sheesh!".

And then, when I do suggest a portable solution (like a browser-based tool), I get that "I want a native application instead." followed by "Better make it a Windows application, because everyone uses Windows, right?".  No, not right.

So, no "sheesh", just a completely different experience.  I might be a bit fed up by Windows users calling me a zealot for not using Windows, mind you.  It's like watching middle age villagers milling about with pitchforks and torches from a window, shouting at me how violent a mob I am.

[PlainName]

In my experience, most zealots are Windows users shouting that everybody else should be using Windows, too

Well let's not get too hung on this.

On this specific point I can't remember the last time I saw someone asking how to do something in Linux, or for advice on Linux, and someone else saying forget that and just use Windows. I don't recall seeing anyone jump into a Linux thread and say, out of the blue, just use Windows. In fact, I'd spill my coffee on my keyboard laughing. OTOH, I do see that kind of thing quite often from Linux (assumed) users. Perhaps it's just that I use Windows so don't have a massive interest in perusing Linux-specific forums, though I don't shy away from Linux info if it crops up. Perhaps that's the same for you - you inhabit the Linux universe more so tend to see and notice contrary stuff.

So long as neither of us are being zealots I don't see a problem.

[PlainName]

when I do suggest a portable solution (like a browser-based tool), I get that "I want a native application instead."

OK, this thing. I really don't see why one is castigated for not wanting to compromise one's experience. Given a nice-looking app and one with the exact same function but a poor GUI, why is it a crime to prefer the nice one? Actually, that's not the crime - it seems the issue is with merely voicing that preference.

I understand that as a developer you want to make things once rather than half a dozen times in different ways. There is no problem with that and, were I attempting to create a multi-platform app I might do the same. But my comment wasn't about being a developer and purely about being the end user. So, if a non-native app cannot use specific features of my PC, why can't I say that I would prefer an app that does use those features?

[Edit: sorry, missed a bit]
I think you're conflating things on this. On the one hand I said I don't like browser-based applications and then, for a completely different reason and context, I said I prefer a native app. You've tied those together and then thrown a strop on that basis, whereas they are in fact different things and unrelated.

For the web app thing, it was about the preferences for one app being used for another, and I gave an example. That absolutely isn't about browser vs native - I just used a native app (PDF editor) and have the exact same issue with that. If it's set up for copy editing it is wrong for general viewing, and it's so annoying that I actually use a worse (to me) pdf viewer just so I'm not continually using the wrong preference!

For the native app thing, it was about waits vs polling. Nothing whatever to do with browsers and everything to do with application frameworks.

[Analog Kid]

Just to further clarify one thing, the Win32 function I experimented with to detect file system changes, ReadDirectoryChangesW(), can be used either in synchronous mode (= polling) or asynchronous mode (= listening). In either case it seems to use very few system resources, so should have little impact on system performance.

[Nominal Animal]

when I do suggest a portable solution (like a browser-based tool), I get that "I want a native application instead."

OK, this thing. I really don't see why one is castigated for not wanting to compromise one's experience. Given a nice-looking app and one with the exact same function but a poor GUI, why is it a crime to prefer the nice one?

Have you taken a look at EasyEDA?  Its GUI is arguably easier and nicer-looking than any other electronic circuit design tool producing classic-format schematics and Gerbers, at least from a hobbyist or new-user perspective.  Just because it runs in a browser, does not mean it has to be poor or non-nice-looking.

The ugliness of my examples (glyphs, FIR analysis) is purely a choice: they're just examples, focusing on showing the functionality and possibilities, not how nice-looking you can make things in a web browser.  I'd need the help of an UX specialist or graphics designer to make it genuinely nice-looking, because I'm a decade out of date on what is considered "nice".  My own preferences tend to what I show on my home page, using the very same technique (it's all contained in that single 21749-byte file); I have thought about making Tux' eyes follow the mouse cursor (á la xeyes), but have thus far resisted the temptation.

My browser-based examples do not use any libraries or application frameworks, either, because their purpose is to show how easily one can get going, and how lightweight such solutions can be.  I use EasyEDA for an example of how nice-looking they can be – but note, just as an example.  I'm sure there are even better examples out there, I just haven't encountered them yet.  Also note that the classic EasyEDA does not require any specific browser, either.

I understand that as a developer you want to make things once rather than half a dozen times in different ways.

Oh, no.  The reason for me focusing on portability was exactly because I envisioned providing the albums here to other, non-technical users.

My own development practice is such that I test and collect "modules", algorithms and approaches, implementing and testing them in isolation; currently each one in their own folder, with a README file, and if math is involved, some documentation and Maxima worksheets to replicate the math. (I've got thousands of these.)

I've found that rather than make them library-like, I get a much better result by adapting a known-working solution I've experimented with, than using one as-is.  (Also, I nowadays tend to think the operation through first, then examine the hardest-to-implement details in this "module"/"unit" fashion, before I start creating the application itself.)

Thus, portability itself is not a goal for me in general.  Is only one tool among many for me.  It is like software licenses to me: I use the entire range from CC0-1.0/Public Domain to GPL to completely proprietary, and have even signed some NDAs.  Also, I often rewrite my code to adapt it to new use cases, so I'm definitely not the type to write stuff only once!

In my opinion, after having implemented such tagged image galleries (and image analysis and commenting tools) for public use, and therefore claiming I have actual practical experience on this (anyone can contact me with a PM for details of projects), I do believe that either such an application should either be "online" (not "cloud", but easily hosted on your own web services, including uploading the images there; the security and running costs of such being the critical/questionable part), or portable across operating systems, so as to not limit the users that can access the album/database.

As an example, my elderly mom uses an Android tablet, and although she's an avid picture-taker, she'd be extremely upset if she got an album she cannot view or fully use because it is Windows-only/macOS-only/non-Android and/or requires a paid program to view.  I, as one half of her unofficial IT support staff, would get the heat.

As to filesystem monitoring for auto-detecting changes in file names:

You do hopefully understand that that is no longer an application; it is a service that has to run all the time for it to be able to do such tracking.  Filesystem events are not recorded anywhere, they are only reported as they occur.  That is, there is no log you could read that would tell you the operations done since Yesterday for example, or the last time this application was running.  Such a service should of course be native, for both efficiency and simplicity.  I do not believe browsers are even able to do this yet, anyhow, lacking interfaces to the OS-specific filesystem monitoring facilities except for polling using the FileSystem browser API.  To be clear: I would definitely not implement such a service in a browser!

Anyway, a solution suggestion:

Since we have (I believe!) already agreed that the biggest issue in this kind of application type is the tagging of the images –– editing the metadata associated with each image ––, why not solve the problem by using an approach that allows compatible implementations as a native service, a native application especially for easy tagging of new images, and a browser-based portable viewer?

I'd say the service approach might be warranted for an user who uses that particular machine in large part for maintaining albums and image archives.  A native application would be needed to interface to the service, and to act as a control panel of sorts to the service –– for example, to select which folder trees it will monitor.

Because of the limitations of the browser approach, tagging images would be best done in a native application.  It is possible to do the same in a browser-based tool, but the interfaces for accessing local files are still limited, would probably feel cumbersome.

If the image metadata, tag definitions and per-image tags and image descriptions, are stored in a format that one can read from a service, native application, or a browser, there is no limitation to how one implements the application part.  Browsers are a bit limited in this front, so it would have to be either plain text, JSON, or an easily parsed plain-text format like S-expressions, CSV, PSV, etc.  While plain text formats are verbose, even if it grew to an average of 1k per image, it would still be extremely fast to process, and the size is irrelevant compared to the size of the image files it describes, so although this is definitely a compromise (compared to e.g. an SQLite database file), I believe it to be an acceptable one, considering the implemenation freedom this compromise provides.  Of these, JSON (using UTF-8 encoding) is probably currently the best option, considering both browser support, library/application support, and ease of implementing your own from scratch, as it is a proper standardized interchange format (see the link).

In other words, each album or image database would then be a single JSON file, plus a set of image files at relative paths (typically in same folder or in a subfolder).  The JSON file would describe the album itself, the tags used, plus have a list of image objects, each specifying at least one image file (if more are specified, they should be the same image in different sizes), the tags that apply to it, and optionally a title, date-time, license, and a description.

If one is interested in this approach, the next step would be to consider the implementation of the database JSON file.  Although I normally prefer long descriptive field names, for the per-image ones I would use short ones to minimize file size overhead.  For the tags, I would use a list of strings per image: although compression via lookup (as in replacing each tag string with an identifier) can reduce the file size, I do not believe it would be worth the added complexity considering how much larger in file size each image is.  KISS.

Personally, I'd take a look at the database schema of existing open source solutions, then sketch out the target one, which I'd put out for suggestions and comments.  For example, it might (but I'm not certain) be useful to split tags into say contents and context.  Contents would contain tags that apply to what is visible in the image; context to why or how the picture was taken or by whom.

[Analog Kid]

As to filesystem monitoring for auto-detecting changes in file names:

You do hopefully understand that that is no longer an application; it is a service that has to run all the time for it to be able to do such tracking.  Filesystem events are not recorded anywhere, they are only reported as they occur.  That is, there is no log you could read that would tell you the operations done since Yesterday for example, or the last time this application was running.  Such a service should of course be native, for both efficiency and simplicity.  I do not believe browsers are even able to do this yet, anyhow, lacking interfaces to the OS-specific filesystem monitoring facilities except for polling using the FileSystem browser API.  To be clear: I would definitely not implement such a service in a browser!

Nor would I (since I don't like the browser-based approach in the first place).
In my vision of how this would work (under Windows), the filesystem monitoring process would run in the background all the time. Probably the easiest way to link this to the photo viewing and tagging app would be through a log file. None of this is rocket surgery.

And in the absence of such a monitoring process, the app could drop back to a "dumb" mode where it simply says "too bad" if it can't find a file that it expects to see at a certain place on disk. Wouldn't be the end of the world for the user.

[Nominal Animal]

In my vision of how this would work (under Windows), the filesystem monitoring process would run in the background all the time. Probably the easiest way to link this to the photo viewing and tagging app would be through a log file. None of this is rocket surgery.

Yup; similarly for user desktop sessions in Linux, Android, macOS, BSDs.  (I mean, a native service or auto-started panel app/tool on each OS, not a portable one.)

This does not change the fact that each image database or album should still have their own "database file".  I do recommend JSON format for the reasons I outlined; the likely larger file size (compared to e.g. SQLite database) is irrelevant compared to typical image file sizes, as the metadata will be only a small fraction of the image file size anyway.

And that approach would allow any implementation, even in parallel.  That is, you could have the service running on your machine tracking image file moves and renames, a native tag editor application, and a browser-based viewer in use all at the same time, no problem.  Or just a subset, whichever you prefer.

I do insist on people thinking a bit more long-term on how this would be used, because it is horrible to find out later you've accidentally limited yourself to a solution you don't like, that feels too confining or gets difficult to maintain or cannot be used like you'd want to.

[Analog Kid]

This does not change the fact that each image database or album should still have their own "database file".  I do recommend JSON format for the reasons I outlined; the likely larger file size (compared to e.g. SQLite database) is irrelevant compared to typical image file sizes, as the metadata will be only a small fraction of the image file size anyway.

I would just roll my own database here.
Since it's basically just a "flat" database, not relational, it could be simply a list of structures, with heaps of strings pointed to by those structures (the pathnames to the picture files and the tags). Probably no need for any kind of hashing, since the total number of files might be ... high, but not astronomical.

[PlainName]

First, I appreciate the bulk of your comment and explanation for what I had misunderstood. I may not agree 100% with some bits but those aren't significant or warrant further comment. It's an example of why I nearly always like reading your output.

when I do suggest a portable solution (like a browser-based tool), I get that "I want a native application instead."

OK, this thing. I really don't see why one is castigated for not wanting to compromise one's experience. Given a nice-looking app and one with the exact same function but a poor GUI, why is it a crime to prefer the nice one?

Have you taken a look at EasyEDA?  Its GUI is arguably easier and nicer-looking than any other electronic circuit design tool producing classic-format schematics and Gerbers, at least from a hobbyist or new-user perspective.  Just because it runs in a browser, does not mean it has to be poor or non-nice-looking.

I think this is a 'not seeing the trees for the wood' issue. I chose, as an example looking nice because it's easy to envision, but it was only an example and it could have been some other function (perhaps need for a network connection or not, generating reams of log output or not, etc.). So concentrating on that specific example to refute means, I feel, the thrust of my point was missed.

[Nominal Animal]

I would just roll my own database here.
Since it's basically just a "flat" database, not relational, it could be simply a list of structures, with heaps of strings [...]

That's exactly what a JSON file is.  See the JSON syntax example at Wikipedia.

Of course, the "own database" here involves the structure and field names.  The key is to organize the structure and fields so that someone just wanting to browse the images can ignore any fields it doesn't recognize.  One can do this smart, or horribly stupidly.  In particular, you do not want sibling properties to modify each others behaviour or functionality, you want to encapsulate logical objects.

As an example, the image set should not be an associative object either arbitrarily keyed or keyed by the path to the image, but be a list of image objects, with each having properties like path, description, tags (a list of strings); with their keys perhaps shortened to a single letter to reduce the per-image-metadata overhead.

The tags used for image marking should probably also be listed, with a description for each one.  I'm not sure a flat list of tags is optimal, so perhaps each tag should be optionally expandable to sub-tags, so that if the parent one is selected, it includes all the child tags as well.

At runtime, the image tags can easily be indexed for extremely fast lookup/check.  For example, you could enumerate the images (in arbitrary order), then create a list for each tag, containing the image indexes in sorted order that the tag applies to.  The selection is then a simple union (or similar operations if you also allow the user to exclude images with a tag, and not just include them) of the selected tags' lists.  With M tags and N images, union on sorted lists is at most O(M N), with tens of tags on thousands of images found basically instantly even in JavaScript.  In C or C++, you might use a bitmap per image, one bit per tag, so it'd be even faster.  You won't really examine the tags as strings except when reading the database.

This is one of those things that one should design and test and document first, before actually implementing the applications.

I chose, as an example looking nice because it's easy to envision, but it was only an example and it could have been some other function (perhaps need for a network connection or not, generating reams of log output or not, etc.). So concentrating on that specific example to refute means, I feel, the thrust of my point was missed.

Hmm.. Indeed, I think I missed your point, now that I reread the thread to see exactly how things got to this point.

I do agree that while there are workarounds ("app mode", custom profiles) for your stated primary reason for disliking web apps, those workarounds have their own downsides.  Such dislikes are from experience, especially from not being able to adapt the tool to your preferred workflow, and I have absolutely zero issues with those.  Basically all applications I use, I tweak their settings and preferences to best fit my needs, and if I cannot, I prefer to use something else instead.  So, I definitely understand and accept your reasoning as fact, without any objections.

What I did not understand, is the categoric pushback.  See my response #33 to your comment, especially the final paragraph.  In #40, I clarify that "only in Windows is polling needed" is from looking at the documentation of various libraries providing cross-platform filesystem event detection, then elaborate further on when I personally choose non-portability.  And in #42, I try to emphasize that I'm only pushing for portability here because of the send-the-album-to-Grandma scenario.

Looking back, I suspect I got quite annoyed that even you did not acknowledge the to-Grandma scenario, and unfairly jumped to/presupposed the "even Grandma should be using Windows anyway" argument, which I seriously object to, and often have to rail against; thus I escalated things, unnecessarily.  It was NOT the "Windows" part, mind you; it is the entire "even Grandma should be using Foo anyway" sentiment, for any value of Foo, including Linux and macOS.  Choice of tools and interoperability is in my mind much more important and valuable than standardization of options.  Actually, I see standardization to a single set of tools dystopic, even if said set was "Linux".  I want everyone to have the option of optimizing their own workflow and usage scenarios, instead of being dictated to as to what tools and how they may use.  Any argument out of popularity, as in "everyone uses Y!", I find utterly inane, and tend to respond with a retort about the number of flies and the popularity of dung among said flies.

So, in all fairness, I think things escalated unnecessarily here because I was getting a bit too irate about the reasons for this thing to be portable being completely ignored by others discussing this.  I do apologize, but I do have a reason: One of the larger image/art-related projects I've done is today very difficult to access, as it was implemented on a CD-ROM using Macromedia Director 4.0 for Mac OS 7.5 back in 1996.  You ignore the practical need for image galleries and archives to be portable at your own peril.  Note: the applications and tools you use to manage said don't need to be portable, but viewing them kinda-sorta ought to be, in my opinion and experience.

[Analog Kid]

This [defining the database and other structures] is one of those things that one should design and test and document first, before actually implementing the applications.

I would reply with "Duh!" to this, but don't want to offend you.
Paper and pencil are my tools at this stage. I don't write a line of code until I have at least the basic data structures mapped out pretty well.

And writing documentation first: I don't always write it before coding, but that's a damn good thing to do. Follow your plan to create the code, rather than vice versa. Usually makes coding a hell of a lot easier.

[Nominal Animal]

Paper and pencil are my tools at this stage. I don't write a like of code until I have at least the basic data structures mapped out pretty well.

And writing documentation first: I don't always write it before coding, but that's a damn good thing to do. Follow your plan to create the code, rather than vice versa. Usually makes coding a hell of a lot easier.

Good to hear!  But, I definitely didn't mean you specifically, though; it's just that I see the world as chock full of code that is simply slapped together haphazardly until it compiles without any thought to its structure, design, or long-term maintenance, so I keep harping about proper engineering approaches in my posts.

There are so many useful algorithms and approaches out there, too.  For example, disjoint-set algorithm applied to a set of tags applied to a set of images would tell you how many isolated groups of images you have, each such group using a specific non-overlapping set of tags that no other group uses; might help with selecting associated images.  The aforementioned run-time optimization using per-tag lists of image identifiers is well suited for this, too.  A variant of certain maze-solving algorithms (breadth-first distance-solving) can be used to do a tag-based Six Degrees of Kevin Bacon variant – say, second degree being images that share tags with images sharing tags with the original image, optionally limiting to a subset of all tags.  Fun stuff, with our imagination –– and short-sightedness when doing the original design! –– as the only true limit.

[PlainName]

So, in all fairness, I think things escalated unnecessarily here...

It takes two to tango, as they say. Another one is "all's well that ends well". 

[kloetpatra]

I can totally recommend https://immich.app/ for that
It's open source and offers all features you would ever need. It uses CLIP neural network for auto tagging pictures. You also have face recognition for people and syncs with mobile devices.

[PlainName]

I think Immich doesn't do tags, which was a requirement here. But I just thought of Google mail which doesn't (now) do folders but instead relies on search. I wonder if there is a feature or way of using Immich which replaces the need for tags.

[kloetpatra]

I think Immich doesn't do tags, which was a requirement here. But I just thought of Google mail which doesn't (now) do folders but instead relies on search. I wonder if there is a feature or way of using Immich which replaces the need for tags.

Do some research or at least read my post before answering. Immich does auto tagging via neural network. In addition to that you can create manual tags as well. Just try the demo.

[PlainName]

Auto-tagging is not the same as manual tagging. It couldn't be.

[Analog Kid]

Yes, what does "auto-tag" tag, anyhow?
I mean, does it actually recognize objects in pictures, like trees, buses, motorcycles (starting to look like captchas here)?
If so, how trivial and unhelpful can you get?
"11,723 images have trees in them."

[Nominal Animal]

Some tags should definitely refer to the context that is not obvious from the image.  Like what was the situation where the image was taken ("Trip to Alps in 1993"), who took the image or with what ("Mike's pinhole camera"), and so on.

Discussing this with my elderly mom, I think one extremely useful feature would be the ability to add audio commentary about an image.  That audio track itself should have a description and possibly tags, of course.  This would allow us to record memories associated with the images, and pass those on to others.