jAlbum 39.1 – A native Mac experience

Using Mac? We’re super excited to present jAlbum 39.1 that integrates image management with Apple’s efficient libraries. (otherwise check out our release notes for what applies to everyone).

With v39.1, we’ve integrated Apple’s super fast (and color correct) image loading and scaling engine – Mac ImageIO and CoreGraphics, meaning that whatever image formats Mac Preview or Apple Photos load (50+ formats), jAlbum will too, and high quality image scaling is being offered at 6x the speed of the equivalent software scaler (Smooth – Lanczos).

Supported image formats

Here you can list, activate and deactivate individual formats (multi-selection works). Once you toggle a setting, it takes effect immediately. By default, Apple’s 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 in order to enjoy significantly faster and color correct loading of formats like RAW, TIFF or HEIC for instance. Here’s a comparison between our standard HEIC/HEIF reader and Apple’s equivalent:

Apart from being a bit more color “punchy”, Apple’s HEIC/HEIF loader loads thumbnails instantly and like the other readers, is generally faster. Here are some measurements:

Reading HEIF/HEIC: 4.6x faster
Reading WebP: 12x faster
Reading TIFF: 3.2x faster
Reading AVIF: 1.5x slower
Reading RAW (Nikon NEF): same speed
Reading RAW (Canon RAF): same speed

Although I didn’t measure higher speed loading RAW files, I’m sticking with Apple’s RAW readers anyway, for two reasons:

• I personally like the color correction Apple appiles
• With Apple’s image readers, the initial (expensive) image scaling is also performed in high quality by Apple’s efficient library, unloading CPU- and RAM intensive work from jAlbum’s side.

Should there be an issue with a specific format, just deselect it from the “Mac image readers” dialog. The RAW support is excellent, and applies Apple’s punchy color profile to your images, but should you prefer to do RAW color management within jAlbum (it’s sometimes faster), then just deselect the corresponding format.

Image scaling

The second area where this integration shines is with high quality image scaling. jAlbum’s “Smooth – Standard” scaler actually does a good job of balancing scaling speed and resulting quality but if you want top-notch quality at high speed, then you should switch image scaler to “Mac – CoreGraphics”. Under Settings -> Images -> Scaling. It’s equivalent to “Smooth – Lanczos” but 6x faster (and slightly slower than Smooth – Standard). Here are the recommended settings. Notice how we also recommend removing sharpening:

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.

More on image readers

There is also a “master switch” for jAlbum image readers to, for instance disable the Mac image reader, including all its formats, open Preferences->Advanced->Image readers:

You will usually need to restart jAlbum for changes here to take effect.

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. For a typical album build, it may look like this (top 10 lines):

                CustomScaler.scale:   108 calls      8,911s
        Writing: AVIF Image Writer:   142 calls      8,015s
             Scale to fit 1600x900:    34 calls      7,288s
              Scale to fit 800x400:    34 calls      6,225s
 Reading: jAlbum Mac Native Reader:    38 calls      3,277s
              Scale to fit 476x380:     3 calls      3,165s
              Scale to fit 400x200:    34 calls      0,903s
          AlbumBean.processFilters:   179 calls      0,504s
                              init:     1 calls      0,381s
 RotationSupport.adjustOrientation:    40 calls      0,289s

This also reveals what component(s) jAlbum was using for reading and writing image files.

I recommend you to compare v39 with v39.1 on a smaller project before applying settings to a huge project. The total speed will vary from 1x (same speed) to 6x depending on several factors:

• Whether your project contains file types Apple’s readers excel in (HEIC/HEIF, TIFF etc)
• Whether your project contains huge panoramics (v39.1 loads huge images much better now)
• With JPEG source images: Whether the largest image produced has a width or height bound that is n/8 of the source image’s width/height (where “n” is an even number between 1 and 7). This allows TurboJPEG to do the expensive initial scaling in a fast manner
• Whether you’re moving from slow scaling algorithms like Smooth – Lanczos (and all other smooth scalers but Smooth – Standard) to “Mac CoreGraphics” or not

Here’s a speed comparison, building a 38 image gallery of HEIC files where the scaling method is switched from “Smooth – Lanczos” to “Mac -CoreGraphics”:

Lower RAM usage

With jAlbum 39.1 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 until jAlbum quits, while native memory is freed as soon as it’s no longer used, allowing it to be used by other apps.

I let jAlbum process 38 HEIF files and 29 NEF (Nikon RAW) files. Here’s the result from v39 vs v39.1 with regards to RAM usage by Java:

v39:
Total: 1040 MB. Used: 305,45 MB
v39.1:
Total: 388 MB. Used: 99,82 MB

We’re basically down to 1/3 RAM usage now.

Let me know what jAlbum 39.1 delivers for you!