So, I've decided to change how I categorize my files.For those who haven't been following the blog, I have been using Hydrus to categorize my porn collection for a few months now. It worked alright, but now that I have a new laptop it's annoying to share files around, and it's also missing some features I want, so I decided to part ways.Instead I'm taking a filesystem first approach to the problem, and just outright including metadata with my files. This may seem inconvenient at first, but it opens up a lot of possibilities, and makes the whole collection a lot more robust.Now, at first I was hoping to do this by injecting metadata into the files themselves. This is mostly fine for the formats I handle (gif files can be converted to webp), and most other formats are fairly straight forward, but Matrioska is a bit annoying to work with, and then I also realized that embedding metadata within the files themselves would mean that sharing them would be a huge opsec issue.So, looking at the pros and cons of embedding data within the files themselves:Pros:- The data is tighly coupled with the file, and there's no risk of moving / copying the file without the dataCons:- Since I require custom fields, the files can be easily tracked to me if I share them- Changing the metadata involves rewriting the full file for most formats- A program which wants to read the metadata for a file has to load the file fully- I would have to rely on multiple decoder / encoder implementations for whatever languages I want to access my library fromThat's rough! So instead, I decided to give json sidecars a try. It may seem more annoying to move things around and keep them in sync, but a fairly simple toolchain can fix this issue. Furthermore, json sidecars have other advantages: you can use a sidecar to categorize an entire directory of files, for example, or have one to categorize a group.I will post the schema I'm thinking of using in my next post.
So, my metadata has the following fields (I won't post the actual data type bcause too many characters):- date- creator- title- collection (different types are supported, such as variants, sets and user albums)- medium / genre / style- source work (ip, series, and so on)- character / person- score- version- content rating (safe, nsfw, etc.)- language- tags- description- identifier (custom identifier)- ai_content (whether the content is AI generated)- ai_description (description so the AI knows what this file is)- usage tags- source (pairs of name and an optional URL)A lot of these things would typically be handled through tags in traditional software such as boorus or hydrus, but I've decided to make a lot of it its own fields instead, so I could control them better, and so I don't have to rely so much on tag namespacing. It also helps separate ubiquitous information such as character or media type so that it doesn't clutter the tags field.Worth noting that most of these fields are lists (even though only tags is plural), including things like collection and source, so there's a lot of versatility.What do you guys think? What fields would you add to something like this?
Your're an abomination
>>85565979What did I do (originalmente)? :(
