Summary: pix.js can be used to create web photo galleries, and is described at some length in its own page. Here I say a few words about what you have to think about before embarking on the construction of a gallery.
A photo gallery is a way of displaying photos and allowing the viewer to navigate between them. It is something more than an archive. If you are constructing a gallery for your photos, it is assumed that you will whittle them down to a small number of good ones, and that you are willing to put some effort into basic editing of them. Constructing a gallery is more work still, and a quite different task from simply uploading photos to the “cloud”.
Your first decision is which gallery software to use. This should be based on the capabilities of the software and the attractiveness of what it produces; you should also take account of its flexibility and ease of use. The last of these is likely to be the hardest to judge. Software authors are not shy in describing the merits of their tools, but not always so forthcoming in admitting how much work is involved in using them. Some software is free, and otherwise you need to take account of its cost.
I have no experience of web photo gallery software other than my own. A Google search will find you the most popular alternatives.
If you use pix.js your second decision is what set of image sizes to use. This isn’t a binding commitment – you can change your mind from one gallery to another – but you should at least try to make a reasonable choice at the outset. If you have no strong preference, you might as well use my own sizes. The relevant considerations are listed below. Although pix.js is very flexible over sizes, my rescaling software has my own preferences hard-wired in. You will need to do some more work to use other sizes.
If you construct a gallery with pix.js, then – having been through the design stages – you need to follow a series of steps. You do not need to process all photos under the first step before moving on to the next; usually I take a few photos through the entire sequence of steps, then add a few more, and so forth.
Firstly you need to select your photographs.
Secondly you need to edit them to produce suitably named versions at the largest size. My convention is that the filenames are comprised of image names of my own choice (eg. “steephill”) followed by an “@”, followed by a suffix associated with the size (eg. “5”) followed by the extension “.jpg”. So “steephill@5.jpg” will be the largest image amongst the set for which I’ve chosen the name “steephill”.
Thirdly you need to rescale the images to the smaller sizes. I just type
pixdownscale.sh 5
The process is documented on my pixrescale page.
Fourthly you need to make entries in a configuration file, often called list.xml, giving the properties of the image: its shape, its name, its title, etc. This is the process documented in full in the pix.js documentation.
Fifthly you need to make an HTML file which displays the gallery. This is just a few lines of boilerplate code, as also described in the pix.js documentation. Perhaps the file will be called alpineclimbs.html. As noted in the pix.js documentation, your files are all on local disc, and file loads are not easily permitted in the Chrome browser; you are therefore recommended to use Firefox, placating it by adjusting the settings as described on the same page. When you visit alpineclimbs.html (from ‘File>Open...’) you should see an attractive – if incomplete – gallery.
Sixthly you are advised to check for errors within the browser by appending “?mode=v” to the end of the entry in the URL bar and hitting return. Various errors will be detected and reported at this point.
Seventhly you can now upload the whole lot to the web: HTML, XML and jpegs. You can view it there to make sure it’s intact.
I am not aware of any other gallery software which requires the user to create a configuration file in XML or any other language.1 That I do so is no doubt off-putting to potential users, but it is certainly the right decision. It makes the image properties reusable. Having entered them once to construct a gallery, you can incorporate the same images alongside text in other pages, you can show them against their positions in routemaster, and in principle you can use them in any number of other ways. And if you make a change, such as moving the images to a different directory, you can update your configuration in a simple and direct way.
Other gallery software must have means by which a user defines image properties. The slickness of the method adopted should be taken into account when choosing one piece of software over another. In particular if a value (such as directory location) is common to all or most images, you shouldn’t have to enter it separately for each one.
1. However my knowledge is very slight.
Not much needs to be said about videos, which may be included in galleries as described in the pix.js documentation. I think some gallery software doesn’t accept videos, but this seems to be an unnecessary limitation: they’re treated so much like still images in HTML that not much additional work is needed.
There are certainly important practical differences, but their effect is that some of the aspects which need care for still images can be glossed over for videos.
The main practical consideration is simply size. Videos take up a lot of space on memory cards, on hard disc, and on a server; and they need a lot of bandwidth to download. Moreover, if a web page was to choose between different resolutions, its decision would want to be based chiefly on bandwidth, which isn’t available to it in the same way as screen size. For this reason you are unlikely to want the same high resolution for video as you expect for still images – even if your camera is capable of providing it. Accordingly my own usage is to display videos only at fairly low resolution, and pix.js allows only one size for them. Therefore you are spared any worries about how to choose a suitable series of video sizes.
To be specific, my videos are 960x720, 25fps, and I encode them at low resolution (“-crf 30”) using ffmpeg. I often pan (using my own software) to reduce 1280x720 to 960x720.
A web gallery should be built from images at a range of different shapes and sizes.
Your camera probably takes all its photographs at a standard size, such as 4000x3000; if you rescale them, you retain the 4:3 aspect ratio. When you create an image gallery you should expect to choose different aspect ratios from shot to shot. A uniform ratio can become boring, especially if it’s a rather sterile one such as 4:3 or 3:2. Landscapes may benefit from a letter-box configuration; on the other hand photos in portrait mode, viewed on a screen which is wider than high, are likely to look better if they are not too oblong.
To change an image’s aspect ratio you need to crop it; and it is a good practice, when taking digital photos, always to zoom out a little further than looks best, so as to have freedom to crop down to the ideal frame later.
You could of course put arbitrary aspect ratios in your gallery, such as 3958x2664. But some discipline is needed because (as we see later) you will rescale an image to a set of smaller sizes, so the dimensions need to be a simple multiple of whatever is the smallest size. It helps to be more disciplined still, and to limit yourself to a discrete set of ratios.
My own practice is as follows: a legal aspect ratio is the ratio of two integers whose sum is 24. Thus 16:8, 15:9, 14:10, 13:11, 12:12, 11:13 etc. are all legal, but 4:3 and 3:2 are excluded.
A gallery will not work well unless each regular image (that is, disregarding thumbnails for the moment) is provided at a set of sizes. This is so that you can make good use of large screens while avoiding downloading a megabyte to devices which can only display a kilobyte.
My own practice is to increase the linear dimension by a factor of two for every two steps along the scale of sizes. Specifically my linear dimensions are in the ratio 7:10:14:20:28:40. (I could equally well have chosen 5:7:10:14:20:28.)
One of these sizes is the smallest, one is the largest, and one is the reference size. All the sizes are defined relative to the reference size, which could be either the smallest or the largest. My own reference size is 100 times a pair of integers whose sum is 24, eg. 1400x1000. This is easy to work with. If I made the smallest size the reference, I would be dealing with numbers which weren’t very round. I haven’t chosen the largest as reference for two reasons. Firstly, as screens have got larger, I have occasionally increased my maximum size, and it is convenient not to change the reference. Secondly, occasionally I do not have an image at the maximum size (eg. if I’ve cropped drastically), and it’s helpful to retain the same reference.
Putting these facts together, we see that the regular versions of an image will be stored at the sizes shown in a column of the following table, in which the bold row is the reference.
| ... | 3200x | 1600 | 3000x | 1800 | 2800x | 2000 | 2600x | 2200 | 2400x | 2400 | 2200x | 2600 | ... | @5 | ||||||||
| ... | 2240x | 1120 | 2100x | 1260 | 1960x | 1400 | 1820x | 1540 | 1680x | 1680 | 1540x | 1820 | ... | @4 | ||||||||
| ... | 1600x | 800 | 1500x | 900 | 1400x | 1000 | 1300x | 1100 | 1200x | 1200 | 1100x | 1300 | ... | @3 | ||||||||
| ... | 1120x | 560 | 1050x | 630 | 980x | 700 | 910x | 770 | 840x | 840 | 770x | 910 | ... | @2 | ||||||||
| ... | 800x | 400 | 750x | 450 | 700x | 500 | 650x | 550 | 600x | 600 | 550x | 650 | ... | @1 | ||||||||
| ... | 560x | 280 | 525x | 315 | 490x | 350 | 455x | 385 | 420x | 420 | 385x | 455 | ... | @0 |
The rightmost column gives the suffix used in my configuration file to distinguish the filenames corresponding to the different sizes. We see that even though the reference sizes have been chosen as fairly round numbers, by the time we get down to the small images the numbers are quite awkward.
Thumbnails are smaller images used for specific purposes. The gallery display will be a table of thumbnails; the thumbnails may be used as links to the main images from a text page; and routemaster displays thumbnails as its initial version of an image.
Various strategies might be adopted over thumbnail aspect ratios:
I adopt the third of these. pix.js is certainly more general, and will be happy with the fourth, and perhaps with one or both of the others.
The second and fourth allow a gallery to be laid out with no waste space, though the fourth requires severe cropping. The first and second lead to thumbnails with extreme shapes which do not look good in galleries. Part of my preference for the third arises from the fact that thumbnails may be used anywhere, so I’d rather not depart too far from the original image contents. An automatic procedure for creating thumbnails will often make a bad job of cropping to a significantly different shape.
In consequence my thumbnails are always 196x140 or 140x196.
Once an image has been edited at the largest size, its rescaling to all the smaller sizes is a purely routine operation. Image gallery software should ideally provide a means for doing so, but the task isn’t without difficulties. It can only reasonably be performed at the location on which the images are stored. If you have your own website, then you will have a directory structure mirroring it on your own computer; and software either there or on your web server can generate the new images; but this requires you to install software in one place or the other, which isn’t entirely straightforward.
Web galleries which are part of image hosting services have an easier job. You upload your images to their website rather than your own (even if you can give it a URL of your own choosing as a subdomain), and the hosting service can install suitable software on it.
For more than 20 years I did all the rescaling manually. I do not recommend this. Not only is it laborious, it may also be badly done. In particular, using Photoshop is a no-no. Photoshop preserves the EXIF (image metadata). Some of this (eg. the date and time) is worth having, but the EXIF also includes the camera thumbnail, which may be 20kB. If you reduce an image to thumbnail size in Photoshop you end up with us much bloat as data – the camera thumbnail in addition to your own. And if you produce an icon for routemaster, it is almost pure bloat. You should keep the original photo whatever you do, and that is the only copy of the EXIF you need.
There were two reasons why I held off from automation. The first is that any form of software would need to use a jpeg library, and I had no knowledge of them. The second is that I’d have liked to find a form of automation which anyone – not just myself – could use. I haven’t done so. I’ve written programs and scripts which can be downloaded and executed on any computer capable of processing the languages used, but this may pose considerable installation requirements. You need a C++ compiler, and the scripts probably can’t be run on Windows; and then you need to install my own software. If you aren’t in a position to do these things, then pix.js may not be for you.
My software, together with documentation and download instructions, is on my pixrescale page.
As for what other gallery software does, I have no idea. I’ve seen a tool which supports only one regular size for each image: this might have been adequate 20 years ago, when there was less variation in screen sizes, but really shouldn’t be entertained now. So one consideration in choosing gallery software is the adequacy and ease of use of its rescaling capability.