Products > Programming
Searching For Photos Based On Tags
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.
--- Quote from: Nominal Animal on January 19, 2025, 10:13:28 pm ---
--- Quote from: PlainName on January 19, 2025, 09:59:53 am ---
--- Quote ---when I do suggest a portable solution (like a browser-based tool), I get that "I want a native application instead."
--- End quote ---
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?
--- End quote ---
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.
--- End quote ---
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:
--- Quote from: Analog Kid on January 20, 2025, 08:17:07 pm ---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 [...]
--- End quote ---
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.
--- Quote from: PlainName on January 20, 2025, 11:29:22 pm ---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.
--- End quote ---
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:
--- Quote from: Nominal Animal on January 21, 2025, 12:17:42 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.
--- End quote ---
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:
--- Quote from: Analog Kid on January 21, 2025, 01:06:40 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.
--- End quote ---
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:
--- Quote ---So, in all fairness, I think things escalated unnecessarily here...
--- End quote ---
It takes two to tango, as they say. Another one is "all's well that ends well". :-+
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version