Leon Mika

I’ve been working on Blogging Tools on-and-off the last few weeks, mainly around images and image management. They’re not super exciting in their own right so I’d figure I’ll briefly write about them here.

The first major addition is the ability to save images to the server from the Image Tool app. There are some composition processors available and if one wanted to pre-process the image in some way, they would have to download the pre-processed image and upload it again for composition. This change will hopefully reduce the need for this back-and-forth. The download button has been replaced within the Image Tool app with a Save button, which will upload the processed image to the server.

Saved images can be recalled from the processor by using a new picker. This replaced the Load image by URL option, which I never really used (although I may add it back within the Saved Image app).

There is also a new Saved Images app which allows one to browse the saved image, file them into categories, and download them to the local file system.

Now those with keen eyes may notice the quality of the saved images in the screenshots above. That’s because the second change I made was to integrate calls to an image generator. There was no reason for doing this other than to try out the API, and I haven’t really used it for anything other than make test images. The API I’m using is Flux 1 provided by together.ai, but there’s also a partially-functional version of Gemini’s API too (the API is region locked and is not available in Germany, which is where Blogging Tools is running).

Saved Images are build on the existing Files subsystem, which has been relegated to a new Settings section, the third change I’ve made to Blogging Tools. This allows one to manage files, see running jobs, and managed sessions from the system. That section may expand in time as I think of things I’d want to change without redeploying the app (most of the config is managed using environment variables).

The last change was the addition of a new notification type. I’ve added photo collections to my blog a few months ago, but I never remember to actually file photos into any of them. My workflow with making a photo post usually ends at the point I hit “publish”, and as far as I can tell, there’s no way to set the category of the image from the new post screen.

So I’ve added a new notification type to help me with this. When the RSS feed of my blog is polled, and a new post with the “Photos” category is found, the first 4 images are extracted and presented as a notification asking if I want to file the photos into a photo category.

This also worked for posts you add to the “Photos” category via the notification subsystem itself. Both act on the same RSS feed and setting the category of a post to “Photos” will clear the fetch history of that item so that it can run through the processors again.

I’ve decided to use notifications for this, rather than add something to do this automatically, as I do want to go through the candidate photos first. But there are some limitations to this approach. For one, the notification system only allows one user selection per notification, making it impossible to add a photo to more than one collection. And to keep the number of notifications low, only the first 4 images are presented, with the rest being ignored. I have some ideas of how this could be improved in the future — probably by adding a separate app — but for now, I think I could live with taking corrective action manually.

One last think about this new category processor: it’s activated by a change to the RSS feed, but it scans for images using the original post retrieved from Micro.blog’s micropub API. The reason for that I’ve enabled the CDN option, and the image URLs which use the CDN do not work with the collections API. It took me a while before I figured this out, mainly because I wasn’t using a CDN on my test blog and that worked perfectly. Something to keep in mind for anyone else using this API.