We recently gave our Mac version a boost by adding native image reading and scaling, meaning that jAlbum now reads and scales all formats that your Mac reads at the same quality and speed.

Now the time has come to Windows. The Windows equivalent is called WIC (Windows Imaging Component). It is generally not as optimised as Apple's equivalent, so don't expect too much, but some formats are surely faster now (for instance HEIC/HEIF, WebP and TIFF). The best part is probably if you're happy with Windows native code accelerated scaler as an alternative to Smooth - Lanczos for instance.

To control what readers to use, open Tools->Windows Image Readers... and tick the desired formats. Once ticked, they will have precedence over other readers.

To try out Windows-specific scalers, see Settings->Images->Scaling. That menu now has more Windows specific scaling options. We'll probably settle for "Windows Fant", but why don't you give them a try.

To see performance details, open jAlbum's system console and hit CTRL+P. You can reset the result by issuing: Profiler.instance.reset()

The Windows readers also does an initial scaling using native code. This helps to avoid having the Java side do the heavy initial scaling.

Installing:
Put https://jalbum.net/download/imageio-win.jaext inside jAlbum's "ext" folder and restart. You can toggle readers on/off under "Tools->Windows Image Readers..."

What do you think? The speed and quality varies between codecs. The JPEG codec is really fast, but doesn't beat our TurboJPEG, so I advice you to keep using TurboJPEG for JPEG reading.

Think I just answered my own question - yes, it does.

TurboJPEG is still the speed champ, by about 20%.

But using either Windows FANT, or dropping back to Smooth, I'm getting a console error for every image:

java.lang.reflect.InaccessibleObjectException: Unable to make field private java.io.RandomAccessFile javax.imageio.stream.FileImageInputStream.raf accessible: module java.desktop does not "opens javax.imageio.stream" to unnamed module @1534f01b

And my test album is now about 10% slower using TurboJPEG than it was before installing this extension and the 39.2.1 core. It works, however - I get an album. And it is, indeed, the extension that's throwing the errors, and slowing down the album build.

A wine not ready for drinking, I'm afraid.

Untick the jpeg boxes under tools - Windows Image Readers so this plugin doesn’t degrade JPEG loading speed. You can still use it for scaling.

Are you saying you get a speed degradation in spite of switching off JPG in the plugin?

That could happen in theory as installed image readers are sometimes queried if they support a certain bit stream, but I only measured around 4ms for that detection.
If you do a profile print within the system console it may tell you what the additional time comes from.

Removing the plugin is one way to guarantee full speed but you should also be able to inactivate all Windows readers, and thus cut off this reader from detecting if it supports a bit stream by unticking ”Windows Image Reader” under preferences - Advanced - Image readers.

I agree. The plan is to reduce the options, but allow more options in a beta like this so we can learn. I really had higher hopes for WIC when I started off, but it isn't generally of the same hardware accelerated quality as Apple's corresponding (Apple ImageIO).

That said, I'm curious if "Windows Fant" scaling is a good alternative to the software scalers (Smooth - Lanczos for instance)?

And things get even more crazy when one ventures into the image readers and writers in the Preferences settings. If a user asked me what boxes he should check off in those settings, I wouldn't have a clue about what to tell him. I have no earthly idea what practical effect any of them has. If you can't tell a user, in a sentence or two, why he should pick one option over another, the option is not doing anything useful for anyone. It's just frightening the horses.

I've been using this app for over 20 years, and have developed 16 different skins. If even I don't know what any of those settings is for....

If you want to broaden the appeal of jAlbum, I think it's time to stop catering to the "pixel peepers" out there. They're a tiny fraction of the user base, and they're usually just kidding themselves. I'd get rid of most of these obscure, inexplicable settings.

This is heresy, but I'd offer Fast and Smooth scaling, without any further refinements (like method). ETA: Maybe make Fast the equivalent of today's Medium. But just two choices.

Let the user adjust sharpening - it really does make a noticeable difference. Using different settings for an album of architectural photos vs. an album of faces is a good thing to do.

I'm not sure I'd even keep the quality settings. The pixel peepers push it up to 100% because it makes them feel good, but that's a foolish thing to do. In a double-blind test, none of them would be able to tell the difference, and they're just condemning themselves to slower build times, slower uploads, and slower page loading. Set it internally to 80%, and move on. Or keep the setting, but with a JComboBox that ranges from 65% to 85%. Tell users that going lower than that risks cranking out inferior images, and going higher is pointless.

Offer JPG or AVIF output. At this stage I don't have a good sense of how much difference the AVIF speed and quality settings make. It seems to be very dependent on the nature of the source images. But with even just two things to tinker with, the permutations and combinations spin out of control pretty quickly.

It already does warn you when you go over 90% for JPG quality (no similar warning for AVIF). But a setting that triggers a warning is a setting that shouldn't be allowed at all. (Including EXIF in the output falls into the same category - if this is a bad idea, why offer it as an option?)

If you make sure that you reset the quality to the new max when you load the project (rather than having it produce a non-working JSpinner - I've made that mistake!), they'll never notice. When they do, tell them it's like throwing an alcoholic out of the bar. He won't be happy about it, but it's for his own good.

ETA: Even better.... Let the user set it to 100%, but internally, just use a max of say, 85%. They'll never know the difference.

jpgQual = Math.min(85, jpgQual);