CN1265318C - Data package template with data embedding - Google Patents

Abstract

This invention describes a universal data packet template that allows data to be encoded and printed in any shape using a specific encoding scheme. The data packet template includes a readable, fixed background of arbitrary shape that determines the location and orientation of the data area. The data in the template consists of multiple points and is encoded for extraction of the stored information.

Description

Data package template with data embedding

technical field

The present invention relates to a packet template or tag with data embedding, in particular to a point-based packet template format structure or tag format structure (TFS).

Background technique

Various methods, systems and apparatus related to the present invention are disclosed in the following related patent applications. These patent applications were filed simultaneously with the present invention by the applicant or assignee of the present invention on May 24, 2000:

PCT/AU00/00518, PCT/AU00/00519, PCT/AU00/00520, PCT/AU00/00521,

PCT/AU00/00523, PCT/AU00/00524, PCT/AU00/00525, PCT/AU00/00526,

PCT/AU00/00527, PCT/AU00/00528, PCT/AU00/00529, PCT/AU00/00530,

PCT/AU00/00531, PCT/AU00/00532, PCT/AU00/00533, PCT/AU00/00534,

PCT/AU00/00535, PCT/AU00/00536, PCT/AU00/00537, PCT/AU00/00538,

PCT/AU00/00539, PCT/AU00/00540, PCT/AU00/00541, PCT/AU00/00542,

PCT/AU00/00543, PCT/AU00/00544, PCT/AU00/00545, PCT/AU00/00547,

PCT/AU00/00546, PCT/AU00/00554, PCT/AU00/00556, PCT/AU00/00557,

PCT/AU00/00558, PCT/AU00/00559, PCT/AU00/00560, PCT/AU00/00561,

PCT/AU00/00562, PCT/AU00/00563, PCT/AU00/00564, PCT/AU00/00566,

PCT/AU00/00567, PCT/AU00/00568, PCT/AU00/00569, PCT/AU00/00570,

PCT/AU00/00571, PCT/AU00/00572, PCT/AU00/00573, PCT/AU00/00574,

PCT/AU00/00575, PCT/AU00/00576, PCT/AU00/00577, PCT/AU00/00578,

PCT/AU00/00579, PCT/AU00/00581, PCT/AU00/00580, PCT/AU00/00582,

PCT/AU00/00587, PCT/AU00/00588, PCT/AU00/00589, PCT/AU00/00583,

PCT/AU00/00593, PCT/AU00/00590, PCT/AU00/00591, PCT/AU00/00592,

PCT/AU00/00594, PCT/AU00/00595, PCT/AU00/00596, PCT/AU00/00597,

PCT/AU00/00598, PCT/AU00/00516, PCT/AU00/00517 and

PCT/AU00/00511

The disclosures of these similar patent applications are summarized here by cross-reference.

In addition, various methods, systems, and apparatuses related to the present invention are disclosed in the following comparable PCT applications. These PCT applications were filed concurrently with the present invention by the applicant or assignee of the present invention:

PCT/AU00/00754, PCT/AU00/00755 and PCT/AU00/00756.

The disclosures of these similar applications are summarized here by cross-reference.

Of particular relevance to the present invention is the PCT patent application entitled "Print Page Mark Encoder" (Application No. PCT/AU00/00517), hereinafter referred to by our reference number PEC02.

Today, almost everything you buy from a store has some sort of barcode on the packaging. Barcodes provide a convenient method of identifying items by product number. The exact interpretation of the product number depends on the type of barcode. The inventory tracking system allows users to define their own product number ranges. However, the items in the store must be coded more generally so that one company's product code does not conflict with another company's product code.

Barcodes themselves come in various formats. Older barcode formats consist of symbols displayed as lines. The combination of black and white lines describe the information contained in the barcode. Typically, there are two types of lines that make up a complete barcode: the symbol lines (the message itself) and the lines that separate the symbol blocks to facilitate optical recognition. Although the information may vary from barcode to barcode, the lines that separate the symbol blocks are the same. Therefore, the lines used to separate symbol blocks can be considered as part of the fixed structural elements of the barcode.

Barcodes are read by specialized reading devices such as light pens, gun readers, scanners, etc. These reading devices extract the data into a computer for further processing.

To ensure that the extracted data can be read correctly, checksums are often used as an easy method of error detection. Newer barcode formats use some kind of redundant encoding scheme, such as the Reed-Solomon encoding method. One such encoding scheme is employed in the Aztec 2D barcode described in US 5,591,956 patent. In general, the degree of redundancy of encoding is selectable by the user.

The information in a 2D barcode is encoded in 2 dimensions, rather than storing information as a series of lines (data stored as lines is extracted in one dimension). Like barcodes before them, 2D barcodes also contain information and structural elements that facilitate optical recognition. An example of a Quick Response (QR) code is shown in Figure 1. This coding scheme was invented by Denso of Japan and disclosed in US 5,726,435 patent. It should be noted that the barcode unit consists of two areas: a data area (related to the data stored in the barcode) and a fixed position detection pattern. The reader uses a fixed position detection pattern to locate the barcode cell itself, and then locates the border of the barcode cell, thereby determining the original orientation of the barcode cell. The basis for determining the direction is: there are only 3 corner patterns in a barcode unit, and there is no fourth corner pattern.

One problem associated with the range of applications of barcodes is that barcode generation hardware can only generate certain barcode formats. As printers become more embedded, there is a growing desire to be able to print barcodes whenever and wherever they are needed.

Contents of the invention

It is an object of the present invention to provide a data package template with data embedding.

Another object of the present invention is to provide a generic markup format structure capable of supporting a generic encoding scheme.

Other objects of the present invention can be further understood through the following discussion and accompanying drawings.

The present invention relates to a method of encapsulating data in a general data packet template formed by a plurality of points, the method comprising the following steps:

constructing for each point position in the above data packet a bit array of entries, the array of entries determining whether each of the above points is part of an arbitrarily shaped fixed background pattern or part of an arbitrarily shaped data region;

Encode the above data and store the encoded data in the above data area:

Print multiple points encoded with the above data.

Description of drawings

In order to better understand and apply the present invention, the present invention is described below using preferred embodiments of the present invention in conjunction with the accompanying drawings, wherein:

Figure 1 shows a previous 2-dimensional quick response code;

Figure 2 shows a Netpage mark background pattern;

Figure 3 shows the data area marked by Netpage in Figure 2;

Figure 4 is an enlarged view of the Netpage markup at 1600dpi resolution.

Figure 5 shows the output resolution effect of a markup element;

Figure 6 shows the data representation in the 2-dimensional quick response code;

Figure 7 shows a simple 3×3 marker structure;

FIG. 8 is an extension of the markers in FIG. 7 .

Detailed ways

In this patent application, the term "marker" refers to the combination of data and any other elements used to accommodate, locate or read data (such as position detection patterns, blank areas, surrounding areas, etc.). Thus, a markup contains the following elements:

• At least one data area. This data area is what generates the markup. The tag data area contains encoded data (either redundantly encoded or processed using simple checksum encoding). The data bits are placed in the data area, whose location is determined by the tag encoding scheme.

• Fixed background pattern, which usually contains a fixed position detection pattern. This background pattern helps the tag reader locate the tag. They contain elements that help with orientation and, for 2D marks, the background pattern may also contain orientation and perspective information. Fixed background patterns may also contain elements such as blank space around data areas or position detection patterns. These blank patterns help to encode data by eliminating interference between data regions.

For ease of description, here we use a commonly used optical recognition method (such as a barcode scanner, etc.) to illustrate the data packet template. It should be understood, however, that the concepts of the present invention are equally applicable to tactile recognition, and even voice recognition.

Most marking schemes have some sort of fixed background pattern, but it is not required. For example, if a physical space is used to surround the marked data area and some non-optical positioning mechanism is used as the means of reading (eg the surface of the barcode is somehow physically aligned relative to the data reader), then no position detection pattern is required.

Different mark encoding schemes produce marks of different sizes and divide the physical mark area into different fixed position detection patterns and data areas. For example, the QR code shown in FIG. 1 uses three fixed blocks 10 on the edge of the mark as position detection patterns, and the rest of the patterns are data areas 11 . In contrast, the Netpage markup structure shown in Figures 2, 3 and 4 contains a circular positioning element 20, a direction element 21, and several data fields. Figure 2 shows a resolution-independent Netpage marker fixed background pattern. The content shown in FIG. 3 is the same as that in FIG. 2, but a data area 30 is added in the Netpage markup. Figure 4 is an example of a dot layout with a Netpage markup of 1600dpi. In Figure 4, a data bit is represented by a number of physical output points that form a block in the data area.

The data area contains tagged data. Each data bit in the data area may be represented by multiple physical printed dots, depending on the marking scheme. The actual number of points representing a data bit depends on the output resolution and the corresponding read/scan resolution. Figure 5 shows the effects of different resolutions of a line in a conventional barcode. When drawn at resolution R, a line might be 2 dots wide and 5 dots high, but when drawn at 2x resolution, the line has double the number of dots in both width and length.

For another example, for the QR code shown in Figure 1, a data bit is represented by a dark or bright color block, where the number of dots in the dark or bright color block is related to the resolution of the drawing, and also to the corresponding reading/scanning resolution related. For example, each data block in FIG. 6 is represented by a square with printed dots (a square filled with dots 60 represents a binary 1, and an empty square 61 represents a binary 0).

Thus, a bit of data in a printed mark can be represented by a certain printed shape. The smallest shape is a printed dot, while the largest shape can be an entire mark. For example, a large dot consists of multiple printed dots in both length and width directions.

An ideal general mark definition structure should allow a specific print shape to be produced for each data bit.

For raw data of a certain number of bits, to be able to put these data into a printed mark for later retrieval by a reading/scanning device, these data bits can be placed directly in the mark, or they can be manipulated in some form. Redundant coding. The exact form of redundant encoding depends on the format of the tag.

The placement scheme of the data bits in the marked data area is directly related to the redundancy mechanism employed in the encoding scheme. The data bits can be placed in 2D so that the probability of accidental error of the data is evenly distributed throughout the marked data area. For example, all the data bits of a Reed-Solomon codeword can be scattered throughout the tag data area to minimize the effects of occasional errors.

Since the data encoding scheme is directly related to the shape and size of the tag data area, it is best to use a common tag format structure. In this way, various markup formats can be rendered using the same data structure and rendering method.

The Tag Format Structure (TFS) of the present invention is a point-based packet template. It allows defining arbitrarily shaped packets of points and how to store the data itself as points in the packet. TFS is optimized so that real-time delineation of markers is possible. TFS provides an entry for each point position within the marker boundary, which determines whether the corresponding point is part of a fixed background pattern (which usually contains a fixed position detection pattern) or part of a data element of the marker.

TFS provides an entry for each point position within the marker boundary, and in this respect it is very similar to a bitmap. Therefore, TFS has TagHeight x TagWidth entries, where TagWidth corresponds to the size of the tag's bounding box in the row direction, and TagWidth corresponds to the size of the tag's bounding box in the column direction. A TFS entry line that is marked is called a marked line structure.

TFS has the following relevant parameters:

· TagWidth is the width of the tag's bounding box (number of points);

· TagHeight is the height of the tag's bounding box (number of points);

· EntryWidth is the number of digits in each entry of TFS (minimum 2);

• NumTagDataBits is the number of data bits (minimum 0) associated with each tag.

In order to encode a specific markup, the data to be inserted into that markup needs to be provided:

• TagData is an array of NumTagDataBits bits containing the actual data to be stored into the tag's data area. These bits have preferably been redundantly coded according to a tag coding scheme.

Each entry in TFS is interpreted by its lowest bit (bit 0):

• If bit 0 is cleared (=0), then the dots output for this entry are part of a fixed background pattern. The pip value itself comes from bit 1. If the first bit is 0, then the output value is 0; if the first bit is 1, then the output value is 1.

• If bit 0 is set (=1), then the points output for this entry come from the TagData array. The remaining bits of this entry (bit 1 through NumTagDataBits-1) contain the address of the TagData bits to use.

Each entry in TFS is interpreted independently, they are not related to state information. This is very important because only then can random reads of all entries be supported so that multiple paint engines can work on different parts of the page at the same time (e.g. a tag can be assigned to two or more paint engines) .

If the printed dot size is too small, there is some way to enlarge the mark. It is possible to enlarge the tag itself by N times in both length and width, but this will increase the number of entries in TFS. Alternatively, the output of the TFS generator can be scaled up using standard bitmap scaling techniques—for example, by pixel duplication or averaging over large samples, etc.

For example, if the original TFS is 21x21 entries, and the scaling method used is to simply enlarge each original point to 2x2 points, then the TFS will become 42x42 entries. To generate a new TFS from an old TFS, the entries in each row of the TFS should be repeated, and then each row of the TFS should be repeated. In the above case, the net entry count of TFS will increase to 4 times (2×2).

TFS allows for large points, not simple scaling. Please refer to Figure 7, which shows a simple example of 3×3 dot marking. At this point we need to print a large image of the marker, where each point is represented by 7×7 print points. If the length and width of the original TFS are replicated 7 times (increase the size of the TFS to 7 times or enlarge the output of the marker generator), then 9 sets of 7×7 squares need to be generated. Here, we can also replace each point in the original TFS with 7×7 dots. Figure 8 shows this result.

Therefore, the higher the resolution of the TFS, the more dots are printed for each large dot, where each large dot represents one data bit of the marker. The more dots that produce large dots, the more complex the pattern of large dots. For example, Figure 4 shows a Netpage markup structure in which each data bit is represented by a pattern of 8×8 dots (at 1600dpi resolution), but the actual structure of the dots is not a square. In this way, the Netpage mark can be read in any direction.

Figure 7 shows a simple example where the mark consists of 9 dots. Among them, 3 dots form a fixed background pattern, which is used to help position the marker, and the remaining 6 dots are used as data. This means we can store 6 bits of data in that tag.

However, assuming that in the above tag the raw data bits are encoded redundantly with their inverses, then the 6 bits in the tag actually represent 3 raw data bits. For example, if the 3 raw data bits are 111, then the 6 data bits in the tag should be 101010. If the 3 raw data bits are 101, then the 6 data bits in the tag should be 100110.

The relationship of point positions in the marker has to take into account the redundant encoding of the data. In the simple example above, the topmost line of markers is always 111. The second line of markers contains the first two data bits. According to the data encoding scheme used, we know that the first two digits must be reversed. So while the second line of markings could be 101, 011, 100, or 010, it will never be 111. The same goes for line 3 of the marker. Therefore, when the mark is produced, the fixed pattern of 111 will not appear in the mark except for the above predetermined fixed area.

The following parameters summarize this simple marking scheme:

· TagWidth=3

·TagHeight=3

·EntryWidth=4 (1+3, 1 is used for low order, 3 is used for indexing 6 data bits)

· NumTagDataBits = 6

Please refer to Figure 7. The first row of TFS should be 0010, 0010, 0010, which represent fixed bits and have nothing to do with the stored data. The first entry of line 2 in TFS should be 0001, indicating that the content of bit 0 of the tag's TagData array should be output to this point. The second entry in line 2 should be 0011, representing the content of the first bit of the TagData array to be output at this point. The 3rd entry on line 2 should be 0101, representing the content of the 2nd digit.

The first entry of line 3 in TFS should be 1001, indicating that the content of the fourth bit of the TagData array should be output to this point. The second entry (line 2, entry 2) of line 3 should be 1011, representing the fifth bit of the TagData array, and the third entry of line 3 in TFS (should be line 2, entry 3) 0111, representing The third bit of the tag's TagData array should be output at this point.

So the whole TFS should be (in entry order):

          0010, 0010, 0010

           0001, 0011, 0101

                                  1001, 1011, 0111

Note that codes 1101 and 1111 are not used in this TFS because they point to data bits 6 and 7 which do not exist (only data bits 0-5 in this example).

The above TFS can generate a tag for any 6-bit data, that is, any 6-bit long TagData array. If these 6 bits are 101010, then at the above 9 dot positions, the output of the marker encoder should be:

1 (fixed)

1 (fixed)

1 (fixed)

1 (obtained from data bit 0)

0 (obtained from data bit 1)

1 (obtained from data bit 2)

1 (obtained from data bit 4)

0 (obtained from data bit 5)

0 (obtained from data bit 3)

If the 6 data bits are 100110, then at the above 9 dot positions, the output of the marker encoder should be:

1 (fixed)

1 (fixed)

1 (fixed)

1 (obtained from data bit 0)

0 (obtained from data bit 1)

0 (obtained from data bit 2)

1 (obtained from data bit 4)

0 (obtained from data bit 5)

1 (obtained from data bit 3)

Please refer to Figure 1 again, where the QR code mark is a pattern of 21 blocks by 21 blocks. If each block is made up of one dot, the QR code is a 21-dot×21-dot pattern. In addition, there are 249 data blocks in the data area, representing 249 bits. At this time, both the basic parameters TagWidth and TagHeight can be set to =21. EntryWidth=9 (1+8, 1 is used for low bits, 8 is used for indexing 249 data bits), NumTagDataBits=249. Therefore, the tag format structure should be 441 entries (21×21), where each entry is 9 bits. The first 7 entries should be 000000010, which define output point constant 1, and the 8th entry should be 000000000, which defines output point constant 0. The next entry should be xxxxxxxx1, where xxxxxxxx are the addresses of the bit numbers that represent the 9th block of the first row. If the block is from bit 129 of 249 data bits, then xxxxxxxx should be 10000001. If the data block comes from the 62nd bit of 249 data bits, then xxxxxxxx should be 00111110. In this TFS, there are a total of 5 data entries followed by 000000000, and 7 lines end with 000000010.

The second line of the tag format structure starts with 00000010, followed by five 0000090000 entries, one 00000010 entry, and one 000000000 entry respectively representing 8 fixed data output points 1, 0, 0, 0, 0, 0, 1 and 0, followed by The 5 entries point to individual bits of the 249 data bits in row 2 of the tag.

The last line of the tag format structure has seven 00000010 entries, one 000000000 entry, and 13 more entries pointing to the respective data bits in the last row of the tag. TagData is a 249-bit array that contains the actual data to be stored into the tag data area. These bits must have been redundantly encoded according to the QR mark encoding scheme.

The tag format structure of the present invention can be implemented using the tag encoder disclosed in the aforementioned comparable PCT application, reference number PEC02. The following briefly explains how the marker encoder works.

Marker Encoders (TE) are used to support marker applications. It usually requires the printhead to use IR ink (although in some cases K ink or other inks can be used instead). The mark encoder encodes fixed data and specific mark data values for the page to be printed. It converts this data into an error-correctable mark that can then be printed on the page using infrared or black ink. The marker encoder can arrange the markers into a triangular grid vertically or horizontally, and the basic marker structure is depicted with a resolution of 1600dpi. At the same time, the marker data can be encoded as a large point of a certain shape (the minimum size is 1 under 1600dpi point).

The marker encoder takes the following inputs:

· a portrait/landscape sign;

A template that defines the markup structure;

Several fixed data bits (fixed for pages);

A flag indicating whether to redundantly encode the fixed data bits or to treat the fixed data bits as encoded data;

- a number of variable data bit records, wherein each record contains variable data bits in a particular row of marks;

• A flag indicating whether variable data bits are redundantly encoded or treated as encoded data.

The output of the marker encoder (TE) is a 1600dpi double layer, which is used to store marker data. The output of the tag encoder is realized through a 1-bit wide first-in-first-out queue (FIFO). The mark can then be printed using infrared ink so that the printed mark can be read by mark detection equipment.

Although the tag encoder (TE) is conceptually designed to allow tags to have variable structures and fixed and variable data elements, the tag encoder has certain restrictions on the range of encoding parameters. These limits are directly related to the buffer size and addressing bits chosen for most encoding applications. It is easy to adjust the size of the buffer and the corresponding addressing mode to determine encoding parameters for other applications.

The marker encoder writes a dual-layer marker bit stream to a dual-level marker first-in-first-out queue (FIFO). The marker encoder is responsible for merging the encoded marker data with the basic marker structure and arranging the points in the output FIFO in the correct order for subsequent printing. Encoded tagged data is generated in real-time from raw data to reduce cache space requirements.

The TagData array is divided into fixed elements and variable elements. For example, if a tag contains 512 bits of data, some of these bits may be fixed for all tags, while others may be different for different tags. For example, a Universal product code contains a country code and a company code. Since these bits do not vary with tags, these bits can be preloaded into the tag generator in order to reduce bandwidth requirements when generating a large number of tags. Another example is the Netpage tag generator. A printed page contains several Netpage tags. The form of these tags is shown in Figure 2-4. The page identifier (page-ID) is fixed for all tags, while the remaining data bits vary from tag to tag. By reducing the amount of variable data transferred to the tag encoder, the overall bandwidth requirements of the encoder can be reduced.

Some parameters of a marker encoder may be implicit or explicit, depending on the specific implementation of the encoder, and the parameters of a marker encoder may also have restrictions on the allowed marker size. For example, a software tag encoder may have no limit on the size of the tag, while some hardware tag encoders may have some limit on the maximum number of tag data bits.

A Tag Encoder may only accept the base, non-redundantly encoded Data bits and encode them, rather than accepting all TagData bits encoded by some external encoder. This saves significant bandwidth. In the case of Netpage tags (as described in similar PCT application PEC02), only 120 bits of raw data are provided for each tag, and the tag encoder encodes these 120 bits into 360 bits. The bandwidth requirement can be reduced by 2/3 by embedding the redundant encoder into the marker encoder.

In the TFS description above, bit 0 indicates whether the output point is stored immediately with the entry (bit 1 contains the value of the output bit) or the higher bits are taken as the address of the indexed TagData structure. Using different bit positions to represent the same information is a small change.

To reduce storage requirements for certain types of tags, TFS can use double indirection. In the above description, when bit 0 of a TFS entry is set, the higher bits constitute the address of the corresponding bit in the TagData array. However, if the total number of entries in the TFS is large, and the maximum number of different bits for a particular row of the TFS is much less than NumTagDataBits, then it is convenient to use double indirection.

With double indirection, TFS's data address entry points to another array, which is stored at the end of the TFS row. This array contains the actual addresses in the TagData array to use. For example, if only 8 different data bits are used on a particular row of a tag, then the EntryWidth can be set to 4 (with 1 bit determining whether to index the data bit or use the 1st bit directly). If bit 0 is 1, then bits 1-3 are used to form an address 0-7. This address points to an 8xn-bit entry table of the TagData array. If there are 512 entries in the TagData array, then n=9. If TagWidth=100, it indicates that the basic encoding scheme uses 1000 bits (100×10 bits) for each row of TFS. If double indirect addressing is used, then each row of TFS requires 472 bits (100*4 bits+8*9 bits). This can save about 50% of the storage capacity, which is very valuable. The amount of memory saved by using double indirect addressing is application dependent.

Another variation is that the dual layer output can be changed to a continuous tone output. In the present invention, each output point is either 1 or 0. If bit 0 is 0, then bit 1 contains the output bit to use. This scheme can be easily extended to include larger numbers of bits. For example, if you need to use 4-bit continuous tone printing, if bit 0 is 0, then the output is 4 bits composed of bits 1-3. Of course, EntryWidth should also be increased accordingly.

Likewise, the address to the TagData array can also point to the nth entry, where the nth entry is not 1 bit, but a number of bits (depending on the number of bits in each contone output point).

If the entire TFS is stored locally (e.g. on a chip), the data in it can be used row-by-row or column-by-column for horizontal or vertical printing. If the tag format structure is not stored locally (for example in off-chip memory), then the data in it can be read 1 row at a time, in which case it is best to have two copies of the tag format structure - one for One for landscape printing and another for portrait printing.

For example, in the similar PCT application PEC02, the marker encoder is an application specific integrated circuit chip, and the TFS is in the external DRAM. To reduce the internal storage requirements on the ASIC, it is loaded with TFS one row at a time. Since TFS is read row by row, two TFS structures need to be saved in external DRAM - one for portrait printing and one for landscape printing. In theory, the two TFS structures are different, but in fact, they are the same TFS, but one of them is rotated 90 degrees.

The purpose of the above description is only to illustrate the preferred embodiments of the present invention, and should not be construed as any limitation to the present invention. Those skilled in the art can easily implement various changes based on the specific embodiments of the present invention, but any equivalent modification or modification according to the present invention shall fall within the scope of the present invention.

Claims (5)

1. A method for encapsulating data in a generic data packet template formed by a plurality of points, the method comprising the steps of: constructing an entry bit array for each point position in said data packet, the entry array determining whether said each point is part of an arbitrarily shaped fixed background pattern or part of an arbitrarily shaped data region; Encoding the data, and storing the encoded data in the data area; Print a number of points encoded with said data. 2. The method according to claim 1, wherein the dot-by-dot double-layer dot printing is performed. 3. The method of claim 1, wherein the dots are printed by contone dots. 4. The method of claim 1, wherein the encoding comprises redundant encoding. 5. The method of claim 1, wherein said encoding comprises double indirect addressing.

Images