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:
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.
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.
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:
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).
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.