I’d like to be able to generate an imageboard/booru style gallery out of a folder full of photos+metadata, but I’m struggling to understand how I might do two steps:
1. Generate a globally available data set of images and metadata (tags, descriptions, attribution in some cases)
2. Generate list pages for tags to cluster together related or like images (every image with a tree, or two people, etc)
From (1) it should be easy to make pages for individual images and for further information about individual tags.
The data model has been difficult to understand and it’s not entirely clear what scopes different steps have and whether any sort of order is guaranteed. Is this possible within reason?
Okay, I can see someone was doing something very similar here: Image galleries based on "tags" stored in data file although I’m not able to tell whether each image has multiple tags or just one? Would this approach still work? Still a bit confused where the data ends up after it is ingested.
That’s a tall order for a simple answer. How far have you gotten setting this up in Hugo? Do you have a link to your repo so we can see the code and point to things?
If I do still have my code it wasn’t pushed to my public repo, unfortunately… I’m coming back to this after some time.
I got as far as loading images and sidecar files from assets/ into site.Data. My understanding was that a content adapter would be responsible for making individual pages for images. It was not clear at the time how one actually specifies where the image and term pages end up.
That said I should probably give it another shot so that I have something to point at, haha. I’ll come back when I have more specific questions.
I’m pondering how I’d accomplish this…
I need the keywords read out of the sidecar or embedded metadata from the photographs on each post. I don’t want to scrape that on every build, that would add up.
At home I yank them out of the jpg, export the exif.json for each file for displaying exif data.
If I wanted to see everything that had a specific lens in my photography, I’d probably try to build a keyword index, so each photo import we scan the json and those keywords are put into a data file in hugo.
{{ $index := site.Data.keywords }}
{{ range index $index "portrait" }}
{{ with site.GetPage . }}
...
{{ end }}
{{ end }}
I’m probably gonna do something with exiftool to extract my data and build my json to feed to hugo.
I can’t think of a way it would be done in a classic sense with #tags, not without exporting that out of the json with a script and up the the posts front-matter.
Tags live in the post, so you can’t make a keyword a “hugo” tag per-se. not without extracting it and making it a tag in front-matter. I might be way off the mark there.
Being able to use hugo taxonomies would be fun!
I took a second stab at it in a clean project here: aarqon/hugo-booru - hugo-booru - Gitea (personal git).
I can make pages for each image and list pages for each tag automatically with the content adapters. Helped for me to think about the content adapter as a script run in that scope and not a representation of a specific object like a markdown file might be. Think that tripped me up before.
My main concern with this naive approach is the nested loops in the content adapters. Surely there is either a smarter way to structure the data or a smarter way to build an index! I’m not opposed to a little Python pre-process if I need to digest a yaml or two.
The hurdle here is that frontmatter is static by design. So if you want to take advantage of hugo’s features and not go build your own content/listing page with the template system, you are limited to frontmatter.
You would need a script that runs before hugo build
- Walk
content/posts/**/exif.json
- Extract info from photo/sidecar/json.
- Insert derived tags into each post’s
index.md frontmatter