Author Topic: Searching For Photos Based On Tags  (Read 2437 times)

0 Members and 1 Guest are viewing this topic.

Online Analog Kid

  • Super Contributor
  • ***
  • Posts: 1373
  • Country: us
Re: Searching For Photos Based On Tags
« Reply #50 on: January 19, 2025, 07:01:49 pm »
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.
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 7321
  • Country: fi
    • My home page and email address
Re: Searching For Photos Based On Tags
« Reply #51 on: January 19, 2025, 10:13:28 pm »
Quote
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.
« Last Edit: January 19, 2025, 10:15:19 pm by Nominal Animal »
 

Online Analog Kid

  • Super Contributor
  • ***
  • Posts: 1373
  • Country: us
Re: Searching For Photos Based On Tags
« Reply #52 on: January 20, 2025, 12:25:53 am »
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.
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 7321
  • Country: fi
    • My home page and email address
Re: Searching For Photos Based On Tags
« Reply #53 on: January 20, 2025, 01:40:56 am »
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.
« Last Edit: January 20, 2025, 01:42:35 am by Nominal Animal »
 

Online Analog Kid

  • Super Contributor
  • ***
  • Posts: 1373
  • Country: us
Re: Searching For Photos Based On Tags
« Reply #54 on: January 20, 2025, 08:17:07 pm »
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.
 

Online PlainName

  • Super Contributor
  • ***
  • Posts: 7587
  • Country: va
Re: Searching For Photos Based On Tags
« Reply #55 on: January 20, 2025, 11:29:22 pm »
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.

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

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 7321
  • Country: fi
    • My home page and email address
Re: Searching For Photos Based On Tags
« Reply #56 on: January 21, 2025, 12:17:42 am »
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.
« Last Edit: January 21, 2025, 12:20:01 am by Nominal Animal »
 
The following users thanked this post: PlainName

Online Analog Kid

  • Super Contributor
  • ***
  • Posts: 1373
  • Country: us
Re: Searching For Photos Based On Tags
« Reply #57 on: January 21, 2025, 01:06:40 am »
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.
« Last Edit: January 21, 2025, 02:51:10 am by Analog Kid »
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 7321
  • Country: fi
    • My home page and email address
Re: Searching For Photos Based On Tags
« Reply #58 on: January 21, 2025, 01:31:33 am »
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.
« Last Edit: January 21, 2025, 01:33:11 am by Nominal Animal »
 

Online PlainName

  • Super Contributor
  • ***
  • Posts: 7587
  • Country: va
Re: Searching For Photos Based On Tags
« Reply #59 on: January 21, 2025, 08:49:11 am »
Quote
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".  :-+
 
The following users thanked this post: Nominal Animal

Offline kloetpatra

  • Contributor
  • Posts: 39
  • Country: de
Re: Searching For Photos Based On Tags
« Reply #60 on: January 21, 2025, 12:42:35 pm »
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.
 

Online PlainName

  • Super Contributor
  • ***
  • Posts: 7587
  • Country: va
Re: Searching For Photos Based On Tags
« Reply #61 on: January 21, 2025, 03:10:52 pm »
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.
 

Offline kloetpatra

  • Contributor
  • Posts: 39
  • Country: de
Re: Searching For Photos Based On Tags
« Reply #62 on: January 21, 2025, 06:57:53 pm »
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.
 

Online PlainName

  • Super Contributor
  • ***
  • Posts: 7587
  • Country: va
Re: Searching For Photos Based On Tags
« Reply #63 on: January 21, 2025, 07:50:38 pm »
Auto-tagging is not the same as manual tagging. It couldn't be.
 

Online Analog Kid

  • Super Contributor
  • ***
  • Posts: 1373
  • Country: us
Re: Searching For Photos Based On Tags
« Reply #64 on: January 21, 2025, 08:47:55 pm »
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."
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 7321
  • Country: fi
    • My home page and email address
Re: Searching For Photos Based On Tags
« Reply #65 on: January 22, 2025, 12:43:03 am »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf