*** mng-0.97-20000227-pdg.txt Tue Sep 5 13:25:16 2000 --- proposed-mng-0.97f-20000905-pdg.txt Tue Sep 5 13:21:56 2000 *************** *** 1,21 **** ! MNG (Multiple-image Network Graphics) Format Version 0.97 For list of authors, see Credits (Chapter 18). Status of this Memo ! This document is a specification by the PNG development group. - It has been approved by a vote of the group, and future technical changes - will require formal approval by a vote of the group. It is the intent of the - group to maintain backward compatibility if possible. We will, however, - correct any technical deficiencies discovered in the course of developing - "beta" implementations. - Comments on this document can be sent to the PNG specification maintainers at one of the following addresses: ! * mpng-list@ccrc.wustl.edu * png-group@w3.org * png-info@uunet.uu.net --- 1,16 ---- ! MNG (Multiple-image Network Graphics) Format Version 0.97f For list of authors, see Credits (Chapter 18). Status of this Memo ! This is a DRAFT proposal for voting purposes. Depending on the outcome of ! voting, some version of this document will become version 0.98. Comments on this document can be sent to the PNG specification maintainers at one of the following addresses: ! * mng-list@ccrc.wustl.edu * png-group@w3.org * png-info@uunet.uu.net *************** *** 26,45 **** ftp://swrinde.nde.swri.edu/pub/mng/documents/. ! Changes from sixty-ninth MNG draft (mng-0.96-19990717) ! * Revised wording about frame count and layer count in MNG-VLC ! datastreams. ! * Clarified that the BACK chunk components are always written as though ! for an RGBA PNG with 16-bit sample depth. ! * Added a statement that MNG editors that create a series of PNG or JNG ! files are expected to execute loops, including the TERM-created loop, ! only "iteration_min" times. ! * Clarified that show_mode 6 and 7 causes the cycle to jump back to the ! beginning when the end of the range is reached. An example of how to ! create forward and back-and-forth cycles with SHOW has been inserted. ! * Fixed some typos. Abstract This document defines the MNG (Multiple-image Network Graphics) format. It --- 21,89 ---- ftp://swrinde.nde.swri.edu/pub/mng/documents/. ! Changes from seventieth MNG draft (mng-0.97-20000228) ! * Added new filter methods REQUIRES APPROVAL ! ! o 1, "implicit none" ! o 32, intra-pixel differencing to improve compressibility. ! o 48, intra-pixel differencing and leveling. ! o 64, leveling. ! ! * Added MAGN chunk. REQUIRES APPROVAL ! ! * Relocated misplaced TERM chunk in Example 14. ! ! * Added a note that top-level color-space chunks do not have any effect ! on already-decoded objects. ! ! * Changed "immediately after the MHDR chunk" to "very shortly after the ! MHDR chunk" in the nEED chunk specification. ! ! * Clarified some wording in the SEEK chunk specification, and added a ! cross reference to the existing requirement to insert a background ! layer when making random access to a segment. ! ! * Added JDAA chunk to carry a JPEG-encoded alpha channel, and revised the ! "Alpha compression type" accordingly, to add type 8. REQUIRES APPROVAL ! ! * Disallow the JSEP chunk when image_sample_depth != 20 ! ! * Fixed typo in JNG signature bytes, to be the decimal equivalent of ! "JNG" instead of "PNJ". ! ! * It is permitted to change the potential visibility, location, and ! clipping boundaries of "frozen" objects, provided that the encoder ! writes chunks to restore them to their "frozen" values prior to the end ! of the segment. REQUIRES APPROVAL ! ! * Clarified treatment of the alpha sample in the BASI chunk when the ! color type is 0, 2, or 3, and clarified that the BASI chunk inherits ! default DEFI values if no DEFI chunk is present. ! ! * Global sRGB nullifies preceding global gAMA and cHRM, and vice versa. ! REQUIRES APPROVAL ! ! * Added a terminology entry for "nullify". ! ! * Added "background transparency", "semitransparency", and "stored ! objects" flags to the simplicity profile, and revised the definitions ! of MNG-LC and MNG-VLC to allow the new transparency flags to be 1. ! REQUIRES APPROVAL ! ! * Added some discussion of background transparency when the MNG is being ! displayed over a changing scene. ! ! * Allow the new JDAA JPEG-encoded alpha channel to be used in Delta-PNG ! to convey a replacement alpha channel. REQUIRES APPROVAL + * Mentioned possibility of infinity as value of "Iteration max" in the + TERM chunk. + + * Changed "Repeat count" to "Iteration count" in the LOOP chunk + specification, and added a definition of "iteration" in the terminology + section. REQUIRES APPROVAL + Abstract This document defines the MNG (Multiple-image Network Graphics) format. It *************** *** 103,109 **** + 4.2.6. CLON Clone an object + 4.2.7. DHDR, Delta-PNG chunks, IEND + 4.2.8. PAST Paste an image into another ! + 4.2.9. DISC Discard objects o 4.3. Critical MNG image displaying chunks + 4.3.1. BACK Background + 4.3.2. FRAM Frame definitions --- 147,154 ---- + 4.2.6. CLON Clone an object + 4.2.7. DHDR, Delta-PNG chunks, IEND + 4.2.8. PAST Paste an image into another ! + 4.2.9. MAGN Magnify objects ! + 4.2.10. DISC Discard objects o 4.3. Critical MNG image displaying chunks + 4.3.1. BACK Background + 4.3.2. FRAM Frame definitions *************** *** 124,138 **** o 5.1. Critical JNG chunks + 5.1.1. JHDR JNG header + 5.1.2. JDAT JNG image data ! + 5.1.3. IDAT JNG alpha data ! + 5.1.4. IEND End of JNG datastream ! + 5.1.5. JSEP 8-bit/12-bit image separator o 5.2. Ancillary JNG chunks * 6. The Delta-PNG Format o 6.1. Delta-PNG critical chunks - + 6.1.1. DHDR Delta-PNG datastream header - + 6.1.2. IEND End of Delta-PNG datastream - + 6.1.3. PROM Promotion of parent object + 6.1.4. IHDR PNG image header + 6.1.5. IPNG Incomplete PNG + 6.1.6. PLTE and tRNS --- 169,180 ---- o 5.1. Critical JNG chunks + 5.1.1. JHDR JNG header + 5.1.2. JDAT JNG image data ! + 5.1.3. IDAT JNG PNG-encoded alpha data ! + 5.1.4. JDAA JNG JPEG-encoded alpha data ! + 5.1.5. IEND End of JNG datastream o 5.2. Ancillary JNG chunks * 6. The Delta-PNG Format o 6.1. Delta-PNG critical chunks + 6.1.4. IHDR PNG image header + 6.1.5. IPNG Incomplete PNG + 6.1.6. PLTE and tRNS *************** *** 140,149 **** + 6.1.8. JHDR JNG image header + 6.1.9. IJNG Incomplete JNG + 6.1.10. DROP Drop chunks - + 6.1.11. DBYK Drop chunks by keyword + 6.1.12. ORDR Ordering restrictions o 6.2. Ancillary Delta-PNG chunks - + 6.2.1. gAMA, cHRM, iCCP, sRGB Color space chunks + 6.2.2. oFFs and pHYs + 6.2.3. Other ancillary PNG chunks o 6.3. Chunk ordering requirements --- 182,189 ---- *************** *** 159,165 **** o 9.3. Immediate frame sync point o 9.4. Embedded images in LOOPs o 9.5. Including optional index in SAVE chunk ! o 9.6. Interleaving JDAT and IDAT chunks * 10. Recommendations for Decoders o 10.1. ENDL without matching LOOP o 10.2. Note on compositing --- 199,205 ---- o 9.3. Immediate frame sync point o 9.4. Embedded images in LOOPs o 9.5. Including optional index in SAVE chunk ! o 9.6. Interleaving JDAT, JDAA, and IDAT chunks * 10. Recommendations for Decoders o 10.1. ENDL without matching LOOP o 10.2. Note on compositing *************** *** 178,186 **** o 12.3. Uniform Resource Identifier (URI) * 13. Rationale * 14. Revision History ! o 14.1. Version 0.97 ! o 14.2. Version 0.96 ! o 14.3. Version 0.95 * 15. References * 16. Security Considerations * 17. Appendix: Examples --- 218,232 ---- o 12.3. Uniform Resource Identifier (URI) * 13. Rationale * 14. Revision History ! o 14.1. Version 0.97f ! o 14.2. Version 0.97e ! o 14.3. Version 0.97d ! o 14.4. Version 0.97c ! o 14.5. Version 0.97b ! o 14.6. Version 0.97a ! o 14.7. Version 0.97 ! o 14.8. Version 0.96 ! o 14.9. Version 0.95 * 15. References * 16. Security Considerations * 17. Appendix: Examples *************** *** 201,206 **** --- 247,253 ---- o 17.15. Example 15: Converting a simple GIF animation o 17.16. Example 16: Counting layers and frames o 17.17. Example 17: Storing an icon library + o 17.18. Example 18: MAGN chunks and ROI * 18. Credits 1. Introduction *************** *** 213,219 **** [PNG] and the JPEG (Joint Photographic Experts Group) specifications. The PNG specification is available at the PNG web site, ! http://www.cdrom.com/pub/png/ A MNG datastream describes a sequence of zero or more single frames, each of which can be composed of zero or more embedded images or directives to show --- 260,266 ---- [PNG] and the JPEG (Joint Photographic Experts Group) specifications. The PNG specification is available at the PNG web site, ! http://www.libpng.org/pub/png/ A MNG datastream describes a sequence of zero or more single frames, each of which can be composed of zero or more embedded images or directives to show *************** *** 282,288 **** MNG does not yet accommodate sound or complex sequencing information, but these capabilities might be added at a later date, in a backward-compatible ! manner. These issues are being discussed in the mpng-list@ccrc.wustl.edu mailing list. Chunk structure (length, name, data, CRC) and the chunk-naming system are --- 329,335 ---- MNG does not yet accommodate sound or complex sequencing information, but these capabilities might be added at a later date, in a backward-compatible ! manner. These issues are being discussed in the mng-list@ccrc.wustl.edu mailing list. Chunk structure (length, name, data, CRC) and the chunk-naming system are *************** *** 342,347 **** --- 389,398 ---- * It allows composition of frames containing multiple images. + * It can achieve 1000:1 and higher lossy compression of Megapixel + truecolor images. While some detail is lost, such highly-compressed + images are useful as full-scale previews and for layout work. + * It facilitates the use of images as "sprites" or groups of images as "animated sprites" that can be reused in subsequent frames. *************** *** 367,372 **** --- 418,427 ---- * JNG provides JPEG with transparency, alpha, and color space information. + * Used together with a magnification chunk, JNG can achieve 1000:1 and + higher compression of megapixel truecolor images. While these are very + lossy, they could be useful as previews and in layout work. + * Multiple-image GIF files can be losslessly converted to MNG, and, (except for those using the "restore-to-previous" disposal method) can be losslessly converted to MNG-LC and (except for those with a variable *************** *** 396,402 **** abstract image or object An image whose pixels have a hidden representation, and which does not necessarily carry PNG or JNG chunk data. An image delta cannot be ! applied to an abstract image. All abstract objects are viewable. child, or child image An image produced by applying an image delta to a parent object. --- 451,458 ---- abstract image or object An image whose pixels have a hidden representation, and which does not necessarily carry PNG or JNG chunk data. An image delta cannot be ! applied to an abstract image. All abstract objects are viewable. Object ! 0 is always abstract, since it is never stored. child, or child image An image produced by applying an image delta to a parent object. *************** *** 465,470 **** --- 521,532 ---- frame. There is no interframe delay prior to the implicit background layer at the beginning of the animation nor after the final frame. + iteration + One cycle of a loop. In this document, as is customary among computer + programmers, the number of iterations of a loop includes the first + cycle. A loop can have zero iterations, which means it is not executed + at all. + layer A layer can be o A visible embedded image, located with respect to the frame *************** *** 502,512 **** loops can all be run once, JNG and Delta-PNG are not present, and certain MNG chunks are not present. Bit 0 of the MHDR simplicity profile must be 1, indicating that the profile is valid, and all other ! bits of the profile except possibly for bits 2 and 3 must be 0, ! indicating that "complex MNG features", JNG, and Delta-PNG are not ! present. Bits 2 and 3 can be 0 or 1, depending on whether "simple MNG ! features" and transparency are absent or present. MNG-LC is a proper ! subset of MNG. MNG-VLC A very-low-complexity version of MNG in which only image 0 is --- 564,574 ---- loops can all be run once, JNG and Delta-PNG are not present, and certain MNG chunks are not present. Bit 0 of the MHDR simplicity profile must be 1, indicating that the profile is valid, and all other ! bits of the profile except possibly for bits 2, 3, 6, 7, and 8 must be ! 0, indicating that "complex MNG features", JNG, and Delta-PNG are not ! present. Bits 2, 3, 6, 7, and 8 can be 0 or 1, depending on whether ! "simple MNG features" and transparency are absent or present. MNG-LC is ! a proper subset of MNG. MNG-VLC A very-low-complexity version of MNG in which only image 0 is *************** *** 513,522 **** permitted, loops can all be run once, JNG and Delta-PNG are not present, and certain MNG chunks are not present. Bit 0 of the MHDR simplicity profile must be 1, indicating that the profile is valid, and ! all other bits of the profile except possibly for bit 3 must be 0, ! indicating that "simple MNG features", "complex MNG features", JNG, and ! Delta-PNG are not present. Bit 3 can be 0 or 1, to indicate whether ! transparency is absent or present. MNG-VLC is a proper subset of MNG. object, object_id An image or a nonviewable basis object. The object_id is an unsigned --- 575,590 ---- permitted, loops can all be run once, JNG and Delta-PNG are not present, and certain MNG chunks are not present. Bit 0 of the MHDR simplicity profile must be 1, indicating that the profile is valid, and ! all other bits of the profile except possibly for bits 3, 6, 7, and 8 ! must be 0, indicating that "simple MNG features", "complex MNG ! features", JNG, and Delta-PNG are not present. Bits 3, 6, 7, and 8 can ! be 0 or 1, to indicate whether transparency is absent or present. ! MNG-VLC is a proper subset of MNG. ! ! nullify ! To nullify a chunk is to undo its effect, restoring the datastream to ! the condition it would have had if the chunk being nullified had never ! appeared. object, object_id An image or a nonviewable basis object. The object_id is an unsigned *************** *** 559,564 **** --- 627,636 ---- Any segment other than the first (also the first segment, when there is only one). + replicate + to make an additional copy. If you replicate something M-1 times, you + end up with M of them. + segment A part of a MNG datastream starting with the MHDR chunk or with a SEEK chunk and extending to just before the next SEEK chunk (or the MEND *************** *** 578,586 **** of the layers making up a complete frame. viewable image ! A stored object that is capable of being made visible. An image is ! viewable, while some objects resulting from decoding a BASI datastream ! are not viewable. visible image Actually drawn on a display. If an object is visible, a person looking --- 650,658 ---- of the layers making up a complete frame. viewable image ! A stored object or embedded object that is capable of being made ! visible. An image is viewable, while some objects resulting from ! decoding a BASI datastream are not viewable. visible image Actually drawn on a display. If an object is visible, a person looking *************** *** 659,664 **** --- 731,739 ---- chunk. When an embedded object is "potentially visible," it can be displayed "on-the-fly" as it is being decoded. Later, the SHOW chunk can direct that a "potentially visible" viewable object be displayed. + It is permitted to change the potential visibility of "frozen" objects; + if this is done, the potential visibility must be restored by the + encoder prior to the end of the segment. Object is viewable. An object is viewable if it has a viewable object buffer. It is *************** *** 677,687 **** Location. The X and Y location of an object is determined by the DEFI chunk that ! introduced it, and can be changed by the MOVE chunk. Clipping boundaries. The clipping boundaries of an object are determined by the DEFI chunk ! that introduced it, and can be changed by means of the CLIP chunk. 3.3. Object buffers --- 752,774 ---- Location. The X and Y location of an object is determined by the DEFI chunk that ! introduced it, and can be changed by the MOVE chunk. It is permitted to ! change the location of "frozen" objects, provided that the encoder ! includes a MOVE chunk prior to the end of the segment that restores ! their locations to their "saved" positions. Clipping boundaries. The clipping boundaries of an object are determined by the DEFI chunk ! that introduced it, and can be changed by means of the CLIP chunk. It ! is permitted to change the clipping boundaries of "frozen" objects, ! provided that the encoder includes a CLIP chunk prior to the end of the ! segment that restores the boundaries to their "saved" values. ! ! Additional information. ! While not required by this specification, applications may wish to ! store other information about the object, such as whether it is ! eligible to be updated by block-alpha-addition, for error-checking ! purposes. 3.3. Object buffers *************** *** 699,704 **** --- 786,798 ---- be made available to the rest of the MNG datastream or be considered viewable after it has been processed. + When the "stored objects" flag (bit 9 of the simplicity profile) is 0 and + valid (i.e., bit 6 is 1 and bit 9 is 0), an object buffer need not be + created even when an embedded object with a nonzero object_id appears, since + the flag promises that the object buffer will never be used. There is no + requirement not to create an object buffer; no harm will be done except for + some unnecessary memory consumption. + Object buffer is viewable. Any object that points to a viewable object buffer can be displayed, but one that points to a nonviewable one cannot. Any attempt to do so *************** *** 751,759 **** + A decoder that recreates PNG or JNG files from a series of PNG, JNG, and Delta-PNG datastreams will also have to store the contents of any unknown chunks that it finds, in case ! they turn out to be safe to copy (see DROP (Paragraph ! 6.1.10), DBYK (Paragraph 6.1.11), and ORDR (Paragraph ! 6.1.12), below). o An abstract image. An abstract image can be stored by the decoder in any form that is convenient, such as an X Window System --- 845,852 ---- + A decoder that recreates PNG or JNG files from a series of PNG, JNG, and Delta-PNG datastreams will also have to store the contents of any unknown chunks that it finds, in case ! they turn out to be safe to copy (see DROP (Paragraph 6.1.7), ! DBYK, and ORDR (Paragraph 6.1.8), below). o An abstract image. An abstract image can be stored by the decoder in any form that is convenient, such as an X Window System *************** *** 845,853 **** (must be 0 in MNG-LC and MNG-VLC datastreams) bit 3: ! 0: transparency is absent or can be ! ignored. ! 1: transparency is present and is essential (critical) for proper display of the images. bit 4: --- 938,949 ---- (must be 0 in MNG-LC and MNG-VLC datastreams) bit 3: ! 0: Transparency is absent. No ! image in the datastream has ! transparency, or its transparency ! can be ignored and all images ! can be rendered as opaque. ! 1: Transparency is present and is essential (critical) for proper display of the images. bit 4: *************** *** 860,866 **** 1: Delta-PNG is present. (must be 0 in MNG-LC and MNG-VLC datastreams) ! bits 6-15: Reserved for public expansion. Must be zero in this version. bits 16-30: --- 956,996 ---- 1: Delta-PNG is present. (must be 0 in MNG-LC and MNG-VLC datastreams) ! bit 6: Validity flag for bits 7, 8, and 9 ! 0: The presence or absence of ! background transparency, stored ! objects, and semitransparency is ! unspecified. ! 1: Background transparency is ! expressed by bit 7, semitransparency ! by bit 8, and the presence of stored ! objects by bit 9. ! bit 7: ! 0: Background transparency is absent ! (i.e., the first layer fills the ! entire MNG frame with opaque pixels) ! or can be ignored. ! 1: Background transparency is present ! and is essential (critical) for ! proper display of the images. ! bit 8: ! 0: Semitransparency (i.e., an image ! with an alpha channel that has ! values that are neither 0 nor the ! maximum value) is present or can ! be dithered down to binary ! transparency. ! 1: Semitransparency is present and is ! essential (critical) for proper ! display of the images. Full alpha ! composition rather than dithering is ! required. ! bit 9: ! 0: Stored objects are not present. ! 1: Stored objects are present. ! (must be 0 in MNG-LC and MNG-VLC ! datastreams) ! bits 10-15: Reserved for public expansion. Must be zero in this version. bits 16-30: *************** *** 927,940 **** If the simplicity profile is nonzero, it can be regarded as a 32-bit profile, with bit 0 (the least significant bit) being a "profile-validity" ! flag, bit 1 being a "simple MNG" flag, bit 2 being a "complex MNG" flag, bit ! 3 being a "transparency" flag, bit 4 being a "JNG" flag, and bit 5 being a ! "Delta-PNG" flag. The upper 15 bits (except for the most significant bit, ! which must be zero) are available for private test or experimental versions, ! and the remaining bits are reserved for future MNG versions, and must be ! zero in this version. If a bit is zero, the corresponding feature is ! guaranteed to be absent, and if a bit is one, the corresponding feature may ! be present in the MNG datastream. When bit 1 is zero ("simple" MNG features are absent), the datastream does not contain the DEFI, FRAM, or global PLTE and tRNS chunks. --- 1057,1070 ---- If the simplicity profile is nonzero, it can be regarded as a 32-bit profile, with bit 0 (the least significant bit) being a "profile-validity" ! flag, bit 1 being a "simple MNG" flag, bit 2 being a "complex MNG" flag, ! bits 3, 7, and 8 being a "transparency" flags, bit 4 being a "JNG" flag, bit ! 5 being a "Delta-PNG" flag, and bit 9 being a "stored objects" flag. The ! upper 15 bits (except for the most significant bit, which must be zero) are ! available for private test or experimental versions, and the remaining bits ! are reserved for future MNG versions, and must be zero in this version. If a ! bit is zero, the corresponding feature is guaranteed to be absent, and if a ! bit is one, the corresponding feature may be present in the MNG datastream. When bit 1 is zero ("simple" MNG features are absent), the datastream does not contain the DEFI, FRAM, or global PLTE and tRNS chunks. *************** *** 954,971 **** if they are present they are not essential (or critical) for displaying the images. A MNG-LC (i.e., a "low-complexity MNG") datastream must have a simplicity ! profile with bit 0 equal to 1 and all other bits except possibly for bits 1 ! and 3 ("simple MNG" MNG features and transparency) equal to zero. If bit 4 ! (JNG) is 1, the datastream is a "MNG-LC with JNG" datastream. MNG-LC ! decoders are allowed to reject such datastreams unless they have been ! enhanced with JNG capability. A MNG-VLC (i.e., a "very low-complexity MNG") datastream must have a simplicity profile with bit 0 equal to 1 and all other bits except possibly ! for bit 3 (transparency) equal to 0. If bit 4 (JNG) is 1, the datastream is ! a "MNG-VLC with JNG" datastream. MNG-VLC decoders are allowed to reject such ! datastreams unless they have been enhanced with JNG capability. Encoders that write a nonzero simplicity profile should endeavor to be accurate, so that decoders that process it will not unnecessarily reject --- 1084,1131 ---- if they are present they are not essential (or critical) for displaying the images. + "Semitransparency is absent or can be dithered" means that if the MNG or PNG + tRNS chunk is present and any PNG or JNG image has an alpha channel, they + only contain the values 0 and the maximum (opaque) value, or that if other + values are present the decoding application is allowed to dither them down + to binary transparency. The "semitransparency" flag means nothing and must + be 0 if bit 6 is 0. + + "Background transparency is absent or can be ignored" means that the first + layer fills the entire frame with opaque pixels, or if any part of the first + layer is not filled with an opaque pixel, the application is free to fill it + with a color of its own choosing. Whatever is behind the first layer need + not show through, or it is not essential (or critical) that it do so. + + When "Background transparency" is present, the application is responsible + for supplying a background color or image against which the MNG background + layer is composited, and if the MNG is being displayed against a changing + scene, the application should refresh the entire MNG frame against a new + copy of the background layer whenever the application's background scene + changes. The "background transparency" flag means nothing and must be 0 if + bit 6 is 0. + + The "stored objects" flag is only useful when bit 2 is nonzero (i.e., + "complex MNG features" are present). This flag promises that even though + such features are present, it is never necessary to store an object buffer + for any object. An object attributes set is necessary for each object, + however. Therefore, the MOVE, CLIP, DISC, deterministic LOOP, partial CLON, + and immediately-displayed BASI chunk are permissible. The "stored objects" + flag means nothing and must be 0 if bit 6 is 0. + A MNG-LC (i.e., a "low-complexity MNG") datastream must have a simplicity ! profile with bit 0 equal to 1 and all other bits except possibly for bits 1, ! 3, 6, and 7 ("simple MNG" MNG features and transparency) equal to zero. If ! bit 4 (JNG) is 1, the datastream is a "MNG-LC with JNG" datastream that ! carries an image or an alpha channel. MNG-LC decoders are allowed to reject ! such datastreams unless they have been enhanced with JNG capability. A MNG-VLC (i.e., a "very low-complexity MNG") datastream must have a simplicity profile with bit 0 equal to 1 and all other bits except possibly ! for bits 3, 6, and 7 (transparency) equal to 0. If bit 4 (JNG) is 1, the ! datastream is a "MNG-VLC with JNG" datastream. The JNG datastream might ! carry an image or an alpha channel. MNG-VLC decoders are allowed to reject ! such datastreams unless they have been enhanced with JNG capability. Encoders that write a nonzero simplicity profile should endeavor to be accurate, so that decoders that process it will not unnecessarily reject *************** *** 989,995 **** contents are the first two or more of the following fields: Nest level: 1 byte (unsigned integer). ! Repeat count: 4 bytes (unsigned integer), range [0..2^31-1]. Termination condition: 1 byte (unsigned integer). --- 1149,1155 ---- contents are the first two or more of the following fields: Nest level: 1 byte (unsigned integer). ! Iteration count: 4 bytes (unsigned integer), range [0..2^31-1]. Termination condition: 1 byte (unsigned integer). *************** *** 1257,1305 **** See the PNG specification [PNG] and the Extensions to the PNG Specification document [PNG-EXT] for the format of the PNG chunks. ! Any chunks between IHDR and IEND are written and decoded according to the ! PNG specification. ! ! If a global PLTE chunk appears in the top-level MNG datastream, the PNG ! datastream can have an empty PLTE chunk, to direct that the global PLTE and ! tRNS data be used. If an empty PLTE chunk is not present, the data is not ! inherited. MNG applications that recreate PNG files must write the global ! PLTE chunk rather than the empty one in the output PNG file, along with the ! global tRNS data if it is present. The global tRNS data can be subsequently ! overridden by a tRNS chunk in the PNG datastream. It is an error for the PNG ! datastream to contain an empty PLTE chunk when the global PLTE chunk is not ! present or has been nullified. ! ! If the PNG sRGB, gAMA, iCCP, or cHRM chunks appear in the top-level MNG ! datastream (and have not been nullified), but none of them appear in the PNG ! datastream, then the values are inherited from the top level as though the ! chunks had actually appeared in the PNG datastream. Data from such chunks ! appearing in the PNG datastream take preference over the inherited values. ! If any one of these chunks, or any future chunk that defines the color ! space, appears in the PNG datastream, none of them is inherited. MNG ! applications that recreate PNG files must write these chunks, if they are ! inherited, in the output PNG files. If the sRGB chunk is present in a MNG ! datastream, it need not be accompanied in the MNG datastream by gAMA and ! cHRM chunks, despite the recommendation in the PNG specification. Any MNG ! viewer that processes the gAMA chunk must also recognize and process the ! sRGB chunk. It can treat it as if it were a gAMA chunk containing the value ! .45455 and it can ignore its "intent" field. If the sRGB chunk is present in ! the MNG datastream, editors that write PNG datastreams should add the gAMA ! and cHRM chunks to the PNG datastream, even though they are not present in ! the MNG datastream. ! ! If the PNG sPLT chunk appears in the top-level MNG datastream, it takes ! preference over any sPLT chunk appearing in the PNG datastream. MNG ! applications that recreate PNG files should not copy top-level sPLT chunks ! to the output PNG files, because a suggested palette for rendering a group ! of images is not necessarily the best palette for rendering a single image. ! ! The PNG oFFs and pHYs chunks and any future chunks that attempt to set the ! pixel dimensions or the drawing location must be ignored by MNG viewers and ! simply copied (according to the copying rules) by MNG editors. ! The PNG gIFg, gIFt, and gIFx chunks must be ignored by viewers and must be ! copied according to the copying rules by MNG editors. If do_not_show=0 for the image when the IHDR chunk is encountered, a viewer can choose to display the image while it is being decoded, perhaps taking --- 1417,1561 ---- See the PNG specification [PNG] and the Extensions to the PNG Specification document [PNG-EXT] for the format of the PNG chunks. ! The IHDR and IEND chunks and any chunks between them are written and decoded ! according to the PNG specification, except as extended in this section. ! These extensions do not apply to standalone PNG datastreams that have the ! PNG signature, but only to PNG datastreams that are embedded in a MNG ! datastream that begins with a MNG signature and the MHDR chunk. ! ! * If a global PLTE chunk appears in the top-level MNG datastream, the PNG ! datastream can have an empty PLTE chunk, to direct that the global PLTE ! and tRNS data be used. If an empty PLTE chunk is not present, the data ! is not inherited. MNG applications that recreate PNG files must write ! the global PLTE chunk rather than the empty one in the output PNG file, ! along with the global tRNS data if it is present. The global tRNS data ! can be subsequently overridden by a tRNS chunk in the PNG datastream. ! It is an error for the PNG datastream to contain an empty PLTE chunk ! when the global PLTE chunk is not present or has been nullified. ! ! * Additional PNG filter methods are defined: ! ! 1: Implicit "none" filtering of every scanline; ! filter bytes are omitted from the compressed ! datastream in the IDAT chunk(s). ! 32: Adaptive filtering with five basic types ! and intra-pixel differencing. The leveling ! is implicitly (0,0,0,0). ! 48: Adaptive filtering with five basic types, ! intra-pixel differencing, and leveling. ! A set of level samples appears immediately ! prior to the filter byte for the first ! scanline in the IDAT chunk. ! 64: Adaptive filtering with five basic types ! and leveling, but without intrapixel ! differencing. ! ! This transformation, which is a modification of a method previously ! used in the LOCO image format [LOCO], is ! ! S0 = Red - Green - Red_level (for color_type 2 or 6) ! or ! Index - Index_level (for color_type 3) ! or ! Gray - Gray_level (for color_type 0 or 4) ! S1 = Green - Green_level (for color_type 2 or 6) ! or ! Alpha - Alpha_level (for color_type 4) ! S2 = Blue - Green - Blue_level (for color_type 2 or 6) ! S4 = Alpha - Alpha_level (for color_type 6) ! ! The transformation is done in integer arithmetic in sufficient ! precision to hold intermediate results, and the result is stored modulo ! the sample depth. Intrapixel differencing (subtracting the green ! sample) is only done for color types 2 and 6, and only when the filter ! method is 32 or 48. When the filter type is 48 or 64, the level values ! are inserted at the beginning of the compressed datastream contained in ! the IDAT chunk, immediately ahead of the first filter byte for the ! first row of pixels. WHen the filter type is 32, the level values are ! not included in the IDAT chunk and are implicitly all zero. ! ! [Experiments with putting a separate level set ahead of each filter ! byte have not been promising; the savings in filesize was offset by the ! extra storage for the level sets.] ! ! The level set contains 16-bit samples if the image sample depth is 16, ! otherwise it contains 8-bit samples. In indexed-color images, the level ! is applied to the raw palette index, not to the decoded colors. When ! the sample depth is less than 8, it is not an error for the level to be ! greater than 127; the modulo arithmetic will simply ignore the most ! significant bits. ! ! In tests, the set (132, 0, 132) has worked well with a large set of ! truecolor images. [should this be the default set, instead of ! (0,0,0,0)?] It has been demonstrated to improve the compressibility of ! natural images by 10 to 15 percent of the compressibility of RGB data. ! This seems to be due to the intra-pixel correlation between color ! samples, which is ignored by the PNG filters. ! ! The RGB samples are recovered, after undoing the basic filtering, by ! the inverse of the transformation, which for RGBA images is ! ! Green = S1 + Green_level ! Red = S0 + Red_level + Green ! Blue = S2 + Blue_level + Green ! Alpha = S4 + Alpha_level ! ! As in the forward transformation, the inverse transformation is done in ! integer arithmetic in sufficient precision to hold intermediate ! results, and the result taken modulo the sample depth. ! ! Applications that convert a MNG datastream to a series of PNG ! datastreams must convert any PNG datastream with one of the additional ! filter methods to a standard PNG datastream with a PNG filter method ! (currently 0 is the only valid filter method). ! ! It is suggested that encoders write a "nEED MNG-1.0" chunk if they use ! this feature, for the benefit of pre-MNG-1.0 decoders. ! ! Applications must not write independent PNG datastreams (with either ! the .png or .mng file extension) with these new filter methods, unless ! they should become officially approved for use in PNG datastreams. For ! experimenting and testing, applications can use a value greater than ! 128 for this purpose, as permitted in the PNG specification. ! ! * If the PNG sRGB, gAMA, iCCP, or cHRM chunks appear in the top-level MNG ! datastream (and have not been nullified), but none of them appear in ! the PNG datastream, then the values are inherited from the top level as ! though the chunks had actually appeared in the PNG datastream. Data ! from such chunks appearing in the PNG datastream take preference over ! the inherited values. If any one of these chunks, or any future chunk ! that defines the color space, appears in the PNG datastream, none of ! them is inherited. MNG applications that recreate PNG files must write ! these chunks, if they are inherited, in the output PNG files. If the ! sRGB chunk is present in a MNG datastream, it need not be accompanied ! in the MNG datastream by gAMA and cHRM chunks, despite the ! recommendation in the PNG specification. Any MNG viewer that processes ! the gAMA chunk must also recognize and process the sRGB chunk. It can ! treat it as if it were a gAMA chunk containing the value .45455 and it ! can ignore its "intent" field. If the sRGB chunk is present in the MNG ! datastream, editors that write PNG datastreams should add the gAMA and ! cHRM chunks to the PNG datastream, even though they are not present in ! the MNG datastream. ! ! Note that the top-level color space chunks are used only to supply ! missing color space information to PNG or JNG datastreams when the ! datastreams are being decoded. They do not have any effect on ! already-decoded objects. ! ! * If the PNG sPLT chunk appears in the top-level MNG datastream, it takes ! preference over any sPLT chunk appearing in the PNG datastream. MNG ! applications that recreate PNG files should not copy top-level sPLT ! chunks to the output PNG files, because a suggested palette for ! rendering a group of images is not necessarily the best palette for ! rendering a single image. ! ! * The PNG oFFs and pHYs chunks and any future chunks that attempt to set ! the pixel dimensions or the drawing location must be ignored by MNG ! viewers and simply copied (according to the copying rules) by MNG ! editors. ! * The PNG gIFg, gIFt, and gIFx chunks must be ignored by viewers and must ! be copied according to the copying rules by MNG editors. If do_not_show=0 for the image when the IHDR chunk is encountered, a viewer can choose to display the image while it is being decoded, perhaps taking *************** *** 1306,1319 **** advantage of the PNG interlacing method, or to display it after decoding is complete. ! If object_id=0, there is no need to store the pixel data after displaying ! it. If concrete_flag=1 and object_id != 0, the decoder must store the original pixel data losslessly, along with data from other recognized PNG chunks, because it is possible that a subsequent Delta-PNG datastream might want to modify it. If concrete_flag=0, the decoder can store the pixel data in any ! form that it chooses. If an object already exists with the same object_id, the contents of its object buffer are replaced with the new data. --- 1562,1577 ---- advantage of the PNG interlacing method, or to display it after decoding is complete. ! If object_id=0, there is no need to store the pixel data after decoding it ! and perhaps displaying it. If concrete_flag=1 and object_id != 0, the decoder must store the original pixel data losslessly, along with data from other recognized PNG chunks, because it is possible that a subsequent Delta-PNG datastream might want to modify it. If concrete_flag=0, the decoder can store the pixel data in any ! form that it chooses. If the "stored objects" flag in the simplicity profile ! is valid and zero, there is no need to store the pixel data and other chunk ! data after decoding and perhaps displaying the image. If an object already exists with the same object_id, the contents of its object buffer are replaced with the new data. *************** *** 1325,1332 **** See the JNG specification below (Chapter 5) for the format of the JNG datastream. ! Any chunks between JHDR and IEND are written and decoded according to the ! JNG specification. The remaining discussion in the previous paragraph about PNG datastreams also applies to JNG datastreams. --- 1583,1590 ---- See the JNG specification below (Chapter 5) for the format of the JNG datastream. ! The JHDR and IEND chunks and any chunks between them are written and decoded ! according to the JNG specification. The remaining discussion in the previous paragraph about PNG datastreams also applies to JNG datastreams. *************** *** 1361,1384 **** 0: Basis object is not viewable. 1: Basis object is viewable. The alpha_sample can be omitted if the viewable field is also omitted. If so, and the color_type is one that requires alpha, the alpha value corresponding to an opaque pixel will be used. If the color samples are ! omitted, zeroes will be used. The decoder is responsible for converting the ! color and alpha samples to the appropriate format and sample depth for the ! specified color_type. When color_type=3, the decoder must generate a palette ! of length 2sample_depth, whose first entry contains the given {red_sample, ! green_sample, blue_sample} triple, and whose remaining entries are filled ! with zeroes. If the viewable field is omitted, the object is not viewable. The color and alpha samples are written as four sixteen-bit samples regardless of the color_type and sample_depth. When the sample_depth is less than sixteen, the least significant bits are used and the remaining bits must be zero filled. When color_type=3, the least significant byte of each ! color sample is used and the upper byte must be zero. When color_type=0 or ! color_type=4, the green and blue samples must be present but must be ignored ! by decoders. The BASI datastream contains PNG chunks, but is not necessarily a PNG datastream. It can be incomplete or empty and it can deviate in certain ways from the PNG specification. It can serve as a parent object for a Delta-PNG --- 1619,1658 ---- 0: Basis object is not viewable. 1: Basis object is viewable. + The sample depth, color type, compression method, filter type, and interlace + type must be valid PNG types, and the width and height must be within the + valid range for PNG datastreams. + The alpha_sample can be omitted if the viewable field is also omitted. If so, and the color_type is one that requires alpha, the alpha value corresponding to an opaque pixel will be used. If the color samples are ! omitted, zeroes will be used. If the viewable field is omitted, the object ! is not viewable. + The decoder is responsible for converting the color and alpha samples to the + appropriate format and sample depth for the specified color_type. + The color and alpha samples are written as four sixteen-bit samples regardless of the color_type and sample_depth. When the sample_depth is less than sixteen, the least significant bits are used and the remaining bits must be zero filled. When color_type=3, the least significant byte of each ! color sample and the alpha sample is used and the upper byte must be zero. ! ! When color_type=0 or color_type=4, the green and blue samples must be ! present but must be ignored by decoders. + When color_type=0 or color_type=2, only the values 0 and 2sample_depth + should be written. Any other alpha value must be interpreted as fully + opaque. + + When color_type=3, the decoder must generate a palette of length + 2sample_depth, whose first entry contains the given {red_sample, + green_sample, blue_sample} triple, and whose remaining entries are filled + with zeroes, together with an alpha array whose first entry is the given + alpha sample and the rest are 255 (i.e., create a one-entry tRNS chunk + containing the least significant byte of the given alpha sample, unless the + given alpha sample is fully opaque). + The BASI datastream contains PNG chunks, but is not necessarily a PNG datastream. It can be incomplete or empty and it can deviate in certain ways from the PNG specification. It can serve as a parent object for a Delta-PNG *************** *** 1398,1405 **** alpha samples. A subsequent Delta-PNG that uses this as the parent object can supply the IDAT chunk or chunks. ! * The PLTE chunk can be omitted or incomplete even when the color_type=3. ! If so, the subsequent Delta-PNG that uses this as the parent object can supply a complete PLTE chunk, if the single-entry palette that is generated is not desired. --- 1672,1679 ---- alpha samples. A subsequent Delta-PNG that uses this as the parent object can supply the IDAT chunk or chunks. ! * The PLTE chunk can be omitted or incomplete even when color_type=3. If ! so, the subsequent Delta-PNG that uses this as the parent object can supply a complete PLTE chunk, if the single-entry palette that is generated is not desired. *************** *** 1406,1421 **** The BASI chunk can be used to introduce such things as a library of faLT chunks from which one or another can be selected for use with any single image, or it can be used to introduce a simple blank or colored rectangle ! into which other images will be pasted by means of the PAST chunk. ! A BASI chunk appearing in a MNG datastream must be preceded by a DEFI chunk ! that gives the object_id, location, and potential visibility for the basis ! object. The concrete_flag can be either 0 (abstract) or 1 (concrete), ! depending on whether the basis image is intended for subsequent use by a ! Delta-PNG datastream or not. When it is abstract it must also be viewable. ! When viewable=1, the resulting image, after the pixel samples are filled in, ! must be a legal PNG image. If viewable=1 and do_not_show=0, a viewer is ! expected to display it immediately, as if it were decoding a PNG datastream. If an object already exists with the same object_id, the contents of its object buffer are replaced with the new data. --- 1680,1697 ---- The BASI chunk can be used to introduce such things as a library of faLT chunks from which one or another can be selected for use with any single image, or it can be used to introduce a simple blank or colored rectangle ! that will be immediately displayed or into which other images will be pasted ! by means of the PAST chunk. ! A BASI chunk appearing in a MNG datastream receives its object_id, location, ! and potential visibility from the preceding DEFI chunk, if one is present, ! or the default values for DEFI, if one is not present. The concrete_flag can ! be either 0 (abstract) or 1 (concrete), depending on whether the basis image ! is intended for subsequent use by a Delta-PNG datastream or not. When it is ! abstract it must also be viewable. When viewable=1, the resulting image, ! after the pixel samples are filled in, must be a legal PNG image. If ! viewable=1 and do_not_show=0, a viewer is expected to display it ! immediately, as if it were decoding a PNG datastream. If an object already exists with the same object_id, the contents of its object buffer are replaced with the new data. *************** *** 1681,1688 **** simultaneously updating and displaying the destination_id, the MOVE and CLIP for the destination_id is used in the display operation). ! 4.2.9. DISC Discard objects The DISC chunk can be used to inform the decoder that it can discard the object data associated with the associated object identifiers. Whether the decoder actually discards the data or not, it must not use it after --- 1957,2138 ---- simultaneously updating and displaying the destination_id, the MOVE and CLIP for the destination_id is used in the display operation). ! 4.2.9. MAGN Magnify objects ! ! This chunk provides mandatory magnification factors for existing objects and ! for subsequent embedded images whose object id is 0. ! ! The chunk contains 0 to 18 bytes: ! ! 2 bytes: First magnified object_id ! If omitted, any previous MAGN ! chunk is nullified. ! 2 bytes: Last magnified object_id ! If omitted, last object_id = first ! object_id. ! 1 byte: X Method ! 0: No magnification ! 1: Pixel magnification of color and ! alpha samples ! 2: Linear interpolation of color ! and alpha samples ! 3: Pixel magnification of color ! samples and linear interpolation ! of alpha samples ! 4: Linear interpolation of color ! samples and pixel magnification ! of alpha samples ! If omitted, X Method = 0. ! 2 bytes: MX, X magnification factor, ! range 1-65535. If omitted, MX=0. ! 2 bytes: MY, Y magnification factor. If ! omitted, MY=MX. ! 2 bytes: ML, left X magnification factor ! If omitted, ML=MX. ! 2 bytes: MR, right X magnification factor. ! If omitted, MR=MX. ! 2 bytes: MT, top Y magnification factor. ! If omitted, MT=MY. ! 2 bytes: MB, bottom Y magnification factor. ! If omitted, MB=MY. ! 1 byte: Y method. If omitted, Y method is ! the same as X Method. ! ! The last object_id must be greater than or equal to the first object_id. It ! is not an error to include a nonexistent object or an existing "frozen" ! object in the range; decoders must do nothing to any such objects. If an ! object is potentially visible and viewable, it is displayed immediately ! after it is magnified. If any object_id is nonzero the result of magnifying ! that object is stored in place of the original object for later use. ! ! If the MAGN chunk is present, all existing objects in the specified range ! must conceptually be magnified immediately in accordance with the given ! magnification factors and methods (decoders may wish to save the ! magnification factors and delay the magnification until display time, or ! until the object is used as the parent object of a Delta-PNG, to save ! memory. There is nothing preventing this, provided that the end effect is ! the same as if the magnification had been accomplished immediately). If ! object 0 is in the specified range, then any subsequent embedded objects ! with object_id=0 must be magnified immediately when they appear in the ! datastream. Magnification factors and methods for object 0 are updated by ! the appearance of a subsequent MAGN chunk and magnification of object 0 is ! turned off by the appearance of an empty MAGN chunk. ! ! When X Method is 1, X magnification is done by simple pixel magnification. ! The leftmost pixel of each row is replicated ML-1 times. If the original ! width is greater than 1, the rightmost pixel is replicated MR-1 times. If ! the original width is greater than 2, the original interior pixels are ! replicated MX-1 times. The magnified width W is ! ! W = ML; if (width > 1) W = W + MR; if (width > 2) W = W + (width-2)*MX; ! ! When X Method=2, X magnification is done by linear interpolation between ! pixels. If the original width of the image is greater than 1, the interval ! between the leftmost pixel and the second pixel of each row is subdivided ! into ML intervals by inserting ML-1 pixels with color and alpha values that ! are obtained by linear interpolation. If the original width is 1, then the ! pixel is simply magnified as if X Method=1. If the original width is greater ! than 2, the rightmost interval is subdivided into MR intervals. If the ! original width is greater than 3, each original interior interval is ! subdivided into MX intervals. The magnified width W is ! ! /* The orginal pixels: */ ! W = width; ! /* Add the new pixels in the left interval: */ ! if (width > 1) W = W + ML-1; ! /* Add the new pixels in the right interval: */ ! if (width > 2) W = W + MR-1; ! /* Add the new interior pixels: */ ! if (width > 3) W = W + (width-3)*(MX-1); ! ! When X Method is 3, the color samples are magnified to the same layout as in ! X Method 2, but using replication as in X Method 1. The alpha samples are ! magnified as in X Method 2. ! ! When X Method is 4, the color samples are magnified as in X Method 2. The ! alpha samples are magnified to the same layout as in X Method 2, but using ! replication as in X Method 1. ! ! When Y Method=1, Y magnification is done by simple pixel magnification. The ! topmost pixel of each column is replicated MT-1 times. If the original ! height is greater than 1, the bottom pixel is replicated MR-1 times. If the ! original height is greater than 2, the original interior pixels of each ! column are replicated MY-1 times. The magnified height H is ! ! H = MT; ! if (height > 1) H = H + MB; ! if (height > 2) H = H + (height-2)*MY; ! ! When Y Method=2, Y magnification is done by linear interpolation between ! pixels. If the original height of the image is greater than 1, the interval ! between the topmost pixel and the second pixel of each column is subdivided ! into MT intervals by inserting MT-1 pixels with color and alpha values that ! are obtained by linear interpolation. If the original height is 1, then the ! pixel is simply magnified as if Y Method=1. If the original height is ! greater than 2, the bottom interval is subdivided into MB intervals. If the ! original height is greater than 3, each original interior interval is ! subdivided into MY intervals. The magnified height H is ! ! H = height; ! if (height > 1) H = H + MT-1; ! if (height > 2) H = H + MB-1; ! if (height > 3) H = H + (height-3)*(MY-1); ! ! When Y Method is 3, the color samples are magnified to the same layout as in ! Y Method 2, but using replication as in Y Method 1. The alpha samples are ! magnified as in Y Method 2. ! ! When Y Method is 4, the color samples are magnified as in Y Method 2. The ! alpha samples are magnified to the same layout as in Y Method 2, but using ! replication as in Y Method 1. ! ! When the image being magnified is a concrete object, it must not be a JNG or ! indexed-color PNG (the latter could be promoted to RGB or RGBA via a ! Delta-PNG PROM chunk first). The result of the magnification is also a ! concrete object. The Method 2 magnification is conceptually done first in ! the vertical (Y) direction, the results rounded to the sample depth, then in ! the horizontal (X) direction. Linear interpolation must be done on the raw ! pixels, prior to any color correction, using integer arithmetic, to ensure ! that the result is deterministic. For each channel, the m-1 interpolated ! samples s[i] are obtained from the two samples s0 and s1 by the following ! ISO C code or by any other method that obtains the identical results: ! ! if(s1 == s0) ! for (i=1; i < m; i++) ! s[i] = s0; ! else ! for (i=1; i < m; i++) ! s[i] = ((2*i*(s1-s0)+1)/(m*2) + s0; ! ! Signed arithmetic in a precision large enough to hold the intermediate ! results must be used, and the final results must be modulo the sample depth. ! ! When the image being magnified is an abstract object (which is always true ! of object 0), interpolation can be done by any means that achieves a ! visually similar but not necessarily identical result, such as rounding the ! results to the sample depth later, using Gouraud shading hardware, or using ! floating point addition in the loop instead of integer multiplication and ! division as in: ! ! float delta = ((float)(s1-s0)/(float)m); ! float sf= (float)s0; ! for (i=1; i < m; i++) { ! sf = sf+delta; ! s[i]=(int)(sf+0.5); ! } ! ! If the abstract object being magnified is an indexed-color PNG, it must be ! converted to an RGB or RGBA abstract representation before doing the ! interpolation. ! ! Because the MAGN chunk was added late in the development of MNG-1.0, and ! there is no simplicity flag to signal its presence, it is recommended that ! encoders place an empty MAGN chunk or a nEED MAGN chunk early in the ! datastream, to allow applications to abandon the datastream immediately if ! they do not recognize the MAGN chunk. + 4.2.10. DISC Discard objects + The DISC chunk can be used to inform the decoder that it can discard the object data associated with the associated object identifiers. Whether the decoder actually discards the data or not, it must not use it after *************** *** 1712,1718 **** When the object is a partial clone or is the source of a partial clone that has not been discarded, only the object attribute set (location, potential ! visibility, and clipping boundaries) can be discarded. The data in the object buffer must be retained until the last remaining partial clone is discarded. --- 2162,2168 ---- When the object is a partial clone or is the source of a partial clone that has not been discarded, only the object attribute set (location, potential ! visibility, clipping boundaries, etc.) can be discarded. The data in the object buffer must be retained until the last remaining partial clone is discarded. *************** *** 1761,1767 **** image_id from a previous BACK chunk becomes undefined. This byte must be omitted in MNG-LC and MNG-VLC ! datastreams. Background tiling: 1 byte (unsigned integer). --- 2211,2219 ---- image_id from a previous BACK chunk becomes undefined. This byte must be omitted in MNG-LC and MNG-VLC ! datastreams, and when the "stored ! objects" flag in the simplicity ! profile is valid and zero. Background tiling: 1 byte (unsigned integer). *************** *** 1797,1802 **** --- 2249,2257 ---- displayed the background image, and then displayed the foreground image (or images), without delay. + It is an error to specify a background_image_id when the "stored objects" + flag in the simplicity profile is valid and zero. + It is not an error to specify a background_image_id when such an image does not exist or ceases to exist for some reason. Viewers must be prepared to fall back to using the background color in this event. They also must be *************** *** 2059,2064 **** --- 2514,2528 ---- each image appears. Otherwise, framing_mode=3 is identical to framing_mode=1. + When the background layer is transparent or does not fill the clipping + boundaries of the image layer, the application is responsible for + supplying a background color or image against which the image layer is + composited, and if the MNG is being displayed against a changing scene, + the application should refresh the entire MNG frame against a new copy + of the background layer whenever the application's background scene + changes (see the "background transparency" bit of the simplicity + profile). + Framing mode 4. When framing_mode=4, the background layer is displayed before each frame, i.e., after each FRAM chunk, with no interframe delay before *************** *** 2066,2071 **** --- 2530,2544 ---- elapsed before displaying the background layer. Otherwise, framing_mode=4 is identical to framing_mode=2. + When the background layer is transparent or does not fill the clipping + boundaries of the frame, the application is responsible for supplying a + background color or image against which the subframes are composited, + and if the MNG is being displayed against a changing scene, the + application should refresh the entire MNG frame against a new copy of + the background layer whenever the application's background scene + changes (see the "background transparency" bit of the simplicity + profile). + The subframe name must conform to the same formatting rules as those for a PNG tEXt keyword: It must consist only of printable Latin-1 characters and must not have leading or trailing blanks, but can have single embedded *************** *** 2247,2253 **** It is not an error for the MOVE chunk to name an object that has not previously been defined. In such cases, nothing is done to the nonexistent ! object. When an object is discarded, its object attribute set, which includes the MOVE data, is also discarded. --- 2720,2728 ---- It is not an error for the MOVE chunk to name an object that has not previously been defined. In such cases, nothing is done to the nonexistent ! object. It is permitted to move "frozen" objects provided that the encoder ! includes chunks to move them back to their original positions prior to then ! end of the segment. When an object is discarded, its object attribute set, which includes the MOVE data, is also discarded. *************** *** 2302,2308 **** It is not an error for the CLIP chunk to name an object that has not previously been defined. In such cases, nothing is done to the nonexistent ! object. When an object is discarded, its object attribute set, which includes the CLIP data, is also discarded. --- 2777,2784 ---- It is not an error for the CLIP chunk to name an object that has not previously been defined. In such cases, nothing is done to the nonexistent ! object. It is permitted to clip "frozen" objects provided that another CLIP ! chunk resets them to their original values prior to the end of the segment. When an object is discarded, its object attribute set, which includes the CLIP data, is also discarded. *************** *** 2439,2445 **** It is not an error for the SHOW chunk to name a nonviewable object or an object that has not previously been defined. In such cases, nothing is done ! to the nonexistent object. 4.3.6. TERM Termination action --- 2915,2923 ---- It is not an error for the SHOW chunk to name a nonviewable object or an object that has not previously been defined. In such cases, nothing is done ! to the nonexistent object. It is permitted to change the potential ! visibility of "frozen" objects provided that another SHOW chunk resets them ! to their original values prior to the end of the segment. 4.3.6. TERM Termination action *************** *** 2476,2486 **** ticks, before repeating the animation. Iteration max: 4 bytes (unsigned integer). Maximum ! number of times to repeat the animation. The loop created by processing a TERM must always be treated by the decoder as if it were a cacheable loop, with iteration_min=1. MNG editors that extract a series of PNG or JNG files from a MNG datastream are expected to execute the TERM loop only once, rather than emitting the files repeatedly. --- 2954,2969 ---- ticks, before repeating the animation. Iteration max: 4 bytes (unsigned integer). Maximum ! number of times to execute the animation. ! Infinity is represented by 0x7fffffff. The loop created by processing a TERM must always be treated by the decoder as if it were a cacheable loop, with iteration_min=1. + Applications must not depend on anything that has been drawn on the output + buffer or device during the previous iteration. Its contents become + undefined when the TERM loop restarts. + MNG editors that extract a series of PNG or JNG files from a MNG datastream are expected to execute the TERM loop only once, rather than emitting the files repeatedly. *************** *** 2602,2608 **** decoders to ignore the SAVE/SEEK mechanism. Known chunks in this category include DEFI, FRAM, BACK, PLTE, cHRM, tRNS, ! fPRI, gAMA, iCCP, bKGD, sBIT, pHYg, pHYs, and sRGB. In the case of chunks like sPLT that can occur multiple times, with different "purpose" fields, additional instances of the chunk are permitted --- 3085,3101 ---- decoders to ignore the SAVE/SEEK mechanism. Known chunks in this category include DEFI, FRAM, BACK, PLTE, cHRM, tRNS, ! fPRI, gAMA, iCCP, bKGD, sBIT, pHYg, pHYs, and sRGB. In addition, it is the ! responsibility of the encoder to include chunks that restore the potential ! visibility, location, and clipping boundaries of any "frozen" objects to ! their "saved" condition. ! ! The magnification factors for object 0 must be saved when the SAVE chunk is ! encountered. If an encoder changes them in a segment, it must include ! another MAGN chunk to restore them to their "saved" condition prior to the ! end of the segement. This guarantees that they are safe to use by a decoder ! that reaches a SEEK chunk while sequentially processing a MNG datastream; ! but they must be restored by a decoder that jumps or skips to a SEEK chunk. In the case of chunks like sPLT that can occur multiple times, with different "purpose" fields, additional instances of the chunk are permitted *************** *** 2645,2656 **** 4.4.2. SEEK Seek point ! The SEEK chunk marks positions in the MNG datastream where a restart is ! possible, and where the decoder must restore certain information to the ! condition that existed when the SAVE chunk was processed, if it has skipped ! or jumped to the SEEK chunk. ! The SEEK can be empty, or it can contain a segment name. Segment name: 1-79 bytes (Latin-1 string). --- 3138,3149 ---- 4.4.2. SEEK Seek point ! The SEEK chunk marks positions ("seek points") in the MNG datastream where a ! restart is possible, and where the decoder must restore certain information ! to the condition that existed when the SAVE chunk was processed, if it has ! skipped or jumped to the SEEK chunk. ! The SEEK chunk can be empty, or it can contain a segment name. Segment name: 1-79 bytes (Latin-1 string). *************** *** 2663,2669 **** or displaying keywords (Refer to Security considerations, below, Chapter 16). No specific use for the segment name is specified in this document, but applications can use the segment name for such purposes as constructing a ! menu of SEEK points for a slide-show viewer. It can be included in the optional index that can appear in the SAVE chunk. It is recommended that the same name not appear in any other SEEK chunk or in any FRAM or eXPI chunk. Segment names should not begin with the case-insensitive strings "CLOCK(", --- 3156,3162 ---- or displaying keywords (Refer to Security considerations, below, Chapter 16). No specific use for the segment name is specified in this document, but applications can use the segment name for such purposes as constructing a ! menu of seek points for a slide-show viewer. It can be included in the optional index that can appear in the SAVE chunk. It is recommended that the same name not appear in any other SEEK chunk or in any FRAM or eXPI chunk. Segment names should not begin with the case-insensitive strings "CLOCK(", *************** *** 2677,2682 **** --- 3170,3181 ---- * Anything appearing ahead of the SAVE chunk. + They also must not depend on anything that has been drawn on the output + buffer or device. Its contents become undefined when the SEEK chunk is + encountered. Decoders that make random access to a seek point must insert a + background layer before processing the segment. Encoders must ensure that + simple viewers do not need to do this. + When the SEEK chunk is encountered, the decoder can discard any objects appearing after the SAVE chunk, as though an empty DISC chunk were present. *************** *** 2688,2695 **** Delta-PNG datastream, or it might need data from preceding MOVE or CLIP chunks. ! When the SEEK chunk is encountered, a decoder must restore the information ! that it saved when it processed the SAVE chunk. Multiple instances of the SEEK chunk are permitted. The SEEK chunk must not appear prior to the SAVE chunk. The SAVE chunk must also be present if the --- 3187,3197 ---- Delta-PNG datastream, or it might need data from preceding MOVE or CLIP chunks. ! When a decoder makes random access to a seek point, it must restore the ! information that it saved when it processed the SAVE chunk. When it ! encounters a SEEK chunk during normal sequential processing of a MNG ! datastream, it need not do anything, because the encoder will have written ! chunks that restore all saved information. Multiple instances of the SEEK chunk are permitted. The SEEK chunk must not appear prior to the SAVE chunk. The SAVE chunk must also be present if the *************** *** 2816,2823 **** Separator: 1 byte (null). ...etc... ! The nEED chunk should be placed early in the MNG datastream, preferably ! immediately after the MHDR chunk. The keywords are typically 4-character private critical chunk names, but they could be any string that a decoder is required to recognize. No --- 3318,3325 ---- Separator: 1 byte (null). ...etc... ! The nEED chunk should be placed early in the MNG datastream, preferably very ! shortly after the MHDR chunk. The keywords are typically 4-character private critical chunk names, but they could be any string that a decoder is required to recognize. No *************** *** 2905,2910 **** --- 3407,3416 ---- datastreams, when the datastream does not have its own bKGD, pHYs, or sBIT chunks. + The top-level sRGB chunk nullifies the preceding top-level gAMA and + cHRM chunks, if any, and either the top-level gAMA or the top-level + cHRM chunk nullifies the preceding top-level sRGB chunk, if any. + * sPLT This PNG chunk is also defined at the MNG top level. It provides a *************** *** 2946,2952 **** specification [PNG]. The PNG specification is available at the PNG home page, ! http://www.cdrom.com/pub/png/ A JNG datastream consists of a header chunk (JHDR), JDAT chunks that contain a complete JPEG datastream, optional IDAT chunks that contain a PNG-encoded --- 3452,3458 ---- specification [PNG]. The PNG specification is available at the PNG home page, ! http://www.libpng.org/pub/png/ A JNG datastream consists of a header chunk (JHDR), JDAT chunks that contain a complete JPEG datastream, optional IDAT chunks that contain a PNG-encoded *************** *** 2959,2965 **** single-image JNG datastream can be written in a standalone file. If so, the first eight bytes of a JNG datastream are ! 139 80 78 74 13 10 26 10 (decimal) which is similar to the PNG signature with "\213 J N G" instead of "\211 P N G" in bytes 0-3. --- 3465,3471 ---- single-image JNG datastream can be written in a standalone file. If so, the first eight bytes of a JNG datastream are ! 139 74 78 71 13 10 26 10 (decimal) which is similar to the PNG signature with "\213 J N G" instead of "\211 P N G" in bytes 0-3. *************** *** 3002,3020 **** Alpha sample depth: 1 byte. ! 0, 1, 2, 4, 8, or 16. Alpha compression method: 1 byte. 0: PNG grayscale IDAT format. Alpha filter method: 1 byte. ! 0: Adaptive (see PNG spec). Alpha interlace method: 1 byte. ! 0: Not interlaced. The width, height, image_sample_depth, image_compression_method, and image_interlace_method fields are redundant because equivalent information --- 3508,3532 ---- Alpha sample depth: 1 byte. ! 0, 1, 2, 4, 8, or 16, if the Alpha ! compression method is 0 (PNG) ! 8, if the Alpha compression method ! is 8 (JNG). Alpha compression method: 1 byte. 0: PNG grayscale IDAT format. + 8: JNG 8-bit grayscale JDAA format. Alpha filter method: 1 byte. ! 0: Adaptive PNG (see PNG spec) or ! not applicable (JPEG). Alpha interlace method: 1 byte. ! 0: Noninterlaced PNG or sequential ! single-scan JPEG. The width, height, image_sample_depth, image_compression_method, and image_interlace_method fields are redundant because equivalent information *************** *** 3050,3057 **** Actually, a JNG may contain two separate JNG JPEG datastreams (one eight-bit and one twelve-bit), each contained in a series of JDAT chunks, and ! separated by a JSEP chunk (see the JSEP chunk specification below, Paragraph ! 5.1.5). Decoders that are unable to handle twelve-bit datastreams are allowed to display the eight-bit datastream instead, if one is present. The core of the JNG JPEG definition is baseline JNG JPEG, which is JPEG Part --- 3562,3569 ---- Actually, a JNG may contain two separate JNG JPEG datastreams (one eight-bit and one twelve-bit), each contained in a series of JDAT chunks, and ! separated by a JSEP chunk (see the JSEP chunk specification below). Decoders ! that are unable to (or do not wish to) handle twelve-bit datastreams are allowed to display the eight-bit datastream instead, if one is present. The core of the JNG JPEG definition is baseline JNG JPEG, which is JPEG Part *************** *** 3206,3212 **** either 8-bit or 16-bit quantization tables. All other JNG restrictions still apply. ! 5.1.3. IDAT JNG alpha data This chunk is exactly like the IDAT chunk in a PNG grayscale image, except that it is interpreted as an alpha mask to be applied to the image data from --- 3718,3724 ---- either 8-bit or 16-bit quantization tables. All other JNG restrictions still apply. ! 5.1.3. IDAT JNG PNG-encoded alpha data This chunk is exactly like the IDAT chunk in a PNG grayscale image, except that it is interpreted as an alpha mask to be applied to the image data from *************** *** 3217,3223 **** IDAT and JDAT chunks. No other chunk type can appear between the sequences of IDAT and JDAT chunks when they are not interleaved. The samples in the IDAT must be presented in noninterlaced order, left to right, top to bottom. ! As in PNG, zero means fully transparent and 2alpha_sample_depth-1 means fully opaque. The IDAT chunks must precede the JSEP chunk, if the JSEP chunk is present. --- 3729,3735 ---- IDAT and JDAT chunks. No other chunk type can appear between the sequences of IDAT and JDAT chunks when they are not interleaved. The samples in the IDAT must be presented in noninterlaced order, left to right, top to bottom. ! As in PNG, zero means fully transparent and 2^alpha_sample_depth-1 means fully opaque. The IDAT chunks must precede the JSEP chunk, if the JSEP chunk is present. *************** *** 3228,3247 **** chunk and apply the alpha samples to the twelve-bit image that is contained in the JDAT chunks that follow the JSEP chunk. ! 5.1.4. IEND End of JNG datastream The JNG IEND chunk is identical to its counterpart in PNG. Its data length is zero, and it serves to mark the end of the JNG datastream. ! 5.1.5. JSEP 8-bit/12-bit image separator The JSEP chunk is empty. A JSEP chunk must appear between the JDAT chunks of an eight-bit datastream and those of a twelve-bit datastream, when image_sample_depth=20 in the JHDR ! chunk. The eight-bit datastream must appear first. Both images must have the ! same width, height, color type, compression method, and interlace type. ! Viewers can choose to display one or the other image, but not both. 5.2. Ancillary JNG chunks --- 3740,3772 ---- chunk and apply the alpha samples to the twelve-bit image that is contained in the JDAT chunks that follow the JSEP chunk. ! 5.1.4. JDAA JNG JPEG-encoded alpha data ! ! This chunk is exactly like the JDAT chunk in a non-progressive JNG 8-bit ! grayscale image, except that it is interpreted as an alpha mask to be ! applied to the image data from the JDAT chunks, when ! alpha_compression_method=8. The alpha channel, if present, can have only ! sample depth 8. The JDAA chunks can be interleaved with the JDAT chunks (see ! Recommendations for Encoders: JNG interleaving below). ! ! Like IDAT chunks, the JDAA chunks must precede the JSEP chunk, if the JSEP ! chunk is present, and are handled similarly. + 5.1.5. IEND End of JNG datastream + The JNG IEND chunk is identical to its counterpart in PNG. Its data length is zero, and it serves to mark the end of the JNG datastream. ! 5.1.6. JSEP 8-bit/12-bit image separator The JSEP chunk is empty. A JSEP chunk must appear between the JDAT chunks of an eight-bit datastream and those of a twelve-bit datastream, when image_sample_depth=20 in the JHDR ! chunk. When image_sample_depth != 20, the JSEP chunk must not be present. ! The eight-bit datastream must appear first. Both images must have the same ! width, height, color type, compression method, and interlace type. Viewers ! can choose to display one or the other image, but not both. 5.2. Ancillary JNG chunks *************** *** 3263,3275 **** When cHRM, gAMA, iCCP, or sRGB are present, they provide information about the color space of the decoded JDAT image, and they have no effect on the ! decoded alpha samples from the IDAT chunks. Any viewer that processes the ! gAMA chunk must also recognize and process the sRGB chunk. It can treat it ! as if it were a gAMA chunk containing the value .45455 and it can ignore its ! "intent" field. The chunk copying and ordering rules for JNG are the same as those in PNG, ! except for the fact that JDAT and IDAT chunks can be interleaved. 6. The Delta-PNG Format --- 3788,3801 ---- When cHRM, gAMA, iCCP, or sRGB are present, they provide information about the color space of the decoded JDAT image, and they have no effect on the ! decoded alpha samples from the IDAT or JDAA chunks. Any viewer that ! processes the gAMA chunk must also recognize and process the sRGB chunk. It ! can treat it as if it were a gAMA chunk containing the value .45455 and it ! can ignore its "intent" field. The chunk copying and ordering rules for JNG are the same as those in PNG, ! except for the fact that the JDAT chunks and IDAT or JDAA chunks can be ! interleaved. 6. The Delta-PNG Format *************** *** 3441,3451 **** An encoder calculates the delta sample values from the samples in the parent object and those in the child image by subtracting the parent ! object samples from the child image samples, modulo 2sample_depth. When ! decoding the IDAT chunk, the child image bytes are obtained by adding ! the delta bytes to the parent object bytes, modulo 2sample_depth. This ! is similar in operation to the PNG SUB filter, except that it works by ! samples instead of by bytes. Only the pixels in the block defined by the block location and dimensions given in the DHDR chunk are changed. The size of the IDAT --- 3967,3977 ---- An encoder calculates the delta sample values from the samples in the parent object and those in the child image by subtracting the parent ! object samples from the child image samples, modulo 2^sample_depth. ! When decoding the IDAT chunk, the child image bytes are obtained by ! adding the delta bytes to the parent object bytes, modulo ! 2^sample_depth. This is similar in operation to the PNG SUB filter, ! except that it works by samples instead of by bytes. Only the pixels in the block defined by the block location and dimensions given in the DHDR chunk are changed. The size of the IDAT *************** *** 3491,3497 **** method, filter method, and interlace method need not be the same. If they are different, the child object inherits the new values, and the new values will be used in decoding the data in any subsequent IDAT ! chunks. The sample_depth value from the IHDR chunk is interpreted as a new value of alpha_sample_depth and is only used for decoding the IDAT data --- 4017,4024 ---- method, filter method, and interlace method need not be the same. If they are different, the child object inherits the new values, and the new values will be used in decoding the data in any subsequent IDAT ! chunks. Neither the parent object nor the delta object can have alpha ! samples that were carried in JPEG-encoded JDAA chunks. The sample_depth value from the IHDR chunk is interpreted as a new value of alpha_sample_depth and is only used for decoding the IDAT data *************** *** 3544,3549 **** --- 4071,4080 ---- compression method, filter method, and interlace method need not be the same. If they differ, the child object inherits the new values. + It is permitted to use JPEG-encoded JDAA chunks to convey the new alpha + data. If this is done, then the alpha channel of the object can no + longer be used as the parent for block-alpha-addition. + Block color replacement delta_type=6 is similar to delta_type=4 except that the alpha channel is not included in the IDAT pixels; the alpha channel is inherited from *************** *** 3658,3664 **** alpha channel is affected, if one is present. If the color_type has been promoted from indexed-color, the original bit depth is always considered to be 8. See the PNG specification [PNG] for further information on these ! filling methods. If the basis object contains data from the PNG bKGD chunk, this data must be promoted as well. If a grayscale object is being promoted to a truecolor --- 4189,4196 ---- alpha channel is affected, if one is present. If the color_type has been promoted from indexed-color, the original bit depth is always considered to be 8. See the PNG specification [PNG] for further information on these ! filling methods. Any alpha channel added in this manner is eligible to be ! updated by block-alpha-addition in this or a subsequent Delta-PNG. If the basis object contains data from the PNG bKGD chunk, this data must be promoted as well. If a grayscale object is being promoted to a truecolor *************** *** 3840,3851 **** location occupied by the IJNG chunk. The JHDR chunk can also be omitted when image_type=2 and the JNG datastream ! begins with a JDAT chunk. Note: Be sure that the first JDAT chunk precedes ! the first IDAT chunk. In this case, no IJNG chunk is required, either. The ! decoder must treat this datastream as though the JHDR chunk were present, ! immediately preceding the first JDAT chunk. If the first JNG chunk is not a ! JDAT chunk, then either the IJNG or JHDR must be present to introduce the ! JNG datastream. 6.1.10. DROP Drop chunks --- 4372,4383 ---- location occupied by the IJNG chunk. The JHDR chunk can also be omitted when image_type=2 and the JNG datastream ! begins with a JDAT or JDAA chunk. Note: Be sure that the first JDAT or JDAA ! chunk precedes the first IDAT chunk. In this case, no IJNG chunk is ! required, either. The decoder must treat this datastream as though the JHDR ! chunk were present, immediately preceding the first JDAT chunk. If the first ! JNG chunk is not a JDAT or JDAA chunk, then either the IJNG or JHDR must be ! present to introduce the JNG datastream. 6.1.10. DROP Drop chunks *************** *** 3890,3899 **** Chunk name: 4 bytes (ASCII text). Order type: 1 byte. 0: Anywhere. ! 1: After IDAT and/or JDAT. ! 2: Before IDAT and/or JDAT. ! 3: Before IDAT, but not before PLTE. ! 4: Before IDAT, but not after PLTE. etc. Critical chunk names must not appear in the ORDR chunk. The applier needs to --- 4422,4431 ---- Chunk name: 4 bytes (ASCII text). Order type: 1 byte. 0: Anywhere. ! 1: After IDAT and/or JDAT or JDAA. ! 2: Before IDAT and/or JDAT or JDAA. ! 3: Before IDAT but not before PLTE. ! 4: Before IDAT but not after PLTE. etc. Critical chunk names must not appear in the ORDR chunk. The applier needs to *************** *** 3955,3961 **** present, and the ORDR chunk is not present, known chunks (always including all standard chunks described in the PNG specification) are considered to have appeared in their proper order with respect to the critical chunks. ! Unknown chunks are ordered as described in above (Paragraph 6.1.12). 7. Chunk Copying Rules --- 4487,4493 ---- present, and the ORDR chunk is not present, known chunks (always including all standard chunks described in the PNG specification) are considered to have appeared in their proper order with respect to the critical chunks. ! Unknown chunks are ordered as described in above (Paragraph 6.1.8). 7. Chunk Copying Rules *************** *** 4024,4035 **** Anything less than this level of support requires subsetting. Applications that provide less than minimal MNG support should check the MHDR "simplicity ! profile" for the presence of features that they are unable to support. A ! specific subset, in which "complex MNG features" and JNG are absent, is ! called "MNG-LC". In MNG-LC datastreams, bit 0 of the simplicity profile must ! be 1 and bits 2 and 4 must be 0. Another subset is called "MNG-VLC". In ! MNG-VLC datastreams, "simple MNG features" are also absent, and bit 1 must ! therefore also be 0. Subsets are useable when the set of MNG datastreams to be processed is known to be (or is very likely to be) limited to the feature set in MNG-LC or --- 4556,4567 ---- Anything less than this level of support requires subsetting. Applications that provide less than minimal MNG support should check the MHDR "simplicity ! profile" for the presence of features that they are unable to support or do ! not wish to support. A specific subset, in which "complex MNG features" and ! JNG are absent, is called "MNG-LC". In MNG-LC datastreams, bit 0 of the ! simplicity profile must be 1 and bits 2 and 4 must be 0. Another subset is ! called "MNG-VLC". In MNG-VLC datastreams, "simple MNG features" are also ! absent, and bit 1 must therefore also be 0. Subsets are useable when the set of MNG datastreams to be processed is known to be (or is very likely to be) limited to the feature set in MNG-LC or *************** *** 4071,4078 **** 2. MNG-LC with JNG, ! 3. MNG. On the other hand, a developer working on an application for storing multi-page fax documents might have no need for more than "MNG-VLC without transparency". --- 4603,4612 ---- 2. MNG-LC with JNG, ! 3. MNG with JNG, but without stored objects. + 4. MNG. + On the other hand, a developer working on an application for storing multi-page fax documents might have no need for more than "MNG-VLC without transparency". *************** *** 4180,4186 **** before deciding to proceed. MNG-compliant decoders must support JNG, but MNG-LC and MNG-VLC decoders are not required to support JNG. ! JHDR, JDAT, IDAT, JSEP, IEND All JNG critical chunks must be fully supported. All values of color_type, bit_depth, compression_method, filter_method and interlace_method must be supported (interlacing, as in PNG, need not --- 4714,4720 ---- before deciding to proceed. MNG-compliant decoders must support JNG, but MNG-LC and MNG-VLC decoders are not required to support JNG. ! JHDR, JDAT, IDAT, JDAA, JSEP, IEND All JNG critical chunks must be fully supported. All values of color_type, bit_depth, compression_method, filter_method and interlace_method must be supported (interlacing, as in PNG, need not *************** *** 4212,4218 **** MNG-compliant decoders are required to support Delta-PNG, but MNG-LC and MNG-VLC decoders are not. ! DHDR, PROM, IHDR, IDAT, IPNG, JHDR, JDAT, IJNG, JSEP, PLTE, tRNS, IEND, PPLT Must be fully supported. Bit 2 or bit 5 of the simplicity profile can be used to promise that none of these are present (because the DHDR chunk is absent). Bit 4 of the simplicity profile can be used to --- 4746,4753 ---- MNG-compliant decoders are required to support Delta-PNG, but MNG-LC and MNG-VLC decoders are not. ! DHDR, PROM, IHDR, IDAT, JDAA, IPNG, JHDR, JDAT, IJNG, JSEP, PLTE, tRNS, ! IEND, PPLT Must be fully supported. Bit 2 or bit 5 of the simplicity profile can be used to promise that none of these are present (because the DHDR chunk is absent). Bit 4 of the simplicity profile can be used to *************** *** 4285,4302 **** lost by deleting the index, because the MNG datastream contains all of the information needed to build the index. If an application does build an index, and the file is going to be kept as a local file, the application ! should replace the empty SAVE chunk with one containing the index. See above ! (Paragraph 4.4.1). ! 9.6. Interleaving JDAT and IDAT chunks When a JNG datastream contains an alpha channel, and the file is intended ! for transmission over a network, it is useful to interleave the IDAT and ! JDAT chunks. In the case of sequential JPEG, the interleaving should be ! arranged so that the alpha data arrives more or less in sync with the color ! data for the scanlines. In the case of progressive JPEG, the alpha data ! should be interleaved with the first JPEG pass, so that all of the alpha ! data has arrived before beginning the second JPEG pass. 10. Recommendations for Decoders --- 4820,4837 ---- lost by deleting the index, because the MNG datastream contains all of the information needed to build the index. If an application does build an index, and the file is going to be kept as a local file, the application ! should replace the empty SAVE chunk with one containing the index. See ! above. ! 9.6. Interleaving JDAT, JDAA, and IDAT chunks When a JNG datastream contains an alpha channel, and the file is intended ! for transmission over a network, it is useful to interleave the IDAT or JDAA ! and the JDAT chunks. In the case of sequential JPEG, the interleaving should ! be arranged so that the alpha data arrives more or less in sync with the ! color data for the scanlines. In the case of progressive JPEG, the alpha ! data should be interleaved with the first JPEG pass, so that all of the ! alpha data has arrived before beginning the second JPEG pass. 10. Recommendations for Decoders *************** *** 4657,4666 **** 13. Rationale ! This (incomplete as of version 0.96) section does not form a part of the specification. It provides the rationale behind some of the design decisions in MNG. Interframe delay Explain why the interframe delay has to be provided before the subframe --- 5192,5221 ---- 13. Rationale ! This (incomplete as of version 0.97) section does not form a part of the specification. It provides the rationale behind some of the design decisions in MNG. + New critical chunk versus filter method 48 + + Filter method 48 could have been implemented as a new critical chunk in PNG + or in MNG, e.g. + + FILT type L0 L1 L2 L3 + + in which L0-L3 are 16-bit values that convey the levels for the various + color channels, type is one of the additional filter types, and an empty + COLT chunk turns off this type of filtering. + + The choice of using a new filter method instead of a new critical chunk was + made based on simplicity of implementation and eventual inclusion of this + method in PNG. + + We did not have any experimental evidence suggesting that it would be useful + to have a separate levelset for each scanline. It is possible that this + would be effective for very wide images, however, and more filter types + could be defined to achieve this. + Interframe delay Explain why the interframe delay has to be provided before the subframe *************** *** 4673,4678 **** --- 5228,5297 ---- Explain why types 4 and 6 (pixel replacement and color channel replacement) are not allowed under these circumstances. + MAGN chunk rationale + + Q. Why not just use a BASI chunk to encode solid-color rectangles? + + A. The MAGN chunk also allows encoding of gradient-filled rectangles. + + Q. Why not just use PNG to encode gradient-filled rectangles? + + A. While PNG can encode vertical and horizontal gradients fairly + efficiently, it cannot do diagonal ones efficiently, and none are as + efficient as a 30-byte MAGN chunk plus a 4-pixel PNG. + + Q. Why not use full-scale low-quality JPEG/JNG? + + A. Low-quality JPEG with reduced dimensions can be much smaller than even + the lowest-quality full-sized JPEG. For example, color lena converted to a + 512x512 JPEG using ImageMagick software, quality 1, is 2944 bytes, while + converted to a 64x64 JPEG, quality 50, it's only 1171 bytes[*] and looks + less posterized when magnified 8 times using the linear interpolation + method. This is a compression ratio of 671:1. Similar results were obtained + with the greyscale lena (2217, 941 bytes[*], and 279:1, respectively). [Show + PSNR numbers] [*]including 21 bytes for a "MAGN 00 00 2 08 07" chunk. + + Such images can then be magnified to full scale with the MAGN chunk, for use + as preview ("LOWSRC") images. For natural images, this has been demonstrated + to be about 40 to 50 times as efficient as using Adam7 interlacing. For + example, the size increase of the color lena image due to interlacing is + 45460 bytes, compared to the 1171 bytes needed for a reduced JNG in front of + a noninterlaced color lena. + + It appears that in general, usable preview images of truecolor photographic + images can be made at compression ratios from M*800:1 to M*2500:1, where M + is the number of megapixels in the original image, by reducing the original + image spatially to width and height in the range 64 to 200 pixels and then + compressing the result to a medium-quality JNG. + + Q. Why not use the pHYg chunk? + + A. It is not mandatory for decoders to process the pHYg chunk and it does + not apply to individual images; it is used to scale the entire MNG frame. + The pHYs chunk cannot be used either because MNG decoders are required to + ignore it. + + Q. Why not 4-byte magnification factors instead of 2-byte ones? + + A. Encoders can start with a larger object or, except for object 0, magnify + it twice. + + Q. Why not 1-byte magnification factors, then? + + A. With typical screen widths currently 1280 or 1620 pixels and film and + printer pages currently about 3000 pixels wide, magnifying a 1x1 image to a + width of more than 255 pixels would not be uncommon. + + Q. I want to magnify a "frozen" object. + + A. You can make a full clone and magnify that. + + Q. Why define Methods 3 and 4? + + A. Method 4 is useful for magnifying an alpha-encoded image while + maintaining binary transparency. Method 3 is useful for making an + alpha-gradient while preserving sharp edges in the main image. + JNG alpha channel It has been suggested that the JNG alpha data should optionally be *************** *** 4692,4703 **** 14. Revision History ! 14.1. Version 0.97 Released 28 February 2000. Minor editorial changes only. A new example was added. ! 14.2. Version 0.96 Released 18 July 1999. The changes that are not simple editorial changes were approved by votes of the PNG Development group that closed 16 July 1999 --- 5311,5433 ---- 14. Revision History ! 14.1. Version 0.97f ! ! Proposed 4 September 2000 ! ! Eliminated color types 18 and 22. ! ! Added new filter methods for use in embedded PNG datastreams. ! ! * 1, "implicit none" ! ! * 32, intra-pixel differencing to improve compressibility. ! ! * 48, intra-pixel differencing and leveling. ! ! * 64, leveling. ! ! 14.2. Version 0.97e ! ! Proposed 2 September 2000 ! ! Added MAGN chunk. ! ! Clarified wording about sRGB nullifying gAMA and cHRM chunks, to make it ! clear that it is preceding chunks that are nullified, not later ones. ! ! Fixed typo in JNG signature bytes, to be the decimal equivalent of "JNG" ! instead of "PNJ". ! ! *Added color types 18 and 22, to carry color samples that have been ! transformed to improve compressibility. ! ! *Disallow the JSEP chunk when image_sample_depth != 20 ! ! 14.3. Version 0.97d ! ! Proposed 29 August 2000 ! ! Relocated misplaced TERM chunk in Example 14. ! ! Added a note that top-level color-space chunks do not have any effect on ! already-decoded objects. ! ! Changed "immediately after the MHDR chunk" to "very shortly after the MHDR ! chunk" in the nEED chunk specification. + Clarified some wording in the SEEK chunk specification, and added a cross + reference to the existing requirement to insert a background layer when + making random access to a segment. + + 14.4. Version 0.97c + + Proposed 27 August 2000 + + Global sRGB nullifies global gAMA and cHRM, and vice versa. + + This will be handled by informal consensus, i.e., by a Call for Objection. + + Added a terminology entry for "nullify". + + It is permitted to change the potential visibility, location, and clipping + boundaries of "frozen" objects, provided that the encoder writes chunks to + restore them to their "frozen" values prior to the end of the segment. + + Clarified treatment of the alpha sample in the BASI chunk when the color + type is 0, 2, or 3, and clarified that the BASI chunk inherits default DEFI + values if no DEFI chunk is present. + + 14.5. Version 0.97b + + Proposed 22 August 2000 + + Added JPEG-encoded alpha channel in JNG and Delta-PNG datastreams, stored in + a new JDAA chunk. This requires a formal vote. + + The meaning of the transparency flag (bit 2 of the simplicity profile) was + restored to the meaning that it had in version 0.97. + + A "semitransparency" flag was added to the simplicity profile. This will be + included in the vote on the "background transparency" flag. + + Revised the MNG-LC and MNG-VLC definitions to include the possibility of the + two new transparency flags and the new validity flag being set. + + The discussion of handling a changing background scene was revised. + + URLs were changed to "libpng.org". + + Instances of "mpng-list" were updated to "mng-list". + + 14.6. Version 0.97a + + Proposed 21 August 2000 + + Changed "Repeat count" to "Iteration count" in the LOOP chunk specification, + and "times to repeat" to "times to execute" in the description of the + "Iteration max" field in the TERM chunk, and added a statement about + representing infinity. This is a minor proposal that will be handled by + informal consensus. + + Separates the "transparency" profile bit into "transparency" and "background + transparency", and adds discussion of "background transparency" to the BACK + and FRAM chunk specifications. This proposal requires a formal vote. + + Adds a "stored objects" flag to promise that even of "complex MNG features" + are present, it is not necessary to create object buffers. This proposal + requires a formal vote. + + Adds a "validity" flag to maintain backward compatibility of the simplicity + profile. If it is zero, then the "background transparency" and "stored + objects" flags do not make any promises. + + 14.7. Version 0.97 + Released 28 February 2000. Minor editorial changes only. A new example was added. ! 14.8. Version 0.96 Released 18 July 1999. The changes that are not simple editorial changes were approved by votes of the PNG Development group that closed 16 July 1999 *************** *** 4750,4756 **** * Added the global bKGD and sBIT chunks. ! 14.3. Version 0.95 Initial public release, approved by the PNG Development Group on 11 May 1999. --- 5480,5486 ---- * Added the global bKGD and sBIT chunks. ! 14.9. Version 0.95 Initial public release, approved by the PNG Development Group on 11 May 1999. *************** *** 5329,5336 **** write "MHDR" chunk saved_images := 0; Interframe_delay := 0 First_frame := TRUE - write "BACK" chunk if(loops>1) "write TERM 3 0 0 loops" chunk for subimage in gif89a file do if(interframe_delay != gif_duration) then interframe_delay := gif_duration --- 6059,6066 ---- write "MHDR" chunk saved_images := 0; Interframe_delay := 0 First_frame := TRUE if(loops>1) "write TERM 3 0 0 loops" chunk + write "BACK" chunk for subimage in gif89a file do if(interframe_delay != gif_duration) then interframe_delay := gif_duration *************** *** 5494,5499 **** --- 6224,6272 ---- eXPI 1 "blue right arrow" MEND + 17.18. Example 18: MAGN chunks and ROI + + This example demonstrates the use of MNG to display Region of Interest (ROI) + at a higher quality than the rest of the frame, and the MAGN chunk to convey + a highly-compressed but very lossy image, a drop shadow, and a diagonal + gradient background. + + MHDR 600 600 0 5 1 0 19 + # Gradient background + MAGN 00 00 2 599 + sRGB 1 + IHDR IDAT IEND # 93 bytes + + # Drop shadow + DEFI 0 0 0 52 52 + BASI 512 512 1 4 0 0 0 00 51 51 51 153 + IEND # 47 bytes Grey-Alpha object + + # Main image, with most of the region of interest + # replaced with a solid rectangle, and reduced to + # 128x128 dimensions, low quality JPEG compression. + DEFI 0 0 0 36 36 + MAGN 00 00 2 04 04 06 05 06 05 + JHDR 128 128 10 8 8 0 0 0 0 0 + JDAT # 2514 bytes + IEND + + # Region of interest, full scale, cropped to + # dimensions 200x313 at location 192,200, + # high quality JPEG compression. + MAGN + DEFI 0 0 0 228 236 + JHDR 200 312 10 8 8 0 0 0 0 0 + JDAT # 8001 bytes + IEND + + MEND + + For the particular image used in this example (the 512x512 color Lena from + Bragzone [URL]), the resulting 600x600 frame occupies about 2.6 times the + file size when written as a simple JNG and about 26 times the file size when + written as a simple PNG. + 18. Credits Editor *************** *** 5550,5557 **** Document source ! This document was built from the file mng-master-20000228 on ! 29 February 2000. Copyright Notice --- 6323,6330 ---- Document source ! This document was built from the file mng-master-20000905 on ! 05 September 2000. Copyright Notice