Using Windows? Now the time has come for Windows users to enjoy accelerated image loading and scaling just like our Mac users.
With v39.3, we’ve integrated Windows image loading and scaling engine (WIC), meaning that whatever image formats Windows loads, jAlbum will too, and high quality image scaling (“Windows HQ Cubic”) offers 5x faster scaling speed than the equivalent software scaler (Smooth – Lanczos).
Supported image formats
jAlbum now handles whatever image format your Windows OS handles. To control them, see Tools menu -> “Windows image readers…”.
Here you can list, activate and deactivate individual formats (multi-selection works). Once you toggle a setting, it takes effect immediately. By default, Windows image loaders will take care of loading all image formats except JPEG (here TurboJPEG still is 2x faster), so there’s nothing you need to do unless you bump into an issue with a specific format (If that happens, deselect that format and report the problem to us, passing along the problematic image).
We’ve measured 2x faster HEIC and RAW image loading by using Windows Image Readers.
We should also mention that with Windows Image Readers active, the initial scaling is done by the native “Windows HQ Cubic” scaler. This reduces RAM usage and is 5x faster than other high quality scalers, like “Smooth – Lanczos” (although not as fast as our “Smooth – Standard” scaler).
Image scaling
jAlbum’s “Smooth – Standard” scaler actually does a good job of balancing scaling speed and resulting quality but you may prefer the “Windows HQ Cubic” scaler for really challenging images.
The “Windows HQ Cubic” scaler is 2x times slower than “Smooth – Standard”, but several times faster than the other “Smooth” scalers (for instance 5x faster than Smooth – Lanczos”).
Don’t be put off by 2x slower: When combined with Windows image readers, the expensive initial scaling that usually takes 90% of the total scaling time is done by the image reader, also while Lanczos provides superior perceived sharpness by using a wide-windowed sinc function to enhance edge contrast, “Windows HQ Cubic” offers a more balanced, “critically damped” result that achieves high fidelity through an adaptive 4×4 bicubic kernel—effectively delivering a crisp, professional image that avoids the distracting “ringing” halos often introduced by the more mathematically aggressive Lanczos filter.
In short, if you’re using any of the “Smooth” scalers jAlbum provides, apart from the fast “Smooth – Standard”, move to “Windows HQ Cubic”.
Here are the recommended settings. Notice how we also recommend removing sharpening (not needed after running Windows HQ Cubic):
With smoother scaling and less sharpening, you can also expect slightly smaller galleries as both JPEG and AVIF (our typical output formats) both prefer smooth gradients.
Easier sign in and sign up
As you’re aware, many internet services today offer a fast track to sign in and sign up without the hassle of setting up yet another password and verifying your email address. You simply hit buttons like “Continue with Google” or “Continue with Apple”. We’ve now also added this convenience to jAlbum – as an alternative to the classic use of username + password. This applies to both our app and site.
Profiling for max performance
If you’re playing with various settings in order to achieve max album build performance, it may be helpful to see just where jAlbum spends its time. After an album build, you can open jAlbum’s System Console (F7) and just hit CTRL/CMD+P in order to print profiling info on the last album build to the system console.
Here are the results from building a gallery of 57 HEIC images. We’ll first show a pre-v39.3 build that scales using Smooth – Lanczos:
CustomScaler.scale: 169 calls 1m 17.927s
Reading: HEIC JDeli Image Reader: 88 calls 1m 14.406s
Scale to fit 1200x900: 55 calls 57.433s
Scale to fit 800x400: 55 calls 37.444s
Writing: AVIF Image Writer: 169 calls 15.354s
Scale to fit 476x380: 2 calls 2.412s
AlbumBean.registerVariables: 61 calls 1.765s
FileFilters.getBasicImageInfo: 59 calls 1.536s
Scale to fit 400x200: 55 calls 1.524s
RecoveryTool.createLifeboat: 1 calls 1.119s
...
Total build time: 1m 38.104sThis also reveals what component(s) jAlbum was using for reading and writing image files. Now let’s build the same gallery on v39.3 using Windows HEIC reader and HQ Cubic scaler:
Reading: jAlbum Windows Native Reader: 88 calls 45.65s
Writing: AVIF Image Writer: 169 calls 18.912s
WinImageScaler.scale: 114 calls 1.716s
Scale to fit 800x400: 55 calls 1.612s
RecoveryTool.createLifeboat: 1 calls 0.75s
AlbumBean.registerVariables: 61 calls 0.748s
AlbumObjectImpl.getXmpManager: 102 calls 0.704s
AlbumBean.makeIndexPages: 3 calls 0.694s
Make views: 1 calls 0.684s
FileFilters.getBasicImageInfo: 59 calls 0.528s
...
Total build time: 50.313sThat’s a 2x speed improvement! That said, we always recommend that you run your tests on a small project before applying the settings to a huge project.
Lower RAM usage
With jAlbum 39.3 you can also expect lower RAM usage as the RAM intensive image loading and scaling tasks are being performed in native memory instead of Java memory. Does this matter you may ask? Yes it does, cause the used Java memory isn’t released to the OS pool immediately after use while native memory is freed as soon as it’s no longer used, allowing it to be used by other apps.
For the sample project of 57 HEIC images above, the difference is like this with regards to RAM usage by Java:
pre v39.3:
Total: 548 MB. Used: 158.63 MB
v39.3:
Total: 320 MB. Used: 88.31 MB
We’re basically down to half the RAM usage now.
Read about all improvements in our release notes. Enjoy jAlbum 39.3!