Merging Images in Photoshop, Part Two

While my first post in this series covered some basics of non-destructive image merging in Adobe Photoshop, this post aims to give you some tools to work with less ideal images.

A typical problem faced by many when attempting to merge images is how to deal with slight variations in your materials. These variations can be a result of the hardware you use (scanner or camera), lighting conditions, software, or a myriad other factors.

In this scenario I'll use an image from a scanned book that has a lighting problem. This is a very common difficulty when scanning books on a flatbed; the book's gutter will raise up from the scanner's surface, giving it a darker tone and distorting the content. Applying pressure to the book may work sometimes, but often we do not want to risk damaging our books (or, worst-case-scenario, our equipment) that way. Much safer to work digitally.

The first step is identifying the cutoff point where the gutter begins to negatively affect image quality. As you can see from this image. As always, make sure you've saved a master version before making any edits. 

Use the Rectangle Marquee tool to isolate the "safe zone" of the page, where the page's content is mostly unaffected by the gutter. Copy this selection and paste it into a new document with approximately the same dimensions as the original document. This is our new "base" document. I will usually put the word "EDIT" in its title somewhere so it won't be mistaken for the master.

In situations like this when we are dealing with an off-white paper, we'll want to make sure our background matches the paper's tone. Use the Eyedropper tool to select the page tone, and use the paint bucket to fill it in the background of the new base document.

What we are going to do next is create an amalgam of the image's two elements (page and background) to create a new version with improved legibility. To accomplish this we are going to use Photoshop's Layer Mask tool. Layer Mask is incredibly useful for photo editing, and best of all it is a non-destructive solution, meaning whatever you do with it can always be easily undone. The Layer Mask is very much what it sounds like: a layer placed on top of each image that can be "masked" or "unmasked," concealing or revealing the image's contents. Select the right side layer and click "Add Layer Mask" at the bottom of the Layer menu. You will now see a small white rectangle linked to that layer; that's your layer mask. The color white means "unmasked," so right now it's simply sitting on top of your original layer waiting for you to give it instructions.

Next, be sure you have the correct layer, AND your layer mask selected, or else you will alter the image itself. The Layer Mask functions in grayscale. Black is "masked," white is "unmasked," and grays are everything in between. Set your foreground color to black. Select the brush tool, and reduce the hardness to 0 (use whatever diameter you feel comfortable with). Check again to make sure you're still on your layer mask, and simply begin lightly touching up the problem spots along the gutter with your brush. Use single clicks rather than click-and-drag, that way you will make very minor adjustments while you get a feel for the technique.

As you can see, we've fixed the page to appear legible and flat. But be warned, this exact method won't work for every situation. If you have content that is deep in the book's gutters, you will likely have to accept a less-than-perfect image. However these techniques can still be used to improve the image quality in those situations, it is simply more difficult to get a "perfect" image. Vary your brush settings and color in the Layer Mask (experiment using a 50% grayscale) to find solutions that best suit your situation.

Written by Ryland Ianelli

File Validation Woes

Over the last few months I have been preparing and ingesting the master TIFF files for the Photo Files collection into our local repository system for safe keeping. The first step is to package the files using the BagIt specification. BagIt was developed by the Library of Congress and the California Digital Library as a way to package files along with some basic metadata that can be used to validate the bags contents. It's the digital equivalent of putting a bunch of things in a box, along with a list of the box’s contents and a unique identifier that can be used to identify each item. Since our Photo Files collection is enormous (so far I’ve deposited over 45,000 images, and we’re not even half way through the collection), I break the bags into manageable chunks for uploading and processing in our repository.

Once a bag is uploaded onto the server, it is validated using the BagIt tool. This is a programmatic way of checking that all the files are still exactly as they should be, and no file has been altered or gone missing or snuck in on the sly. Finally, the contents of the bags are run through the File Information Tool Set, or FITS. FITS brings together a bunch of open-source tools that identify file types, check to see if those files are valid, and extract technical metadata. So, for instance, when I deposit a bag from the Photo Files collection, FITS produces a report that says “These files are TIFFs! These TIFFs are well formed and valid! Here’s some technical info you might want to have around!”, only with less exclamation marks:

Sample FITS report

So, this process has been going along just swimmingly until a few weeks ago. Like I said, I’d made it through about 45,000 images, and then suddenly, BAM! an error report for every single image:

page-masters/Icon1647-0875-0000010A.tif is not valid: "Type mismatch for tag 700; expecting 1, saw 7"

All about the Tagged Information File Format (TIFF):

The first thing I discovered was that this error message had something to do with the T part of the TIFF. The TIFF file format has what’s called a header that uses tags to describe the content of the file. These tags, and the information in them, can be manipulated using various types of tools. The capture software we use to create our master images automatically inserts certain tags. As part of our process, we add additional information into the headers of our TIFFs. This is called embedded metadata, or information about the file that is part of the file itself.

The problem with these images was the 700 tag. From the Library of Congress’ super useful guide to TIFF tags I learned that this tag has something to do the XMP metadata within the file. XMP is a data model for structuring embedded metadata. Data models for metadata help standardize how metadata is stored. For instance, I could edit an image to say “Author: Jane Doe”, while someone else might edit it to say “Photographer: Jane Doe” and we could both mean the same thing. A data model would say, “Ok, everyone, we’re going to use the term Creator.” This makes it easier for both humans and computers to make use of embedded metadata, making digital objects more discoverable and easier to maintain.

So, now I knew that there was a problem with the metadata we were embedding in the files. Something about a 1 and a 7? Deep inside the Photoshop user forums, I found that I was not the first one to run across this problem. These numbers refer to the type field in the XMP, with 1 meaning “byte” and 7 meaning “unknown”. So these files said "unknown" when they should have said “byte”, right? Well, not really. According to David Franzen (Employee)’s response in the user forum, both the 1 and the 7 were valid values. So why was I getting this error message?

JHOVE and FITS:

As mentioned above, FITS packages together a number of tools. The tool that was giving this error message was Jhove, or JSTOR/Harvard Object Validation Environment. According to wikipedia, Jhove tells us whether or not objects are “well-formed (consistent with the basic requirements of the format) and valid (generally signifying internal consistency).” The version of Jhove that is packaged in FITS says that in order for a TIFF to be well formed, tag 700 needs to have a “1”, and anything else is invalid. But it also seems that the "7" is also a valid value for this tag. So, why is there this discrepancy in what makes a valid TIFF? Well, it turns out that when Jhove was first developed, the TIFF format specifications weren’t exactly easy to decipher. The TIFF specifications encoded in the tool were based on confusing, incomplete and scattered documentation. When others started getting the same error message as I got, they turned to Adobe for clarification. As a result, Jhove’s code was updated in version 1.8 to accept both “byte” and “unknown” as valid values in the 700 tag.

However, the updated version of Jhove didn’t make its way into FITS. Apparently, there were some other changes to Jhove 1.8 that would make integrating the newer version into FITS a rather large job. Making the necessary changes to FITS to accept newer versions of Jhove currently isn’t a priority for the FITS developers.

The Real Culprit:

Now that I knew what was causing the error message, I circled back to the big question- why now? The first 45,000 files had been just fine. What changed? In discussion with our digital production team, I learned that there had been a significant change to the production workflow, specifically in how they were adding embedded metadata. What before had been a time consuming process was greatly simplified by using Adobe Bridge to quality check images and add metadata. In researching this error message, I had seen people mention Bridge as the culprit in changing the 700 tag.


                          

Testing embedded metadata settings:

To be sure, I decided to play around with the settings in both our capture software and Bridge to see if I could get a different result. I created a number of test images with different metadata settings using our capture software, then ran these through FITS. All checked out okay. Next, I played around with the metadata setting in Bridge, and made changes to the embedded metadata in my test files. I ran the files through FITS again, and all failed to validate. No matter what settings I used in Bridge, the 700 tag was changed.

So Now What?

Now that we knew what was causing the error, there were a number of different approaches we could take. To find out what we did, stay tuned for my next blog post...

Written by Jenny Mullins