It is proposed to replace paragraph 4.2.3 with the following, which adds two new color types for embedded PNG datatreams. 4.2.3. IHDR, PNG chunks, IEND A PNG (Portable Network Graphics) datastream. 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. * 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. * Two additional PNG color types are defined in PNG datastreams when they are used inside a MNG datastream. These are 18: 3-sample pixels containing RGB data that has been transformed to S0 = Red - Green S1 = Green S2 = Blue - Green The transformation is done in integer arithmetic in sufficient precision to hold intermediate results, and the result is stored modulo the sample depth. 22: 4-sample pixels containing transformed RGB samples as in color type 18, plus an alpha sample that is not transformed. This transformation, which has previously been used in the LOCO image format [LOCO], has been demonstrated to improve the compressibility of natural images by 10 to 15 percent of the compressibility of RGB data. This is due to the correlation between color samples, which is ignored by the PNG filters. The RGB samples are recovered by the inverse of the transformation, which is Red = S0 + S1 Green=S1 Blue = S2 + S1 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 color types 18 or 22 to a standard PNG datastream with a PNG color type (0, 2, 3, 4, or 6). 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 these two color types, unless they should become officially approved for use in PNG datastreams. For experimenting and testing, applications can use values 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 MNG 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 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.