Security Stripes
note cases where images have been manipulated beyond what their editors considered ethical. For example, the Journal of Cell Biology recently reviewed papers accepted over a period of 42 months. Although only 1% of acceptances were revoked, 25% of submitted papers contained at least one image that had to be redone before publication because they conflicted with image presentation guidelines [4]. Te need for standards is now obvious to the scientific
community. In fact, U.S. government regulations such as CFR 11 Part 21 give image integrity preservation the force of law [16] for pharmaceutical research. However, as intimidating as the CFR regulations may be, they do not specify a protocol. In fact, such detailed specification may not be generally possible within the CFR. Although there is general agreement that image file
formats should be loss-less, most else is up for grabs. Today there is a vast legacy of proprietary protocols (numbering over 50) and file formats that must be reduced to a few. Standards have been proposed by the Open Microscopy Environment, which endorses an OMEXML format, and a TIFF format that includes the non-image data in the ImageDescription tag as an XML file. OME also provides a Bio-Formats function library that can be used to read and write most of the proprietary formats and translate these into the OME-XML format [17]. In addition, the Microscopy Society of America ethics committee supports TIFF6 as a recording standard [1]. Still, neither these nor any other standard or protocol has gained dominance. More importantly, most do not address authentication.
Security Stripe Goals One possible solution to these difficulties is a security
stripe that embeds image information into the image itself. Te specific goals for developing the security stripe are: 1) Preservation of experimental conditions plus sample and authorship information.
2) Compatibility with native character sets. 3) Compatibility with standard imaging applications. 4) Flexibility to include new types of information without needing to revise the standard.
5) Authentication of both pixel data and the attached description of experimental conditions.
6) Extension to any loss-less image storage format, open or proprietary.
7) Preservation through image format conversion. In achieving these goals the security stripe has become
a visible addition to a digital image. It contains companion information, can authenticate the data collection process, and serves as a robust seal. It acts similarly to a product bar code, as it is immediately visible, while at the same time it encodes experimental information and authentication data. Because it contains data, the security stripe is similar to the invisible metadata oſten contained in headers of digital records. However, the stripe differs by being visible and not confined to a unique file format. Te stripe should not make obsolete progress made by
standards organizations or manufacturers who have dealt with these issues using specific loss-less formats and databases. It should provide a mechanism for exchange of data that can be used in conjunction with all loss-less protocols.
26
Security Stripe Implementation Tere are many ways one might design a security stripe,
and although flexibility is valuable, some general guiding principles will make exchange of information much easier. We propose that the following features be included in building a security stripe to be used for microscopy. 1) Te security stripe should use Unicode text data to encode the gray scales along a stripe corresponding to the width of the image. Unicode is a widely used format that permits standard encoding of native scripts.
2) Te text data should include experimental conditions as well as security keys for image authentication and validation. Te keys may be simple codes, can refer to image characteristics, be self-consistency checks, or a combination of these.
3) Te stripe should be appended to the picture section of the original digital image file in the form of pixels. Tis will create a single file where the companion experi- mental conditions and authentication information are permanently and visibly attached to the pixel data.
4) Te security stripe cannot be an overlay, as many lossless formats do not support overlays.
5) Te security strip should appear as a caption or part of a caption to the image. A prototype is shown in Figure 2.
Te security stripe shown in Figure 2 clearly meets its goals of compatibility. Current TIFF reading programs can
Figure 2: Encoded contextual information and security keys incorporated as part of an image. This is a prototype version of the Security Stripe, which is 40 lines high. Companion and authentication data are encoded into grayscale values in a reserved region of caption portion of a single image. In this example each pixel is given an 8-bit ASCII character value (in an 8-bit image). In this 2k wide image, the strip can incorporate 2,000 characters per line, so this data strip has a capacity of 80 kB. A Unicode version would typically require 4 pixels to represent a character. However this is more than enough space to record typical experimental conditions, sample information, facility, and authorship.
www.microscopy-today.com • 2010 September
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76