Processing Photos

Files and Directories

All photos that Albumatic processes reside in files on the local computer (the one running Albumatic), and, once published to the Web, on the Web/FTP server as well.

Each album is kept in its own directory whose name is the same as the album name, but with punctuation characters replaced by underscores. All albums are located under a common root directory. You set for your PC with the Application Preferences dialog, and for the Web site with the FTP Connection dialog. You can also arrange to the album to be in a tree that's common to both the local and remote sites with the Subdir field in the Album Properties dialog. See Local and Remote Directories for more information.

Albums whose directories have a common parent (i.e., siblings) can be included in a library. See About Libraries or a detailed explanation of the directory structure of libraries.

The are four types of photo files that can be involved in an album:

  1. Original photo files, usually JPEGs (e.g., "myphoto.jpg"). These are created outside of Albumatic and usually exist before Albumatic is used to build the album. That is, they are brought into the album rather than created by Albumatic. An important principle to remember is that Albumatic doesn't modify these files in any way. If it needs the file in a different location, or needs to crop it, or flip it, or resize it, it makes a suitable copy. These copies are types #3 and #4 below.
  2. Scanned-in files created by Albumatic if its Scan button is pressed. (Photos you scan in outside of Albumatic are of type #1.) You supply the file name for these, and they're always placed in the album directory.
  3. Photos that appear in the table on the Index View. These range in size from thumbnails to full-size originals (depending on how you've set your album properties). They are always located in the album directory, and their names are the same as the original-photo file name with "S_" prepended.
  4. Photos that appear when the user clicks on a photo on the Index View. These appear on the Enlargement View. Usually, these are larger than the main photos, but this is not a strict requirement. Like #3, these are always written to the album directory, but with "L_" prepended.

Output Image Characteristics

For types #2 through #4 in the preceding section, Albumatic always writes JPEG files. The quality varies depending on the purpose, however. For thumbnails, the default quality setting is 70%; for all others it is 90%. (Note that these percentages don't have a standard meaning, even within the world of JPEGs, but are rather just parameters to the particular algorithm used by Albumatic.) To say it more simply, thumbnails look a little mottled and the others look great. But, thumbnails are very small, usually only 2K each, so the main page loads very quickly, even if there are dozens of photos. The larger linked-to photos only load when the user clicks on a thumbnail, so that's pretty responsive, too.

If you don't like the default JPEG qualities, you can set your own via the Album Properties dialog.

JPEG Restrictions

Albumatic can't process grayscale JPEGs (you'll get an error message), which you sometimes get when you scan a black-and-white photo. It can handle black-and-white as long as the image is encoded as a full-color image. You can ensure this by choosing "full color" or "true color" when you scan, or, if you already have the image, by running it through an image-processing program to change its format.

Writing a New Image vs. Copying the Original

When it needs to write an "S_" or "L_" file into the album directory, Albumatic usually creates a fresh JPEG even if the original is already suitable. When would that be? Well, if the size set in Album Properties is "original" and the image hasn't been cropped flipped, or rotated, the original file could, in theory, be just copied (saving all of the complicated JPEG processing) or even used in place.

Using it in-place normally won't work, because all of the album URL references have to be the same on the local system and on the Web site. (There are ways to deal with this complication short of making separate copies, but we didn't choose to do that.)

On the other hand, if you have a set of fairly big JPEG files and you're not asking Albumatic to crop, flip, or resize them, why should you have to have two copies on your disk, when one would clearly do? For this important case Albumatic is willing to forego writing a new file if the original is located in the album directory. It will never move it there—it has to already be there. Note that this will happen automatically for scanned-in photos, because they're put in the album directory to begin with.

So, if you want the main album page to reference original photos, do this:

  1. Use Albumatic to create the album, but don't add any photos to it.
  2. Using Windows Explorer (or any other utility you want), move the original photos to the album directory which got created in step #1. Or, if you want, make copies there. (No need to do anything for photos that you've scanned in with Albumatic.) You can even do this from within Albumatic's Add dialog; here's how.
  3. Now with Albumatic add the photos to the album.

If it's really true that the album properties call for the linked-to photos to be original size, Albumatic will be smart enough to just use the original if that particular photo isn't being cropped, flipped, or rotated. If it is, a copy will be made, but perhaps not for the others. When reusing an original for the linked-to photos, Albumatic doesn't try to rename them so as to prepend "L_". It just uses the original name.

Albumatic never attempts this trick for the "S_" photos (the ones that appear on the main album page).

Of course, none of the above has anything to do with what needs to be transferred to the Web/FTP site. All photos referenced by the album need to be copied there, at least once (see next section).

More Smart Processing

Albumatic tries to be smart about when it needs to write a new photo file and when one it's written previously is OK. If the original hasn't changed since the output file was written and none of the relevant album or photo characteristics have changed (e.g., the cropping is still the same), the photo is just used again. This greatly speeds up processing. It may take 2 minutes to build the page the first time, and only a second to do it again if, say, all that happened is that the album title changed.

If for some reason Albumatic is failing to write a file when you think it should, or if you just want to be sure, you can use the Full Album Build command on the Edit menu instead of the Build Page button.

Albumatic is also smart about copying files to the FTP site, by looking at the times of the files. It only copies photos that are newer than the ones that are already there. This can go awry if the clock on your computer is set wrong—a file won't be copied even though it should be. The simple solution is to do a Full Album Build, which forces the next Publish to Web operation to upload everything, disregarding the times.

Albumatic never relies on the FTP site's clock or file times, as it's too difficult to figure out the remote computer's time zone.