Gee, I can't imagine how this could be solved.

Jeff, b7 is out as a core update (along with new texts.properties). I've made the layout of Settings-images less ugly now (more in line with your design, but with clearer pipeline)

BTW, I was curious about what would happen if I set the JPG Quality to 0%. Console dump, and the results are downright comical.

I'm thinking you might want to set a lower limit on all of the quality settings. Anything less than 50% is probably a bad idea*, but 25% isn't nearly as bad as I would have predicted. But 20% might be a rational lower limit.

In my tinkering, I've started to get a feel for how the AVIF tradeoffs work. You can get away with remarkably low quality settings if you're willing to give it a little more processing time. That's a good exchange - you have to endure the processing time only once, but you're rewarded with much smaller files.

ETA: I've gotten excellent results with AVIF Quality at a mere 30%, but with AVIF Speed at 8. Slow as can be, but great slide image quality. Indistinguishable from a JPG at 75%, but the file is one-third the size.

This also helps lightbox scripts behave smoothly, since the slide image file they're being asked to cough up is so much smaller. Noticeable on old PC's, like my 2019 vintage desktop (it's really time for an update - hell, I can afford it).

* But see my remarks about AVIF.

On quality percent: Yes, I should probably limit the lower setting to a more reasonable value, but when experimenting with image rebuild mechanisms, it's practical to sometimes set a really ugly setting, just so one can easily spot a difference.

On your AVIF experimentation: Love it when you dive into this territory . I'm fascinated myself on the ability to achieve both smaller file sizes and better quality by trading that for build time. Makes perfect sense for the "final" build of a jAlbum gallery.

Let's see if you can make sense of the pros and cons of the various encoders and decoders as well. I'm inclined to dump SVT_AV1 as it has stability issues (can crash the app under stress). Now I've labeled it as "Experimental" under Preferences. If we dump SVT_AV1 (which is really made for videos), then we save another 8MB disk space too

The word “closeups” has meaning only to skin developers, and even we rarely use it. Virtually everywhere, they’re called “scaled images” or “slide images.”

In fact, the word “closeup” implies that you’re zooming in on something. “I’m ready for my closeup, Mr. DeMille.” But you’re actually taking a large original and making it smaller.

Stick to “scaled images.” And the way we use that term, it doesn’t include thumbnails. Yes, they’re being processed, and things like the quality settings come into play, but users are usually paying attention only to the slide images.

But it’s all “output,” right? It all lands in the “output directory.”

Thinking like a developer again. It's all in the "output directory." There's "input" and there's "output." Everyone gets it. "Writing" is what you do with a pen.


Yes, I thought about that - tricky because the variants might include a mix of formats.

Why is the Variants tab green? It should be "danger red," of course.

Yes, felt hard to handle at first, but then it boiled down to this beautiful code (Java streams):

    boolean isUsingFormat(OutputFormat format) {
        return outputFormat.getSelectedItem() == format
                || thumbVariants.getModel().getVariants().stream().anyMatch(v -> v.getFormat() == format)
                || imageVariants.getModel().getVariants().stream().anyMatch(v -> v.getFormat() == format);
    }

v39 now released: See https://jalbum.net/software/release-notes