Checking for a Watermark

The last method in the ImageSign category is the verify() method (Listing 6). This method also checks the target image for a given watermark. But it returns a BOOL value to show if the watermark remains mostly intact.

Listing Six
// Check the target image for a watermark
- (BOOL)verify:(NSData *)aMrk;
{
    NSNumber *tRef, *tAct;
    NSComparisonResult tTst;
    BOOL tChk;
    
    // set the desired percent coverage
    tRef = [NSNumber numberWithDouble:68.2];
    
    // calculate the actual coverage
    tAct = [self coverage:aMrk];
    
    // validate the result
    tTst = [tRef compare:tAct];
    tChk = (tTst == NSOrderedSame) || (tTst == NSOrderedAscending);
    
    // return the check result
    return (tChk);
}

The method begins by creating an NSNumber object tRef with a value of 68.2 (line 9). This value is essentially twice standard deviation, expressed as a percentile. Here, it sets the lower bound of a watemark’s level of confidence. So if at least 68.2% of the image has an intact watermark, the image is likely to be authentic. Less than 34.1% could mean the image has been severely altered or it may be original work. But if the actual percentage is between 34.1 and 68.2, the image may be derivative work, warranting a more detailed inspection.

The method then calls the coverage() method (line 12), passing along the watermark as input. It takes the result from coverage() and compares it against tRef (line 15-16). The outcome of the comparison then serves as the output value.

Testing the Watermark

In Figure 5 is the image used to test the watermark algorithm. This is a digital photo of two figs, with one split in the middle. The photo was taken with a Palm Zire 71, which has a pixel resolution of 640x480 pixels (about 0.3 megapixels). The image format is an uncompressed big-endian TIFF with a resolution of 72 dpi (dots per inch). The color model is a 24-bit RGB and the image size is 428 pixels by 321 pixels

Figure 6 shows the same image, but with the string “watermark” embedded into its pixels by the coverage() category method. The image format is still the same uncompressed big-endian TIFF. The color model, image size and resolution also remain the same. Notice the image showed no visible quirks due to the presence of the watermark. But open the marked image with an image editor and look at its top-left pixel — you should find a color value of 0x1d2e36. Compare this with the same top-left pixel from the unmarked image — that pixel will have color value of 0x1f2f34. The lower nibbles of each color byte differ by a value of one to three, depending on the embedded watermark bits.

The Watermark and Image Effects

Table 1 shows how the LSB watermark stands up to five common image effects. First effect is a Gaussian blur, applied with a radius of five pixels. The result is an image that appears out of focus. Second is a color inversion, which maps each pixel to its opposite color and intensity. It renders the image into its color negative. Next up is a sepia tone: This one remaps the pixels to shades of brown, giving the image a distinct old-fashion look. Then there is the unsharp mask, which enhances the edge contrast around each major detail. It uses a radius of 2.5 pixels and a relative intensity of 0.5. The last effect is a smudge, applied to the borders of each fig. It is a restricted Gaussian blur using a radius of five pixels.

All five effects are supplied by the Core Image framework. The altered images are again saved as uncompressed big-endian TIFF files, with the same size of 428x321 pixels, using the same 24-bit RGB model and 72 dpi resolution.

Now of the five images, only the smudged one still has most of its watermarks. This is because the effect is localized, affecting only a small portion of the image. The other four effects alter the whole image, making it visually different from the original marked image. Except, of course, for the unsharpened image, which looked like a sharper version of the original.

So for the LSB watermark to stay effective, it must be applied last, after all possible effects. Moreover, a visible watermark can help counter the effects of an unsharp mask.

The Watermark and Image Formats

The next two tables show how the LSB watermark survives changes in image format. In Table 2, the marked image is saved into four TIFF files, each file using a slightly different setting. For the first TIFF file, the image was resampled from 72 dpi to 300 dpi. For the second, the image was saved in little-endian mode, as opposed to big-endian. The last two TIFF files compressed the image data compressed — one with LZW, the other with RLE.

Of the four TIFF files, only the 300 dpi variant lost its watermark. To increase the resolution from 72 to 300 dpi, the resample process has to use interpolation to create the necessary pixels. The interpolated pixels may have one or both watermark bits or none at all. Since the watermark bits were applied in succession, changing the resolution of the marked image also changes the order of those bits.

The other three TIFF files kept their watermarks mostly intact. Changing the byte-order, for instance, did not affect the watermark in any way. Though the pixel bytes are ordered differently, the watermark bits are still in the correct bytes and in the correct sequence. TIFF compression did not affect the watermark as well. Both compression algorithms themselves are lossless. They do not remove or alter any essential bytes.

Table 3 shows the marked image, this time saved in four different formats. The BMP format is, of course, the raster graphics format used by Microsoft Windows and the defunct OS/2 system. The PNG format is the FSF/W3C standard meant to replace the legally problematic GIF format. Both formats, like TIFF, are lossless. Thus the saved image data still holds on to its embedded watermark.

The other two formats are JPEG and its successor JPEG-2000. Both are lossly formats because they filter out colors not perceptible to the unaided eye. Both remap the pixel data from RGB to YCbCr. But whereas JPEG uses a discrete cosine transform as its filter function, JPEG 2000 uses a wavelet transform.

Nevertheless, the LSB watermark fails to survive the quantize process. This is not surprising since this watermark manifests itself as subtle color shifts. Here, too, a visible watermark could help counter the effects of JPEG compression.

Conclusion

Watermarks provide an effective way to secure and authenticate a digital image. They can help deter the unfair use of the image, as well as counter attempts of forgery and theft. If properly applied, a watermark can be difficult to duplicate or remove. Some, however, are susceptible to certain image effects.

The NSImage class is the primary container for image data on the OS X platform. Yet it lacks the means to apply a watermark to a given image, or check for one on the same image. To address this lack, we used the category mechanism to add three new methods to the class. We also used the same mechanism to give the NSString class the ability to produce an MD5 hash. Later, we embed this hash into the target image using an LSB watermark algorithm. And we tested how well the embedded watermark stands up to a handful of image effects and formats.

So ends this topic of securing the NSImage data with a digital watermark. For more information, feel free to consult the following references.

References

Apple Developer Connection. Cocoa Core Comptencies:Categories, Apple Inc. [2010 Aug 03].

CocoaDev.com, NSImage. [2010 Oct 13].

Michael Stumpfl, Digital watermarking [pdf]. Department of Electronics and Computer Science. University of Southhampton, UK. 2001.

Wikipedia, Digital watermarking. [2008 Apr 27].

Cruz is a freelance engineering writer currently residing in North Vancouver, British Columbia. He can be contacted at anarakisware@gmail.com.