[HN Gopher] Scoping a Local-First Image Archive
___________________________________________________________________
Scoping a Local-First Image Archive
Author : stog
Score : 22 points
Date : 2025-03-19 19:43 UTC (3 hours ago)
(HTM) web link (www.scottishstoater.com)
(TXT) w3m dump (www.scottishstoater.com)
| wlesieutre wrote:
| I remember a Mac app years ago that had nearly this exact same
| pitch, but stopped development because it wasn't making enough
| sales and the developer didn't want to pursue it just as a hobby
| project.
|
| Just now I found FlowVision which looks like a similar concept,
| but I don't think that was the one I'm thinking of.
|
| https://github.com/netdcy/FlowVision?tab=readme-ov-file
|
| Anybody know what app I'm trying to remember?
| stog wrote:
| I don't know the project you mentioned first, but it's a shame
| they stopped developing due to sales.
|
| FlowVision looks brilliant and an almost perfect client for my
| needs - thanks for sharing. It's a very similar concept to what
| I'm trying to acheive with my project but with mine I'm trying
| to focus on having the output suitable for archiving with no
| dependecies/app installs - all the user would need is a web
| browser.
|
| The idea is that as long as browsers are about, you (or anyone)
| can use the viewer. The general idea is that once it's built it
| would be put on an SSD or something and in years to come can be
| plugged in and viewed by clicking a .html file. Sticking to
| plain old HTML and CSS in the output has proved pretty resilent
| over the last 30 years.
|
| I'll be sticking the code on GitHub shortly under MIT and
| people can do what they want with it (hopefully make it faster,
| and more reliable without bloating it).
| kingo55 wrote:
| I love the idea of having access to your own personal data in
| plain formats like this. Just like with plain text note taking,
| and being able to run local AI models against your personal
| notes, I imagine one day running local AI models over your image
| data.
| pscanf wrote:
| Hurray for this approach! I want most software that works with my
| personal data to work like that. And I'm actually working on a
| hobby project to make it possible: a local database + platform to
| run "local" apps on it.
|
| I haven't gotten to implementing the data layer yet, but my idea
| was indeed to go for "simple files in folders". But I'm
| wondering, what format should I use for files containing
| structured data used by a specific app? For a photo app, using
| image formats is the obvious and easy choice. But what about, for
| example, a meal tracking app? What file format would you use to
| store nutrition facts about a certain food?
|
| My first thought is JSON, but that's not really user-friendly.
| For a non-technical user a JSON file is basically useless without
| the app that generated it. YAML is maybe a bit less cryptic for a
| non-technical user, but still mostly useless. A TXT with a
| specific, more user-friendly format? Then you risk the app
| breaking because the user changed its content. And still, as a
| user what would I do with a bunch of TXT files containing
| nutrition facts? Without the app that generated them, there's a
| high chance they become useless.
|
| My project also wants to solve that issue actually, ensuring that
| you always retain access to the apps that generated those files.
| But I would love to find a way to store data so that it keeps
| being useful and accessible even "app-less".
| clueless wrote:
| I've been thinking on working on something exactly like this for
| months and happy to see the work started here.
|
| The big thing I'd love to add is smarter llm based searching
| ability (using face-detection, lon/lat based location data
| extracted from photos, overall image description based on AI,
| etc) similar to how google photo does it.
|
| Now the question is, what local/small llm would be best for this?
| mentalgear wrote:
| Lo-fi for the win! Also markdown or JSON pairs nicely.
| creer wrote:
| > A plain text file (meta.md) can store optional metadata and is
| readable simply by opening it
|
| To me, "readable" is not enough. Entering this data-augmentation
| text is time consuming: it should be as easy as possible.
| Including "augmenting" in batches (for this photo and that one
| and these 200 others).
|
| Markdown in particular is not it - augmenting is not about
| presentation but about something like unstructured input of
| structured data. Or unstructured input of data which is
| systematic enough that it can be exploited by structured data
| retrieval. For example, "my finished art" or "my clothing
| inspiration" even when there is not strictly one way that these
| are tagged (yet).
|
| To me, this means that super-efficient input of "somewhat
| structured" data is the missing link. It's a user-interface issue
| (NOT database screens) and a data language issue (NOT json or
| markdown).
|
| By all means "AI" help is welcome - if it can be local.
___________________________________________________________________
(page generated 2025-03-19 23:01 UTC)