================================ Image Delta Stream (IDS) draft 3 ================================ Sun 19 Jan 1997 Adam M. Costello Contributors: Glenn Randers-Pehrson All contributors to MNG draft 32. This proposal leaves out some details of chunk layout and exception handling. IDS is just a name for this draft, not a suggestion for the name of a real format. Contents ======== Changes from the Previous Draft Design Goals Format Non-Pixel Operations Pixel Operations Changes from the Previous Draft =============================== Changes from draft 2: Removed the Motivating Thoughts chapter. Removed the Relation to DOH chapter. Removed the Comparison with PND chapter (it will appear separately). Added the Design Goals chapter. Changed IDEL. Renamed the Stream Format chapter to Format, and subdivided it. Completely revamped the way non-pixel data is altered. Renumbered the orientation field values in CPIX. Design Goals ============ An IDS may be applied to a parent PNG to produce a child PNG, or the same IDS may be applied to a parent concrete image to produce a child concrete image. An IDS can be designed to work with a variety of parent PNGs or images, but there is no requirement that an IDS must work with every possible parent. The applier of the IDS needs only streaming access to the IDS, but may need random access to the parent PNG or image. Format ====== ::= IDEL IHDR ( DROP | DBYK | ORDR )* * IEND ::= | IDAT+ | * | ( CPIX* * ) ::= EPIX IDAT+ IDEL: image delta Source ID Pixel operation (replace/edit/copy-and-edit) Deepening function (left-bit-replication/zero-fill) If the pixel operation is , and the pixel data portion must be a sequence of one or more IDAT chunks. All fields of the IHDR are significant, and need bear no relation to the parent. If the pixel operation is , the width and height must match those of the parent, the bit depth and color type must not be less than those of the parent, and the remaining IHDR fields are ignored. The pixel data portion must be a sequence of zero or more pixel edits (see EPIX). The pixel data of the parent is used to initialize the pixel data of the child, but the edits can then alter the pixel data. If the pixel operation is , the width and height need not match those of the parent, the bit depth and color type must not be less than those of the parent, and the remaining IHDR fields are ignored. The pixel data portion must be a sequence of zero or more CPIX chunks followed by a sequence of zero or more pixel edits (see EPIX). The pixel data portion is obligated to overwrite the entire child pixel array, because it is not initialized. The CPIX chunks can copy pixels from the parent. The less-than relation on color types is defined by the following partial order: RGBA / \ RGB GA / \ / indexed G RGBA is the greatest color type. Non-Pixel Operations -------------------- Immediately following the IHDR is a sequence of zero or more DROP, DBYK, and ORDR chunks, followed by zero or more PNG chunks. These tell the applier of the delta what chunks other than IHDR, IDAT, and IEND should appear in the child PNG, and where. This portion of the IDS can also be used to determine changes to be made to a concrete image. DROP: drop chunks Chunk name All chunks in the parent with the specified name are inhibited from being copied into the child. If multiple name appear in DROP, it is shorthand for multiple DROP chunks. DBYK: drop by keyword Chunk name Polarity (only/all-but) Keywords (null-separated text strings) The chunk name must be the name of a chunk that begins with a null-terminated text string. Some parent chunks with the specified chunk name are inhibited from being copied into the child. If polarity is , then any parent chunk whose keyword appears in the keywords list is inhibited. If polarity is , then any parent chunk whose keyword does not appear in the keywords list is inhibited. ORDR: ordering restrictions Chunk name Order type ORDR informs the applier of the IDS of the ordering restrictions for chunks. The order type may take the following values: 0: anywhere 1: after IDAT 2: before IDAT 3: before IDAT, but not before PLTE 4: before IDAT, but not after PLTE Critical chunk names may not appear in ORDR, since the applier needs to know everything about them anyway. If a chunk name appears in ORDR, it is a promise that any chunk of that name appearing in the parent which is not inhibited by DROP/DBYK will not be broken by this IDS, and therefore the applier must copy it into the child at a location compatible with its ordering restrictions. After all the DROP, DBYK, and ORDR chunks there may appear zero or more PNG chunks other than IHDR, IDAT, and IEND. For any that are ancillary (i.e. any other than PLTE), their names must have appeared in an ORDR chunk, so that the applier knows where they can be placed in the child. If any ancillary chunk appears in the parent, and it is not inhibited, and its name does not appear in ORDR, then the applier should copy it into the child only if it knows the chunk well enough to be sure that it is consistent with the changes made by the IDS, and knows where it may be placed in the child. Those conditions are always true of safe-to-copy chunks. If any critical chunk defined in neither this specification nor the PNG specification appears in the parent or in the IDS, it is a fatal error unless the applier knows how to handle it. The specification of the critical chunk may include provisions for this scenario. If the IDS is being applied to a concrete image rather than a PNG, the ORDR chunks can be ignored. The DROP, DBYK, and PNG chunks indicate what changes need to be made to the parent image in order to produce the child. Pixel Operations ---------------- If the child color type does not equal the parent color type, then the applier needs to promote the pixel data before it can perform pixel copying or editing. The cases are: G -> GA Don't change the gray values. Set all the alpha values to fully opaque, except for pixels marked transparent by cheap transparency--set their alpha values to fully transparent. Discard the cheap transparency information. RGB -> RBGA Don't change the RGB values. Handle the alpha values as in the G -> GA promotion. G -> RGB Set R, G, and B equal to the gray value. Apply the same operation to the cheap transparency information (if any). GA -> RGBA Set R, G, and B equal to the gray value. Don't change the alpha values. G -> RGBA Set R, G, and B equal to the gray value. Handle alpha values as in the G -> GA promotion. indexed -> RGB Set R, G, and B according to the palette entry corresponding to the index. Discard the cheap transparency information (if any). indexed -> RGBA Set R, G, and B as in indexed -> RGB. Set the alpha value according to the cheap transparency information (if any). Discard the cheap transparency information. If the bit depth has been changed, values may need to be deepened. The applier must use left-bit-replication or zero-fill according to the deepening function in IDEL. Remember that if the color type has been promoted from indexed, the parent bit depth is considered to be 8. In some cases, the parent pixel array can be mutated (destructively) into the child pixel array. In others, the parent pixel array can be discarded as soon as the child array is initialized. But if the pixel operation is , the parent array is still needed while the copies are being performed. All pixel copies must preceed all pixel edits. Copies and edits must be processed sequentially in order of appearance. CPIX: copy pixels Source X Source Y Width Height Destination X Destination Y Orientation Copy a rectangle of pixels from the parent pixel array into the child pixel array. The source X and Y values are in the parent's coordinate system, while the destination X and Y values are in the child's coordinate system. The destination point specifies where the original upper-left pixel of the rectangle falls in the child image. The orientation is one of: 0: 1 2 -> 1 2 3 4 3 4 1: 1 2 -> 4 3 3 4 2 1 2: 1 2 -> 3 1 3 4 4 2 3: 1 2 -> 2 4 3 4 1 3 4: 1 2 -> 2 1 3 4 4 3 5: 1 2 -> 3 4 3 4 1 2 6: 1 2 -> 1 3 3 4 2 4 7: 1 2 -> 3 2 3 4 4 1 Notice that bit 2 indicates whether the rectangle is mirrored, bit 1 indicates whether it is sideways, and bit 0 indicates whether the original upper-left corner ends up at the top or the bottom. EPIX: edit pixels Destination X Destination Y Width Height Edit type Compression method Filter method Interlace method EPIX is followed by a sequence of IDATs containing (width * height) pixels, filtered, interlaced, and compressed (see the PNG specification). Those pixels are used to modify a rectangle within the child pixel array, whose upper-left corner is given by the destination X and Y. The bit depth and color type are not specified by EPIX because they must match those of the child pixel array (except as noted below). The nature of the modification is specified by the edit type, which is one of: The pixels in the IDATs replace the pixels in the child array. The pixels in the IDATs are used to increment the pixels in the child array. The addition is by sample, modulo 2^bitdepth. The pixels in the IDATs use color type G, and are used to replace the alpha values in the child array. The pixels in the IDATs use color type G, and are used to increment the alpha values in the child array. The addition is by sample, modulo 2^bitdepth.