Merry Christmas. jAlbum 26 is free!



Yes, it's true. For the first time in a decade we're offering jAlbum for free*.

Back in 2012, jAlbum went from freeware to be offered under a 30 day trial. This has worked out fairly well (hey, we’re still around...), but we think that people like you and I are far more positive to exploring software without time restrictions. (Just look at how most mobile Apps are made available for instance). In jAlbum 26, the time restriction is gone.




There are instead some functional limitations*, but not to the point of making jAlbum useless – You can make smaller sized galleries in 100 different designs straight out of the box AND download additional skins for even more designs. Here is how we think, our “business model” if you wish:

  1. Get as many people as possible to discover jAlbum and see it’s advantages: Integrity, customisable design and ease of use
  2. Offer additional functionality at a reasonable cost
  3. Offer web space for those that don’t have their own web hosting

The future will tell if this was our best or dumbest move ;-).

Merry Christmas everyone! Get jAlbum 26 today!

* Functional limitations of jAlbum Free:

  • There is a limit of max 24 images or videos per gallery.
  • Galleries can be customized through skin and style choices only. jAlbum’s settings window is “read-only”. (You can see what’s available, but it won’t affect the gallery).
  • Discrete “powered by” credit links are generated



How database-driven skins work

Simple web photo albums put all images (a.k.a thumbnails) on an HTML page and offer to view them in larger size either on the same page (dynamic) or on a separate “slide” page (static). However, when a gallery author wants to enrich the album with advanced functions – like search or tags – using a database will be unavoidable, because plain HTML pages cannot be used for storing data. Especially not for storing data of other folders.

The so-called SQL database is used the most often all over the web, in tandem with an appropriate database-management software (MySQL, MongoDB, or MariaDB) running on the server. Such databases require a server that is capable of running them – you can’t simply run such services on a PC. These databases also require regular maintenance and backup, which is something most content creators would like to avoid. Therefore we chose the middle ground for jAlbum album's lightweight services – the JSON database model (JavaScript Object Notation) – which does not require server-side database processing. Instead, the database is downloaded by the visitor's browser, and processed by the script running behind the page.

Currently the following skins utilize this JSON database: Tiger (default), Photoblogger, Projector and Story.


This database is generated by jAlbum when you hit Make album. Two versions are made: one that contains all the data of all the folders (deep-data.json), the other is made up of a bare-bones tree (tree.json) and several data1.json files – folder data – distributed over the folders. This allows skins to pick the most appropriate database(s) for the chosen features.

When you run a Make album, all these databases get updated, unless you turn ON Settings / Advanced / Process only updated directories. In this case, the database will get easily corrupted over time, where the tree points to missing folders or the next folder’s links get broken. That’s why we always suggest turning this feature OFF with database-driven skins. Recreating the database on each Make isn’t as a burden as running Make on a fresh album, and generating the scaled images – which I guess is the main motivation behind turning this feature on.

When you do manual uploads, e.g. using an external FTP application, you need to pay attention to updating the root folder’s tree.json and data1.json files besides the currently updated folder. (Naturally, the /res folder also needs to be updated after every skin update, but this is something you have to pay attention to with non-JSON skins too.)

Size matters

While the JSON database brings simplicity, it has disadvantages too. One is you can’t go beyond a certain limit without spoiling the user experience. In an album containing 50 000 images, the JSON database could easily grow as big as 50 MB, which takes some 4 seconds to download on a 100 Mbit/s line. There is an overhead time too while the browser recontructs the database in the memory. That’s not ideal. This is why these JSON-based skins try to mitigate the delay by loading the full database only when the visitor starts a search. On page load, they only load the folder tree (tree.json), and the current folder’s individual database (data1.json). The only function that requires the full database is tag cloud, but the album loads it only after the page composition has finished, in order to avoid delay.

Number of
Database size
/ using gzip
@100 Mbit/s
Processing time
(~20 000 obj/s)
Delay before the
search results appear
(first search only)
10 000 10 MB / 0.6 MB 0.8 s / 0.05 s 0.5 s 0.5–1.3 s
50 000 50 MB / 3 MB 4 s / 0.26 s 2.5 s 3–6 s
100 000 100 MB / 6 MB 8 s / 0.53 s 5 s 6–13 s
500 000 500 MB / 30 MB 40 s / 2.6 s 25 s 28–65 s

These figures depend on a lot of things – intended for comparison.

From this table you can see how important it is turning the server’s GZIP feature on in order to speed up the database in huge albums. A JSON database can be compressed down to 5-6% of its original size! I’d say above some 10-20 thousand images it is essential. If you are hosting albums with us – on – don’t worry, you’re already covered.

If you are using the Tag cloud feature, I’d suggest collecting tags only from the “Current folder” above some 20-30 thousand images, as collecting tags from the whole album might noticeably slow down page load.

Although the Search function doesn’t affect all visitors, those who run a search might face longer delays on very large albums or on a very slow connection. So you might want to turn off search in albums larger than, say, 200 000 images, as the results could appear only after 5-10 secs in the best case.

For the more curious

If you wonder how these databases are built up, you can install a JSON viewer browser extension – I use this for instance – and peek into the database by appending data1.json at the end of the URL or instead of index.html. Useful also in case your album gets broken, and you want to check out if the database looks fine. Here’s one example. (Don’t forget to install the viewer first, otherwise, it will look rather ugly. :) )

Your feedback is welcome,

Skin UI philosophy

You might ask, what is UI at all? UI is the acronym for User Interface, which sometimes we refer to as GUI too - “Graphical” UI. In this blog post, I will try to shed light on how my skins’ user interfaces are organized and why.

Individual settings

A skin’s UI contains all the settings that control how the album will look and what features it will have on the global level. Even though skins can allow some settings associated with individual images – like the Image data panel in Edit mode (see right) – the vast majority of skin settings apply to the whole album. Hence we call them “global settings”.

As skins evolve they receive more and more features, which disrupts the UI sooner or later. (You simply can’t put as many top-level tabs as the number of different features.) You can see this problem on Chameleon’s UI below.

Chameleon’s main menu (a relics from 2008 :))

A deeper structure will be necessary to accommodate everything: the layout-related settings, the features, behavior. Undeniably, it’s hard to pick the best organizing principle, and whatever you choose you will certainly end up poking around sometimes to find that special setting.

Tiger skin’s UI

In my skins, I chose the layout as the main organizing principle, the place where you can find a given feature in the final album. Adding instant previews to the UI, users got immediate feedback for many settings.

Use search to find any skin-related setting too.

jAlbum’s search functionality is also a great help. You just type in a few letters and jAlbum will show you all the related settings. Tiger skin also has a help system built around concepts in case you could not find a particular setting by its place. This helps in using my other skins too, as they are using the same (or similar) components.

As you can see, under the Site tab you’ll find all the generic settings, and those related to the index page, like the top bar, the hero (a.k.a header) and the footer.

The Sections tab has settings for the main content below the header, like the Images (thumbnails), the Folders - and you can even customize their order by dragging the sections around on the right “Ordering” panel. Useful when you want your custom page links below the thumbnails, or say want to have some custom content above the page content.

The Lightbox tab contains settings for the lightbox - you might’ve guessed :) - the large images. In the old times we called this “Slide page”, but as now we don’t have separate pages for these images in most skins, the word "Lightbox" fits better.

Finally, the Advanced tab has “advanced” settings, like Google Analytics or SEO optimization. You can also add "Custom code" here, e.g. custom CSS styles.

Note, actual (visible) page content should go into one of the custom content boxes: Site / Top bar / Custom content, Site / Footer / Custom content or the Sections / Custom section.

As different skins have different main layout features, the main menu might look slightly different:

Animatics skin tabs

Animatics skin’s extra features (e.g. Navigation, Map, Social, Background music) can be found under the Control bar tab.

Lucid skin tabs

... and the same is true for the Lucid skin.

Photoblogger skin tabs

In Photoblogger skin you have the main content (wide) column, and a side-bar (a narrower column). Typically, the main section contains the thumbnails, the folders, and all content that require wider space, meanwhile the majority of the functions (Tag cloud, Filtering, Map, Shopping cart, ...) go to the narrower side-bar.

Projector skin

Projector skin has a fixed side bar with all the control buttons and functions on the left.

Story skin

Story skin has a floating button bar that controls every function on the page. All related settings can be found under the Functions tab. In Story skin you can have the thumbnails mixed with folders and custom pages, therefore no Sections tab is used here. Instead, the settings for Folders and Images are placed on the Design tab, which also has an instant preview, so you can immediately see what some settings do.

We are aware jAlbum’s and its skins’ settings are sometimes hard to grasp. That’s why we are constantly improving the user interface based on user feedback.

Your ideas are welcome too,

jAlbum 25 - a time saver for power users

Many of our users regularly update their galleries. This is for you!

Being a desktop app, supporting folder hierarchies, jAlbum lends itself well to managing huge image volumes regularly. We see many users, especially organizations, update their galleries on a weekly basis. in v25 we’ve taken several steps aiming at making your life easier:

  • Image processing time cut down to half *
  • Albums can be made and uploaded in the background while you continue using jAlbum. (jAlbum can even make and upload simultaneously).
  • Albums can be automatically updated (made and uploaded) once changes are detected

* Measured on a full rebuild of an 80 image gallery consisting of 16MPixel images, Tiger skin

Faster image processing and lower RAM usage

The first thing you’ll probably notice is that jAlbum feels snappier when processing images. It also consumes less RAM memory, meaning that you can serve it 50Mpixel images without any hickups. We've achieved these improvements by only reading every 2:nd pixel from original images prior to scaling them. We’ve actually employed this technique before, if you’ve been using the "Medium" image scaling quality, but in jAlbum 25 we combine this technique with smooth scaling and we're being careful to only use it when the source image is significantly larger than the final image. Given this, we haven’t noticed any quality degradation in the generated images, but you will notice a faster jAlbum :-).

Background processing

If you’re as picky as I am, you’re probably doing several edit-make-upload cycles until you’re satisfied with your gallery or gallery update. It’s ironic how often we don't notice errors until we view the final result, isn't it? When doing repeated make- and upload cycles, you shouldn’t have to wait for a progress dialogue. jAlbum 25 has two background engines that make and upload your changes while you continue editing any project:

jalbum 25 background processing

There are three types of "tasks" that can be submitted for background processing:

  • Make – jAlbum makes an album out of a project: CTRL+M
  • Make + upload – The album is first made, then, on success, uploaded: CTRL+SHIFT+M
  • Upload – The album is uploaded to a previously uploaded location: CTRL+SHIFT+U

These actions are available in the following locations:

  • On the Album menu
  • On the context menus of the "Make album" and "Upload" buttons
  • On the context menu of the current project
  • Within the new MultiMaker window (see below)

Once you’ve submitted a task for background processing, it can be monitored, paused or aborted through jAlbum's new Progress Manager component and its task list, which is is revealed when you click it:

Progress manager showing background tasks

The progress manager showing background tasks

The Progress Manager is located in the lower-right corner of jAlbum’s window, to the right of the status bar. It’s normally hidden, but appears whenever background tasks are being processed. The first ("oldest") started task’s progress can be monitored directly. Click the Progress Manager to reveal more details and to view any other queued or running tasks. (click outside to close it). There are buttons to pause/resume a task or to abort it. While processing a task, the tasks panel also prints the estimated time left in the lower right corner of each task.

Queuing tasks

Tasks are processed in a "first-come-first-served" fashion, moving from the top of the task list down, but upload tasks can be executed in parallel with make tasks as they don’t compete for the same computer resources (CPU vs IO). Make+upload tasks are however executed in sequence.

jalbum 25 task conveyors

You can queue another upload task while an existing upload task is in progress. This allows you to initiate a possibly lengthy gallery upload early in an editing session and have that upload followed up by final make+upload task that includes your last edits.

Aborting tasks

Project list

To abort a task, just click the "X" button. To abort all background tasks, right click the component and use the "Abort all" context menu item. If you abort a "make+upload" task, then the upload part will be aborted too.

While processing background tasks, jAlbum shows a progress spinner on the corresponding project’s item within the Recent projects list. When aborting a task, you will notice a slight delay before these progress spinners go away. This is because jAlbum tries to do a "clean" abort, i.e. let any ongoing image processing or uploading complete first.


Notifications from tasks

Notifications displaying completed or failed tasks

To avoid interrupting your work-flow, jAlbum’s background processor will notify you on completed or failed tasks using the status bar and optionally also by displaying a Notification, which is hidden after a couple of seconds.

If you find the Notifications too intrusive, then you can make them discrete or switch them off altogether under Preferences. Discrete notifications only show when you click the Megaphone button in the top of jAlbum’s window. On top of this, jAlbum also prints information on initiated, completed, failed and aborted tasks to jAlbum’s system console (F7).

Project monitoring

jAlbum 25 can ensure that selected projects are automatically made and possibly also uploaded (in the background) as soon as changes are detected to the project. To activate project monitoring, use the Monitor changes context menu of the current project:

Monitor changes

Activating project monitoring

Monitored projects are indicated with an eye icon in the recent projects panel. jAlbum checks monitored projects for changes every 10 seconds. Once changes are detected, jAlbum will inform you using a Notification and initiate a make or make+upload task. Likewise, completed or failed task are also indicated using Notifications.

The new Multi Maker

The new background processing engine of jAlbum 25 makes it both faster and easier to update multiple projects as you can queue multiple make- and upload tasks, but jAlbum’s Multi Maker window makes this even more convenient. It now works along with the new background processing engine and acts as a "task submitter" for it. Simply select the projects you wish to process from its project list and use the relevant action buttons.

Multi maker window

The updated Multi Maker window of jAlbum 25

Once you’ve submitted tasks, you can close the Multi Maker window and continue working with jAlbum. Monitor and control the progress of any submitted tasks as described earlier here by using the Progress Manager component.

The new MultiMaker is more informative than the old, listing sortable table columns for project name, skin, style, last made and last uploaded dates. To reorder the table based on, say "last uploaded" date, click the "Last uploaded" column. To quickly remake all projects made using a certain skin (say after a skin update), click the Skin column, then select the projects using that skin and hit the relevant action button. Completed tasks will be reported using Notifications, but for clarity, they also turn turn green within the Multi Maker.

In addition to this, the updated Multi Maker also features a context menu where you can open, preview or view the project the mouse rests on as well as submitting that specific project for background processing.

It’s also worth reminding that the Multi Maker allows you to drop a file listing paths to each project you wish to reprocess.


jAlbum 25 aims at making life easier for you who regularly maintain one or several galleries. Image processing is significantly faster and you can have jAlbum make and upload galleries while you continue your edits. As background tasks don’t need to wait for your interaction, you also save time. Uploading a small change, like an adjusted title or rearranged images is now down to a split second! You’ll soon fall in love with the CTRL+M keyboard shortcut (CMD+M for Mac).

jAlbum 25 is a free update for anyone who is on a current support & update plan (check under About jAlbum). In any case, you can evaluate all functionality during 30 days.

Get jAlbum 25 today!

jAlbum 24 is here!

jAlbum 24 is here, reading and writing new, better image formats than JPEG and delivering images that fits the client's screen better than ever. We're also bundling jAlbum with two major skin updates and some other improvements. It's been a long time since we released a major version, but I hope you'll find these improvements worth the wait.

Offering choices to the browser

"Any customer can have a car painted any colour that he wants, so long as it is black."
- Henry Ford
This quote pretty well tells how images have been delivered over the web. The same image type and resolution have been delivered to the browser no matter its capabilities or the screen's capabilities. This is about to change...
A few years back the HTML specification standardized on a a way for the browser and server to negotiate on the image type and resolution that best fits that client. The server can offer a list of image variants of various types and resolutions and let the browser pick the one that it prefers.
Image credit: Jason Leung -
Choice is a good thing, isn't it? In jAlbum, we call this Variants (See Settings->Images).
The model has multiple advantages:
  • Provides the ability to introduce newer image formats while keeping JPEG as fallback for 100% browser compatibility
  • Allows the browser to pick a higher resolution image for high resolution displays while serving smaller and faster versions to other devices
  • Allows the browser to pick better compressed variants for supported browsers while serving ordinary JPEG images as fallback
New image formats
As I mentioned, we can now introduce better image formats without breaking compatibility with old browsers. JPEG has been around since 1992 and has become of age. 

WebP (read and write)
The first new image format to accompany JPEG for image generation in jAlbum is WebP. WebP provides several advantages over JPEG:
  • Lossy or lossless compression
  • Compresses better than JPEG
  • Supports alpha (transparencies)
  • Supports animation
  • Lossless variant compresses 26% better than PNG
WebP is supported by most browsers today, among those Chrome and Firefox. However, older Safari browsers don't support WebP, so to keep 100% compatibility, jAlbum can serve a JPEG as fallback for browsers that don't support WebP.
The following two galleries demonstrates showing transparent images the old way (PNG images) vs the new way (lossless WebP with JPEG fallback). Even though we add JPEG images as fallback, the 2:nd gallery is less than 1/3 the size of the original gallery!
HEIC/HEIF (read)
jAlbum 24 now reads this new format, commonly used by iOS devices. The format has several advantages over JPEG, among these 50% better compression and support for image sequences, lossless reversible editing, alpha and depth information.

AVIF and others (future)
This latest format isn't supported by jAlbum yet but we'll plan to support it as soon as we can. What's exiting about it is that it, apart from offering the advantages WebP has over JPEG, it compresses even better and offers 10- and 12 bit color depth and wider color gamut. It's supported by Chrome today meaning it works for a majority of viewers already. We'll likely see more formats emerging now that the brower can choose.

Variants in jAlbum
Our take on this new browser choice is called Variants. Under Settings->Images->Variants you can now specify any number of additional image sizes and formats to be generated. These are specified as a size multiple of a typical thumbnail or closeup image. If you simply want to cater for HiDPI screens without imposing a 4x size and bandwidth penalty on all other devices, add a set of 2x variants. To reduce the additional disk space, choose WebP instead of JPEG. To cater for those having large screens and offer crisp zooming, add 3x or even 4x size variants. The choice is yours, and eventually the browser's.
You can watch this video or play with this sample gallery to see how the browser loads different image sizes depending on the browser window size.

Skin support
Skins need to be adapted to support Variants. We currently bundle jAlbum with updated versions of Tiger and Minimal that have this support added. You will also see updated skins from our user community.

Minimal 8
Apart from Variant support, Minimal 8 offers a new mixed color style and responsive closeup images. These images will fill as much of the browser window as possible. Navigation buttons and text are superimposed onto the images to maximize the images, and they are hidden after 5 seconds of inactivity, showing ONLY your beautiful image. Minimal has become even more minimalistic.
This demo demonstrates the use of 2x and 3x sized variants. Resize the browser window to see how the browser chooses the best suiting variant!
(The image sizes are printed on each variant for demonstration purpose)

Tiger 3.0

Our default Tiger skin is reborn too. Not only to support Variants, but its underlying structure has also been renewed for a better responsive (a.k.a “flex”) layout. Here’s a short list of changes:

  •  Image variants support
  • Instant preview for some 50 settings on the User Interface
  • Continuous zoom (zoom slider)
  • Masonry thumbnail layout
  • 2 icons sets: fat and thin
  • Sticky (always on-screen) Shopping cart, Feedback and Filtering boxes
Read more about the changes and on how you can play safe with upgrades in our Tiger blog post.
A peek under the hood
Without getting too technical about this, here's a short html code snippet that shows how WebP images are presented to browsers that support WebP while older browsers will choose the JPEG fallback:
  <source type="image/webp" srcset="img-1600w.webp 1600w,img-800w.webp 800w"/>
  <source type="image/jpeg" srcset="img.jpg 800w"/>
    <img src="img.jpg" width="800" height="600" alt="My garden">

Modern browsers will look through the source elements, picking the first one with a supported image type. It will then select the most suitable size variation. Older browsers simply ignore the picture and source elements and read the img element.
For a basic jAlbum skin to support variants, all that is needed is for the img element to be wrapped in a ja:picture element, like this (Minimal skin's slide.htt file):
  <img src="${imagePath}" width="${imageWidth}" height="${imageHeight}" alt="${title}">
See the full list of enhancements in our release notes. I hope you're really excited to run jAlbum 24 now. Just head to our download page.