I’ve been taking photos lately. You can see them here.

I wasn’t satisfied with my flow for tagging, encoding, and deploying these to my site; so I wrote a houseplant program to help. If you’re interested, you can see the code here–but, fair warning, it’s only meant to be useful to me.

Digital photo development

When I’m developing a photo, I run through these steps:

1. I take a picture.

   The camera captures a RAW file with the image sensor data. The camera embeds metadata: the camera model, lens model, timestamp, F-stop and shutter speed, etc.

   This file has more data than we typically shunt around the web. My camera has 14 bits of resolution (sensitivity) in each color channel; most displays still only have 8 bits / channel of color resolution.

2. I develop the RAW file.

   Using Darktable, RAWPower, or some other software, ^{I process the photos. After triaging, I make choices like cropping, exposure, white balance…}

   For the photos that I’m happy with, I export a then export a developed image: a lossless 16-bit PNG. These are very large files–in some cases, >100MB.

3. I convert the photo for the web.

   The lossless, high-bit-depth image is good for archives; but for the web, I need something smaller, and without a “lossless” requirement. I transcode the image into a web-safe image in the WebP format.

   I also create scaled-down versions. The “featured image” I have in the articles list winds up being a lot smaller on your screen than the original; why bother sending the extra bits around?

   The web versions also need to have filtered metadata. I’d like to be able to GPS-tag my photos for my own usage; but I don’t want to put the coordinates of my backyard on my web site.

4. I write captions and alt-text for each image.

   These go into the album page; but I try to embed these as additional metadata fields in the image.

Motivating issues

Before writing phloto, my process was to do (1) with the camera, (2) with RAWPower, ^{(3) with Hugo’s image filters, and (4) in the text of the Hugo page.}

This process fell down in a couple places.

Portability

When I started doing more photography, I used Darktable for steps (2) and (4). It’s a really neat piece of software! It took me a while to understand Darktable’s flow; and even then I’m using a fraction if its power.

Even as I grew more comfortable using Darktable, I still found “open up the computer” to be a psychological barrier to doing image triage and editing. Using a computer for this task made “deal with photos” that much more like a job or a chore.

I wound up getting a refubished iPad, with the explicit goal of using it for photo processing on the go. It lives in my camera bag rather than at my desk. Unfortunately, an iPad can’t run Darktable.

Metadata loss

RAWPower and Nitro, in step (2), did not carry all metadata from the RAW file into the developed PNG. Only Darktable (of the software I’ve tried) allows editing the title and description metadata fields.

The most frustrating bit: Hugo sometimes silently fails to extract Exif metadata from PNG and WebP images. I can’t “just” pull the caption (title) and alt text (description) out of the image, even if I’ve set it. (I’ll file a bug to Hugo for this.)

Transcoding

I was using Hugo itself for step (3), which required putting the developed files into my Git repository. Remember, these are not yet compressed; one gallery can run to over a gigabyte of data!

Modern image compression techniques are very good at shrinking file size, but they are very CPU-intensive; ^{they take time. With two galleries, the rebuild took about four minutes. Even worse, I didn’t have Hugo caching set up properly, so just about every build was taking this long.}

phloto

I set out with these requirements:

• Web-based. The server should be accessible from my iPad, where I do the development (step 2), and from my computer where I make the final site change.

• Edit Exif title and description. I want to treat captions and alt-text as an “image” step, not as a “web” step.

• Transcode with filtered Exif metadata. I want to have my “public-safe” Exif tags set up-front, and have code that I’m in charge of do the filtering. I want to do the transcode approximately once, rather than spending redudnant CPU cycles.

phloto does the above. It’s a hodgepodge of untested glue between the hyper HTTP server, image and zenwebp codecs, and my fork of the kamadak-exif library.

It’s houseplant software, with no effort to be suitable for anyone other than me. So, y’know, don’t use it. But it does do some neat tricks; read on for some inspiration!

This image brought to you by phloto.

Nondestructive editing of metadata

Most RAW development software uses “nondestructive editing”: they don’t modify the RAW file, ever. Instead, they write a “sidecar” file (usually in the XMP format) that describes what modifications/interpretations to apply to the RAW data. The software can “replay” a RAW+XMP to get the developed file (PNG).

I wanted phloto to, similarly, treat the RAW and developed files as read-only. ^{But I didn’t want to deal with XMP, nor did I want to maintain a database (as Darktable does).}

phloto’s hack is to read back metadata, in priority order, from each of the three files:

1. an existing web file, if available
2. the developed image (PNG)
3. the RAW file

The highest-priority value is kept, i.e. the first value read in the above list. When I update metadata, phloto writes out a new web file–so the new value takes the highest priority.

Peeking at containers to avoid transcodes

In my initial implementation, phloto re-encoded every time the metadata changed. This was Not Great, as re-transcoding results in redundant work… and takes a long time!

Luckily (?) I wound up having a mostly-complete WebP parser from an earlier stage of the project. ^{Using that, phloto can open up the WebP container without actually decoding the image, replace only the Exif data, and write the updated file back.}

Now my problem is that updates are too fast–the visual feedback “I’m working on this update” disappears before I see it!

Note that an image can get re-transcoded if the developed file (PNG) is newer than the web file (WebP). If I want to go back and re-develop an image, I can still do that.

htmx is great

I’ve wanted to use htmx for a while, but I haven’t really had any projects that warrant it. Everything I’ve been doing has been either exclusively server-side or exclusively client-side. This was a nice opportunity to try it out!

htmx handles a couple things that make the interface snappy and interactive:

• The first time an image is loaded, phloto doesn’t have a web-friendly version of it. ^{phloto kicks off a background transcode… and via a little htmx, tells the browser to re-load the fragment of HTML around the image.}

  This is an htmx load poll. While the transcode is ongoing, the placeholder (and poll directive) remain in place. When the transcode is done, phloto serves a new HTML fragment, without the poll–and with a texual indicator, “webp”, that indicates the transcode is done.

• The metadata update runs through a form element handled by htmx. When the form submission completes, phloto serves back an HTML fragment that replaces the existing form, with data read back from the file that was written, giving a confirmation that the update is complete.

Future steps

I find myself confused as to whether the metadata is up to date, e.g. if I hit “submit”. I probably will want to add an indicator for this.

phloto could be a little snappier at listing the contents of large directories. Each listing of an album page has multiple “find and parse the sources for this image” calls; caching those would probably provide a good speedup.

I might want to expose metrics, e.g. “how many transcodes are in flight”.

There is the outstanding bug where Hugo is not able to read metadata from some files; I might need to fix this, if the issue lies with phloto or my webp editor. But I might bypass this, either by having phloto generate markdown sources (with alt-text and caption pre-filled), or by moving my site away from Hugo.

That said, phloto meets the requirements I was looking for. Other than a little styling, and optionally cleaning up some of the code organization, I don’t think there’s a much to add.