archive-org.com » ORG » O » OPENINDIANA.ORG

Total: 101

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Index of /oi-build/source-archives
    Jul 2011 22 03 1 3M transset 0 9 1 tar bz2 24 Nov 2009 04 28 93K top 3 8beta1 tar gz 31 Jul 2011 22 03 276K tomcat connectors 1 2 28 src tar gz 31 Jul 2011 22 02 1 5M tls1 6 src tar gz 31 Jul 2011 22 02 164K tld 0 7 tar gz 31 Jul 2011 22 02 53K tk8 5 9 src tar gz 31 Jul 2011 22 02 3 6M tigervnc 1 0 1 tar gz 19 Mar 2010 16 02 2 7M tidy 1 0 0 tar gz 31 Jul 2011 22 02 925K texinfo 4 7 tar bz2 31 Jul 2011 22 02 1 4M tcsh 6 17 00 tar gz 31 Jul 2011 22 02 869K tcpdump 4 1 1 tar gz 31 Jul 2011 22 02 1 5M tcl8 5 9 src tar gz 31 Jul 2011 22 01 4 3M tcl8 4 18 src tar gz 31 Jul 2011 22 01 3 5M tar 1 26 tar bz2 31 Jul 2011 22 01 2 2M tar 1 25 tar bz2 31 Jul 2011 22 01 2 2M synergy 1 3 1 tar gz 02 Apr 2006 21 23 775K swig 1 3 35 tar gz 31 Jul 2011 22 01 4 4M sudo 1 7 4p4 tar gz 31 Jul 2011 22 00 941K subversion 1 6 16 tar gz 31 Jul 2011 22 00 7 2M stdcxx 4 2 1 tar gz 31 Jul 2011 22 00 6 9M squid 3 1 8 tar gz 31 Jul 2011 21 59 3 1M squid 2 7 STABLE9 tar gz 31 Jul 2011 21 59 1 7M spawn fcgi 1 6 3 tar gz 31 Jul 2011 21 59 96K sox 14 3 0 tar gz 31 Jul 2011 21 59 1 0M snort 2 8 4 1 tar gz 31 Jul 2011 21 59 4 4M smproxy 1 0 3 tar bz2 17 Oct 2009 00 35 101K slrn 0 9 9p1 tar gz 31 Jul 2011 21 58 1 5M slib 3b1 zip 31 Jul 2011 21 58 1 0M slang 2 2 4 tar bz2 31 Jul 2011 21 58 1 4M showfont 1 0 2 tar bz2 24 May 2008 01 14 88K setxkbmap 1 1 0 tar bz2 09 Jul 2009 00 20 97K sessreg 1 0 6 tar bz2 04 Jun 2010 01 34 110K sed 4 2 1 tar gz 31 Jul 2011 21 58 1 1M scrnsaverproto 1 2 0 tar bz2 25 Aug 2009 09 45 48K screen 4 0 3 tar gz 31 Jul 2011 21 58 821K sblim cim client 1 3 7 src zip 31 Jul 2011 21 58 444K sane frontends 1 0 14 tar gz 31 Jul 2011 21 58 226K sane backends 1 0 19 tar gz 31 Jul 2011 21 58 4 1M samba 3 5 8 tar gz 31 Jul 2011 21 57 29M samba 3 0 37 tar gz 31 Jul 2011 21 56 22M rubygems 1 3 5 tgz 31 Jul 2011 21 56 272K ruby 1 8 7 p334 tar bz2 31 Jul 2011 21 56 4 0M rtorrent 0 8 2 tar gz 31 Jul 2011 21 55 494K rsync 3 0 8 tar gz 31 Jul 2011 21 55 772K rsync 3 0 7 tar gz 31 Jul 2011 21 55 761K rsync 3 0 6 tar gz 31 Jul 2011 21 55 761K rstart 1 0 3 tar bz2 02 Aug 2009 14 41 104K rgb 1 0 3 tar bz2 06 Jun 2008 04 18 101K resourceproto 1 1 0 tar bz2 25 Aug 2009 07 37 47K renderproto 0 11 1 tar bz2 10 Aug 2010 15 13 103K recordproto 1 14 tar bz2 01 Oct 2009 13 16 82K readline 5 2 tar gz 31 Jul 2011 21 55 1 9M rds tools 2 0 4 tar gz 31 Jul 2011 21 55 74K rdiff backup 1 2 1 tar gz 31 Jul 2011 21 55 185K randrproto 1 3 1 tar bz2 06 Oct 2009 04 55 108K quilt 0 47 tar gz 31 Jul 2011 21 55 412K quagga 0 99 8 tar gz 31 Jul 2011 21 55 2 2M qperf 0 4 6 0 1 gb81434e tar gz 31 Jul 2011 21 54 199K Python 2 6 4 tar bz2 31 Jul 2011 21 54 11M pyOpenSSL 0 11 tar gz 31 Jul 2011 21 54 236K pylint 0 18 0 tar gz 31 Jul 2011 21 54 207K pycurl 7 19 0 tar gz 31 Jul 2011 21 54 70K pycups 1 9 46 tar bz2 31 Jul 2011 21 54 41K pybonjour 1 1 1 tar gz 31 Jul 2011 21 54 18K pwgen 2 06 tar gz 31 Jul 2011 21 54 30K pv 1 1 4 tar gz 31 Jul 2011 21 53 90K pth 2 0 7 tar gz 31 Jul 2011 21 53 637K psutils p17 tar gz 31 Jul 2011 21 53 61K proxymngr 1 0 1 tar bz2 18 Jan 2006 23 51 90K proftpd 1 3 3e tar gz 31 Jul 2011 21 53 4 7M privoxy 3 0 8 stable src tar gz 25 Jul 2011 11 37 1 9M printproto 1 0 4 tar bz2 06 Mar 2008 21 25 48K pmtools 20071116 tar gz 31 Jul 2011 21 53 50K pmtools 1 10 tar gz 31 Jul 2011 21 53 19K ply 3 1 tar gz 31 Jul 2011 21 53 143K pixman 0 18 4 tar bz2 16 Aug 2010 11 50 412K pinentry 0 7 6 tar gz 31 Jul 2011 21 53 464K perl 5 12 3 tar bz2 31 Jul 2011 21 53 11M perftest 1 3 0 0 42 gf350d3d tar gz 31 Jul 2011 21 52 60K pcre 7 8 tar gz 31 Jul 2011 21 52 1 1M pconsole 1 0 tar gz 31 Jul 2011 21 52 210K patch 2 5 9 tar gz 31 Jul 2011 21 52 197K pam pkcs11 0 6 0 tar gz 31 Jul 2011 21 52 1 0M p7zip 9 20 1 src all tar bz2 31 Jul 2011 21 52 3 7M p7zip 4 55 src all tar bz2 31 Jul 2011 21 52 1 4M otp src R12B 5 tar gz 31 Jul 2011 21 52 45M otp doc man R12B 5 tar gz 31 Jul 2011 21 50 803K otp doc html R12B 5 tar gz 31 Jul 2011 21 50 5 4M openssl fips 1 2 tar gz 31 Jul 2011 21 50 3 6M openssl 1 0 0d tar gz 31 Jul 2011 21 49 3 8M openssl 0 9 8q tar gz 31 Jul 2011 21 49 3 6M opensm 3 3 9 tar gz 31 Jul 2011 21 49 1 2M openexr 1 6 1 tar gz 31 Jul 2011 21 49 13M oclock 1 0 1 tar bz2 18 Jan 2006 23 51 81K ntp dev 4 2 5p200 tar gz 31 Jul 2011 21 48 4 1M nmap 5 21 tgz 31 Jul 2011 21 48 11M nethack 343 src tgz 31 Jul 2011 21 48 3 3M Net SSLeay 1 36 tar gz 31 Jul 2011 21 47 142K net snmp 5 4 1 tar gz 31 Jul 2011 21 47 4 9M neon 0 29 5 tar gz 31 Jul 2011 21 47 864K ncftp 3 2 3 src tar bz2 31 Jul 2011 21 47 415K mutt 1 5 21 tar gz 31 Jul 2011 21 47 3 5M mpfr 2 4 2 tar gz 31 Jul 2011 21 47 1 3M mpc 0 9 tar gz 31 Jul 2011 21 46 553K mozldap 6 0 7 tar gz 31 Jul 2011 21 46 659K mod proxy html 3 1 1 tar bz2 31 Jul 2011 21 46 22K mod perl 2 0 4 tar gz 31 Jul 2011 21 46 3 6M mod gss 1 3 3 tar gz 31 Jul 2011 21 46 112K mod fcgid 2 3 6 tar gz 31 Jul 2011 21 46 99K modsecurity apache 2 5 9 tar gz 31 Jul 2011 21 46 1 2M mng vlc 1 0 20010209 pdg html 31 Jul 2011 21 46 77K mng lc 1 0 20010209 pdg html 31 Jul 2011 21 46 123K mng 1 0 20010209 pdg html 31 Jul 2011 21 46 355K mkfontscale 1 0 7 tar bz2 11 Oct 2009 06 33 108K mkfontdir 1 0 5 tar bz2 11 Oct 2009 06 49 85K MesaLib 7 4 4 tar bz2 24 Jun 2009 01 54 3 2M MesaDemos 7 4 4 tar bz2 24 Jun 2009 01 54 1 3M mercurial 1 8 4 tar gz 31 Jul 2011 21 46 2 4M mercurial 1 8 2 tar gz 31 Jul 2011 21 45 2 4M mercurial 1 3 1 tar gz 31 Jul 2011 21 45 1 7M memcached 1 4 5 tar gz 31 Jul 2011 21 45 295K meld 1 4 0 tar gz 31 Jul 2011 21 45 462K mc 4 7 5 2 tar gz 31 Jul 2011 21 45 3 6M mc 4 7 3 tar gz 31 Jul 2011 21 44 3 6M Mako 0 4 1 tar gz 31 Jul 2011 21 44 310K makedepend 1 0 2 tar bz2 11 Oct 2009 06 10 114K make 3 81 tar gz 31 Jul 2011 21 44 1 5M m4 1 4 12 tar gz 31 Jul 2011 21 44 1 1M M2Crypto 0 21 1 tar gz 31 Jul 2011 21 44 404K lxml 2 1 2 tgz 31 Jul 2011 21 44 2 6M luit 1 0 5 tar bz2 10 Feb 2010 00 54 119K lua 5 1 4 tar gz 31 Jul 2011 21 44 212K logilab common 0 40 0 tar gz 31 Jul 2011 21 44 176K logilab astng 0 19 0 tar gz 31 Jul 2011 21 43 85K lndir 1 0 2 tar bz2 14 Aug 2010 05 23 103K listres 1 0 2 tar bz2 15 Dec 2009 23 10 100K links 1 00 tar gz 31 Jul 2011 21 43 609K lighttpd 1 4 23 tar gz 31 Jul 2011 21 43 785K libXxf86vm 1 1 0 tar bz2 05 Oct 2009 03 04 243K libXxf86misc 1 0 2 tar bz2 09 Oct 2009 06 27 240K libXvMC 1 0 6 tar bz2 14 Aug 2010 06 04 264K libXv 1 0 5 tar bz2 03 Oct 2009 10 17 261K libXtst 1 1 0 tar bz2 05 Oct 2009 02 51 251K libXt 1 0 8 tar bz2 15 Mar 2010 22 10 524K libxslt 1 1 26 tar gz 31 Jul 2011 21 43 3 2M libXScrnSaver 1 2 0 tar bz2 25 Aug 2009 10 01 243K libXres 1 0 4 tar bz2 09 Oct 2009 17 30 244K libXrender 0 9 6 tar bz2 09 Jun 2010 03 25 252K libXrandr 1 3 0 tar bz2 06 Mar 2009 14 17 256K libXpm 3 5 8 tar bz2 09 Oct 2009 18 36 383K libXp 1 0 0 tar bz2 18 Jan 2006 23 51 239K libXmu 1 0 5 tar bz2 24 Sep 2009 02 19 316K libxml2 2 7 6 tar gz 31 Jul 2011 21 43 4 6M libxkbfile 1 0 6 tar bz2 07 Oct 2009 01 19 279K libXinerama 1 1 tar bz2 02 Oct 2009 04 30 239K libXi 1 3 2 tar bz2 03 Aug 2010 23 17 354K libXft 2 1 14 tar bz2 10 Oct 2009 00 54 282K libXfont 1 4 1 tar bz2 10 Oct 2009 01 43 419K libXfixes 4 0 5 tar bz2 10 Jun 2010 04 20 250K libXext 1 1 2 tar bz2 04 Jun 2010 01 21 311K libXevie 1 0 2 tar bz2 13 Oct 2006 21 03 222K libXdmcp 1 0 3 tar bz2 23 Sep 2009 23 40 251K libXdamage 1 1 3 tar bz2 09 Jun 2010 02 54 243K libXcursor 1 1 10 tar bz2 28 Aug 2009 07 44 258K libXcomposite 0 4 2 tar bz2 09 Jun 2010 02 40 253K libXaw 1 0 7 tar bz2 17 Oct 2009 22 51 585K libXau 1 0 6 tar bz2 19 Jul 2010 17 24 255K libX11 1 3 5 tar bz2 12 Aug 2010 00 33 2 0M libtorrent 0 12 2 tar gz 31 Jul 2011 21 43 572K libtool 1 5 22 tar gz 31 Jul 2011 21 43 2 8M libsndfile 1 0 23 tar gz 31 Jul 2011 21 42 1 0M libSM 1 0 3 tar bz2 13 May 2007 13 35 219K libsigsegv 2 6 tar gz 31 Jul 2011 21 42 341K libsdp 1 1 108 0 15 gd7fdb72 tar gz 31 Jul 2011 21 42 739K libsam LGPL tar 31 Jul 2011 21 42 890K librsync docs 0 9 7 tar gz 31 Jul 2011 21 42 93K librsync 0 9 7 tar gz 31 Jul 2011 21 42 443K librdmacm 1 0 14 1 tar gz 31 Jul 2011 21 42 361K libpthread stubs 0 1 tar bz2 24 Nov 2006 07 46 190K libpciaccess 0 10 9 tar bz2 25 Sep 2009 01 28 276K libpcap 1 1 1 tar gz 31 Jul 2011 21 42 568K libopenusb 1 0 1 tar gz 31 Jul 2011 21 42 494K libnet 1 1 2 1 tar gz 31 Jul 2011 21 42 1 0M libmthca 1 0 5 0 1 gbe5eef3 tar gz 31 Jul 2011 21 41 726K libmng 1 0 10 tar gz 31 Jul 2011 21 41 1 0M libmlx4 1 0 1 1 18 gb810a27 tar gz 31 Jul 2011 21 41 558K libmemcached 0 16 tar gz 31 Jul 2011 21 41 393K libmcrypt 2 5 8 tar gz 31 Jul 2011 21 41 1 3M liblbxutil 1 1 0 tar bz2 05 Dec 2009 02 05 262K libksba 1 1 0 tar bz2 31 Jul 2011 21 41 571K libidn 1 19 tar gz 31 Jul 2011 21 41 3 1M libICE 1 0 6 tar bz2 28 Aug 2009 06 56 273K libibverbs 1 1 4 1 22 g7257cd3 tar gz 31 Jul 2011 21 41 641K libibumad 1 3 7 tar gz 31 Jul 2011 21 40 302K libibmad 1 3 7 tar gz 31 Jul 2011 21 40 323K libFS 1 0 2 tar bz2 07 Jul 2009 23 57 255K libfontenc 1 0 5 tar bz2 28 Aug 2009 06 51 244K libevent 1 3e tar gz 31 Jul 2011 21 40 441K liberation fonts 1 04 tar gz 08 Sep 2008 02 57 1 0M libdrm 2 4 14 tar bz2 21 Sep 2009 23 35 405K libassuan 2 0 1 tar bz2 31 Jul 2011 21 40 483K lftp 4 3 1 tar bz2 31 Jul 2011 21 40 1 7M lftp 4 0 10 tar bz2 31 Jul 2011 21 40 1 5M less 436 tar gz 31 Jul 2011 21 40 297K ldtp 2 1 1 tar gz 31 Jul 2011 21 40 104K lcms 1 19 tar gz 31 Jul 2011 21 40 906K lbxproxy 1 0 2 tar bz2 03 Nov 2009 17 10 201K lablgtk 2 10 1 tar gz 31 Jul 2011 21 40 750K kbproto 1 0 5 tar bz2 10 Aug 2010 15 04 109K junit4 5 zip 31 Jul 2011 21 40 1 1M jng 1 0 20010209 pdg html 31 Jul 2011 21 39 28K java memcached release 2 0 1 tar gz 31 Jul 2011 21 39 214K ircii 20060725 tar gz 31 Jul 2011 21 39 700K ipmitool 1 8 10 tar gz 31 Jul 2011 21 39 733K iperf 2 0 4 tar gz 31 Jul 2011 21 39 243K inputproto 2 0 tar bz2 02 Oct 2009 02 47 137K infiniband diags 1 5 8 tar gz 31 Jul 2011 21 39 449K imap 2007e tar gz 31 Jul 2011 21 39 1 9M imake 1 0 3 tar bz2 16 Apr 2010 04 01 136K ImageMagick 6 3 4 2 tar gz 31 Jul 2011 21 39 6 6M im sdk tar bz2 19 Mar 2015 19 23 20M ilmbase 1 0 1 tar gz 31 Jul 2011 21 38 452K iftop 0 17 tar gz 31 Jul 2011 21 38 157K ico 1 0 2 tar bz2 21 Jul 2007 01 22 95K iceauth 1 0 3 tar bz2 11 Oct 2009 04 57 104K ibutils 1 5 7 tar gz 31 Jul 2011 21 38 3 5M httping 1 4 4 tgz 31 Jul 2011 21 38 14K httping 1 3 0 tgz 31 Jul 2011 21 38 13K httpd 2 2 19 tar gz 31 Jul 2011 21 38 6 8M httpd 2 2 16 tar gz 31 Jul 2011 21 38 6 1M hplip 3 10 9 tar gz 31 Jul 2011 21 37 21M hexedit 1 2 12 src tgz 31 Jul 2011 21 37 64K hal cups utils 0 6 19 tar gz 31 Jul 2011 21 37 105K gzip 1 3 5 tar gz 31 Jul 2011 21 37 324K gutenprint 5 2 4 tar bz2 31 Jul 2011 21 37 4 9M guile 1 8 4 tar gz 31 Jul 2011 21 36 3 6M grep 2 5 4 tar bz2 31 Jul 2011 21 36 706K grails src 1 0 3 tar gz 31 Jul 2011 21 36 29M gpgme 1 1 8 tar bz2 31 Jul 2011 21 35 808K gperf 3 0 3 tar gz 31 Jul 2011 21 35 845K google droid fonts 2010 02 24 tar gz 25 Feb 2010 03 39 2 7M gocr 0 48 tar gz 31 Jul 2011 21 35 374K gnuplot 4 4 0 tar gz 31 Jul 2011 21

    Original URL path: http://dlc.openindiana.org/oi-build/source-archives/?C=N;O=D (2016-02-01)
    Open archived version from archive

  • JNG 1.0
    scale is 128 when dealing with eight bit data 2048 for twelve bit data With these equations Y Cb and Cr all have the same range as R G and B 0 to 255 for eight bit data 0 to 4095 for twelve bit data The JFIF convention for YCbCr differs from typical digital television practice in that no headroom footroom is reserved the coefficient values range over the full available 8 or 12 bits Intercomponent sample alignment shall be such that the first upper leftmost samples of each component share a common upper left corner position This again differs from common digital TV practice in which the first samples share a common center position The JFIF convention is simpler to visualize subsampled chroma samples always cover an integral number of luminance sample positions whereas with co centered alignment chroma samples only partially overlap some luminance samples Additional JNG restrictions JNG imposes three additional restrictions not found in the text of either JPEG Part 1 or the JFIF specification The sampling factors for YCbCr images must be one of these sets 1h1v 1h1v 1h1v also called 4 4 4 or 1x1 sampling 2h1v 1h1v 1h1v also called 4 2 2 or 2x1 sampling 2h2v 1h1v 1h1v also called 4 2 0 or 2x2 sampling 1h2v 1h1v 1h1v also called 1x2 sampling In other words the chroma components may be downsampled 2 1 or 1 2 horizontally or vertically relative to luminance or they may be left full size These four sampling ratios are the only ones supported by a wide spectrum of implementations 1x2 is relatively uncommon and is usually the result of a lossless rotation of a 2x1 sampling For grayscale images the sampling factors are irrelevant according to a strict reading of JPEG Part 1 Hence decoder authors should accept any sampling factors for grayscale However we recommend that encoders always emit sampling factors 1h1v for grayscale since some decoders have been observed to malfunction when presented with other sampling factors There must be only one scan in an image that is YCbCr images must be fully interleaved There is little advantage to be gained by encoding a baseline image in multiple scans and many baseline decoders do not support multiple scans at all The DNL Define Number of Lines marker is prohibited The image height must always be specified accurately in the SOFn marker and in the JHDR chunk Recommended progressive JPEG subset For JNG progressive JPEG datastreams the JPEG process is progressive Huffman coding SOF marker type SOF2 rather than baseline SOF0 All JNG compliant decoders must support full progression including both spectral selection and successive approximation modes with any sequence of scan progression parameters allowed by the JPEG Part 1 standard Otherwise all the restrictions listed above apply except these Multiple scan support is obviously required for progressive JPEG Huffman table numbers up to 3 the full JPEG limit may be used since the baseline two table limit is unlikely to be needed by any decoder that can handle progressive JPEG We require full progression support since relatively little code savings can be achieved by subsetting the JPEG progression features In particular successive approximation offers significant gains in the visual quality of early scans Omitting successive approximation support from a decoder does not save nearly enough code to justify restricting JNG progressive encoders to spectral selection only No particular progressive scan sequence is specified or recommended by this specification Not enough experience has been gained with progressive JPEG to warrant making such a recommendation To allow for future experimentation with scan sequences decoders are expected to handle any JPEG legal sequence Again the code savings that might be had by making restrictive assumptions are too small to justify a limitation When the JSEP chunk is present both images must be progressive if one of them is progressive Recommended 12 bit JPEG subset JNG JPEGs may optionally use 12 bit sample precision as defined in JPEG Part 1 For a sequential image the SOF marker type must be SOF1 extended sequential not SOF0 and the baseline restriction of two Huffman tables is removed Also the encoder may use either 8 bit or 16 bit quantization tables All other JNG baseline restrictions still apply It is recommended that JNG encoders not use extended sequential mode except to encode 12 bit data For a progressive image the only difference between 8 bit and 12 bit modes is that the sample precision is 12 bits and the encoder may use either 8 bit or 16 bit quantization tables All other JNG restrictions still apply 1 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 the JDAT chunks when alpha compression method 0 The alpha channel if present can have sample depths 1 2 4 8 or 16 The filter method can be any filter method that is defined for PNG datastreams that are embedded in MNG datastreams The IDAT chunks can be interleaved with the JDAT chunks see Recommendations for Encoders JNG interleaving below No other chunk type can appear among the sequence of 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 Minimal viewers that ignore the twelve bit JDAT chunks must read the IDAT chunks and apply the alpha samples to the eight bit image that is contained in the JDAT chunks that precede the JSEP chunk Viewers that skip the eight bit JDAT chunks must decode the IDAT chunks that precede the JSEP chunk and apply

    Original URL path: http://dlc.openindiana.org/oi-build/source-archives/jng-1.0-20010209-pdg.html (2016-02-01)
    Open archived version from archive

  • MNG 1.0
    discarded its set of object attributes which includes the CLIP data is also discarded 4 3 5 SHOW Show images The SHOW chunk is used to change the potential visibility of one or more previously defined objects and to direct that they be displayed It contains 2 4 or 5 bytes or it can be empty When any field is omitted all subsequent fields must also be omitted First image 2 bytes nonzero unsigned integer Last image 2 bytes nonzero unsigned integer This field can be omitted if the show mode byte is also omitted If so decoders must assume the default values show mode 0 and last image first image Show mode 1 byte unsigned integer 0 Make the images potentially visible and display them set do not show 0 1 Make the images invisible set do not show 1 2 Do not change do not show flag display those that are potentially visible 3 Mark images potentially visible do not show 0 but do not display them 4 Toggle do not show flag display any that are potentially visible after toggling 5 Toggle do not show flag but do not display even if potentially visible after toggling 6 Step through the images in the given range making the next image potentially visible set do not show 0 and display it Set do not show 1 for all other images in the range Jump to the beginning of the range when reaching the end of the range Perform one step for each SHOW chunk in reverse order if last image first image 7 Make the next image in the range cycle potentially visible do not show 0 but do not display it Set do not show 1 for the rest of the images in the range This field can be omitted If so decoders must assume the default show mode 0 The decoder processes the objects or images named in the SHOW chunk in the order first image through last image and resets the do not show flag for each of the objects If show mode is even valued it also displays the images if they are potentially visible and are viewable images When the SHOW chunk is empty the decoder displays all existing potentially visible images without changing their do not show status The empty SHOW chunk is equivalent to SHOW 1 65535 2 If last image first image the images are processed in reverse order When show mode is odd valued nothing is displayed unless a subsequent SHOW chunk with an even valued show mode appears Interactions with the framing mode When show mode is even valued each visible image that is displayed generates a separate layer even if it is offscreen and no pixels are actually displayed In such cases the layer is totally transparent When show mode is odd or when no image is potentially visible and show mode is 2 4 or empty no layer is generated When show mode is 1 4 5 6 or 7 images can be made invisible This is not permitted when the framing mode is 2 or 4 in the FRAM chunk and the images have already appeared in the frame because simple viewers will have already drawn them and have no way to make them invisible again without redrawing the entire frame When show mode is 6 or 7 the decoder must make the next image in the cycle potentially visible and if show mode is 6 generate a single layer To do this it must examine the do not show flag for each image in the range first image through last image and make the next one the one with the next higher value of image id that exists and is viewable after the first visible one it finds visible and the rest invisible When first image last image the cycle is reversed and the next image is the one with the next lower value of image id In either case if the first visible one found was last id or none were visible it must make first image visible These modes are useful for manipulating a group of sequential images that represent different views of an animated icon See Example 8 below Chapter 18 If no viewable object is in the specified range an empty layer must be generated When show mode is 0 2 4 or 6 separate layers will be generated each containing an instance of one visible image at the location specified by the DEFI CLON or MOVE chunk and clipped according to the boundaries specified by the CLIP and FRAM chunks When the MOVE or CLON chunk is used in the delta form which will frequently be the case each image must be displaced from its previous position by the values given in the MOVE or CLON chunk Assuming a nonzero interframe delay any of the following sequences would cause the image identified by object id 6 in a composite frame to blink LOOP 0 0 10 FRAM 4 Show background SHOW 1 10 Show images 1 thru 10 FRAM Show background SHOW 1 5 Show images 1 thru 5 SHOW 7 10 Show images 7 thru 10 ENDL FRAM 4 Show background LOOP 0 0 10 SHOW 1 5 Show images 1 thru 5 SHOW 6 6 4 Toggle potential visibility of image 6 SHOW 7 10 and show it show images 7 thru 10 FRAM ENDL FRAM 4 Show background LOOP 0 0 10 SHOW 6 6 5 Toggle potential visibility of image 6 SHOW 1 10 2 Show potentially visible images in 1 FRAM through 10 ENDL It is not necessary to follow an IHDR IEND JHDR IEND BASI IEND or DHDR IEND sequence or PAST chunk with a SHOW chunk to display the resulting image if it was already caused to appear by do not show 0 in the DEFI chunk that introduced the image Similarly the CLON chunk need not be followed by a SHOW chunk if do not show 0 in the CLON chunk 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 4 SAVE and SEEK chunks The SAVE chunk marks a point in the datastream at which objects are frozen and other chunk information is saved The SEEK chunk marks positions in the MNG datastream where a restart is possible and where the decoder must restore the saved information if they have jumped or skipped to a SEEK point from the interior of a segment They only need to restore information that they will use e g a viewer that processes gAMA and global PLTE and tRNS but ignores iCCP and sPLT need only restore the value of gamma and the global PLTE and tRNS data from the prologue segment but not the values of the iCCP and sPLT data Simple decoders that only read MNG datastreams sequentially can safely ignore the SAVE and SEEK chunks although it is recommended that for efficient use of memory they at least mark existing objects as frozen when the SAVE chunk is processed and discard all unfrozen objects whenever the SEEK or empty DISC chunk is processed 4 4 1 SAVE Save information The SAVE chunk marks a point in the datastream at which objects are frozen and other chunk information is saved a decoder skipping or jumping to a SEEK chunk from the interior of a segment must restore the saved chunk information if it has been redefined or discarded In addition the SAVE chunk can contain an optional index to the MNG datastream The SAVE chunk can be empty or it can contain an index consisting of the following Offset size 1 byte unsigned integer 4 Offsets and nominal start times are expressed as 32 bit integers 8 Offsets and nominal start times are expressed as 64 bit integers plus zero or more of the following index entries Entry type 1 byte unsigned integer 0 Segment with nominal start time nominal layer number and nominal frame number 1 Segment 2 Subframe 3 Exported image Offset 4 or 8 bytes unsigned integer Must be omitted if entry type 1 set equal to zero if the offset is unknown Nominal start time 4 or 8 bytes unsigned integer Start time of the segment measured in ticks from the beginning of the sequence assuming that all prior segments were played as intended on an ideal player ignoring any fPRI chunks Must be omitted if entry type 0 Nominal layer number 4 bytes unsigned integer Sequence number of the first layer in the segment assuming that all prior segments were played as intended on an ideal player ignoring any fPRI chunks the first layer of the first segment being layer 0 Must be omitted if entry type 0 Nominal frame number 4 bytes unsigned integer Sequence number of the first frame in the segment assuming that all prior segments were played as intended on an ideal player ignoring any fPRI chunks the first frame of the first segment being frame 0 Must be omitted if entry type 0 Name 1 79 bytes Latin 1 text Must be omitted for unnamed segments The contents of this field must be the same as the name field in the corresponding SEEK FRAM or eXPI chunk Separator 1 byte null must be omitted after the final entry The SAVE chunk must be present when the SEEK chunk is present It appears after the set of chunks that define information that must be retained for the remainder of the datastream These chunks collectively referred to as the prologue segment are no different from chunks in other segments They can be chunks that define objects or they can be chunks that define other information such as gAMA cHRM and sPLT If any chunks appear between the SAVE chunk and the first SEEK chunk these chunks also form a part of the prologue segment but their contents become undefined when the SEEK chunk appears Only one instance of the SAVE chunk is permitted in a MNG datastream It is not allowed anywhere after the first SEEK chunk It is not permitted at any point beyond the SAVE chunk to modify or discard any object that was defined ahead of the SAVE chunk An object appearing ahead of the SAVE chunk can be the subject of a CLON chunk If the clone is a partial clone modifying it is not permitted because this would also modify the object buffer that the original object points to A chunk like gAMA that overwrites a single current value is permitted after the SAVE chunk even if the chunk has appeared ahead of the SAVE chunk Decoders are responsible for saving a copy of the chunk data in any convenient form when the SAVE chunk is encountered and restoring it when skipping or jumping to a SEEK chunk from the interior of a segment If no instance of the chunk appeared ahead of the SAVE chunk the decoder must restore the chunk data to its original unknown condition when it skips or jumps to a SEEK chunk from the interior of a segment It is the encoder s responsibility if it changes or discards any saved data to restore it to its saved condition or to nullify it if it was unknown prior to the end of the segment This makes it safe for simple 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 In the case of chunks like sPLT that can occur multiple times with different purpose fields additional instances of the chunk are permitted after the SAVE chunk but not with the same keyword as any instances that occurred ahead of the SAVE chunk The decoder is required to forget such additional instances when it skips or jumps to a SEEK chunk from the interior of a segment but it must retain those instances that were defined prior to the SAVE chunk Encoders are required to nullify such additional instances prior to the end of the segment Known chunks in this category include only sPLT If an entry for a segment entry type 0 or 1 appears in the optional index there must also be an entry for every segment whether named or not except for the prologue segment that precedes it All entries must appear in the index in the same order that they appear in the MNG datastream There must never be a segment entry type 0 or 1 for the prologue segment but there can be entries for named images or subframes in the prologue placed ahead of the first segment entry Only named images or subframes are permitted and it is not an error to omit any or all named images or subframes Nor is it an error to omit a contiguous set of segments at the end of the datastream from the index Offsets are calculated from the first byte of the MNG 8 byte signature which has offset 0 This is true even if the MNG datastream happens to be embedded in some other file and the signature bytes are not actually present Applications with direct access to the datastream can use the index to find segments subframes and exported images quickly After processing the prologue segment they can jump directly to any segment and then process the remaining datastream until the desired subframe image or time is found Applications that have only streaming access to the datastream can still use the index to decide whether to decode the chunks in a segment or to skip over them Only one instance of the SAVE chunk is permitted in a MNG datastream If the SEEK chunk is present the SAVE chunk must be present prior to the first SEEK chunk The only chunks not allowed ahead of the SAVE chunk are the SEEK chunk and the MEND chunk The SAVE chunk must not appear inside a LOOP ENDL pair 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 from the interior of a segment The SEEK chunk can be empty or it can contain a segment name Segment name 1 79 bytes Latin 1 string The segment name is optional It must follow the format of a tEXt keyword It must consist only of printable Latin 1 characters and must not have leading or trailing blanks but can have single embedded blanks There must be at least one and no more than 79 characters in the keyword There is no null byte terminator within the segment name nor is there a separate null byte terminator Segment names are case sensitive Use caution when printing or displaying keywords Refer to Security considerations below Chapter 17 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 FRAME or FRAMES which are reserved for use in URI queries and fragments see Uniform Resource Identifier below Applications must not use any information preceding the SEEK chunk except for Data appearing in the MHDR chunk 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 from the interior of a segment 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 In addition to providing a mechanism for skipping frames or backspacing over frames the SEEK chunk provides a means of dealing with a corrupted datastream The viewer would abandon processing and simply look for the next SEEK chunk before resuming Note that looking for a PNG IHDR chunk would not be sufficient because the PNG datastream might be inside a loop or a Delta PNG datastream or it might need data from preceding MOVE or CLIP chunks When a decoder jumps to a seek point from the interior of a segment it must restore the information that it saved when it processed the SAVE chunk and it must reset the object attributes and magnification factors for object 0 to their default values When it encounters a SEEK chunk during normal sequential processing of a MNG datastream it need not restore 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 SEEK chunk is present The SEEK chunk must not appear between a LOOP chunk and its ENDL chunk 4 5 Ancillary MNG chunks This section describes ancillary MNG chunks MNG compliant decoders are not required to recognize and process them 4 5 1 eXPI Export image The eXPI chunk takes a snapshot of a viewable object either concrete or abstract associates the name with that snapshot and makes the name available to the outside world like a scripting language The chunk contains an object identifier snapshot id and a name Snapshot id 2 bytes unsigned integer Must be zero in MNG LC and MNG VLC datastreams Snapshot name 1 79 bytes Latin 1 text When the snapshot id is zero the snapshot is the first instance of an embedded image with object id 0 following the eXPI chunk When the snapshot id is nonzero the snapshot is an already defined object with that object id as it already exists when the eXPI chunk is encountered Note that the snapshot name is associated with the snapshot not with the snapshot id nor its subsequent contents changing the image identified by snapshot id will not affect the snapshot The snapshot name means nothing inside the scope of the MNG specification except that it can be included in the optional index that can appear in the SAVE chunk If two eXPI chunks use the same name it is the outside world s problem and the outside world s prerogative to regard it as an error It is recommended however that the snapshot name not be the same as that appearing in any other eXPI chunk or in any FRAM or SEEK chunk A decoder that knows of no outside world can simply ignore the eXPI chunk This chunk could be used in MNG datastreams that define libraries of related images rather than animations to allow applications to extract images by their snapshot id Names beginning with the word thumbnail are reserved for snapshot images that are intended to make good icons for the MNG Thumbnail images are regular PNG or Delta PNG images but they would normally have smaller dimensions and fewer colors than the MNG frames They can be defined with the potential visibility field set to invisible if they are not intended to be shown as a part of the regular display The snapshot name string must follow the format of a tEXt keyword It must consist only of printable Latin 1 characters and must not have leading or trailing blanks but can have single embedded blanks There must be at least one and no more than 79 characters in the keyword Keywords are case sensitive There is no null byte terminator within the snapshot name string nor is there a separate null byte terminator Snapshot names should not begin with the case insensitive strings CLOCK FRAME or FRAMES which are reserved for use in URI queries and fragments see Uniform Resource Identifier below Multiple instances of the eXPI chunk are permitted in a MNG datastream and they need not have different values of snapshot id 4 5 2 fPRI Frame priority The fPRI chunk allows authors to assign a priority to a portion of the MNG datastream Decoders can decide whether or not to decode and process that part of the datastream based on its priority compared to some measure of cost The fPRI chunk contains two bytes fPRI delta type 1 byte unsigned integer 0 Priority is given directly 1 Priority is determined by adding the fPRI data to the previous value modulo 256 Priority or delta priority 1 byte signed integer Value to be assigned to subsequent chunks until another fPRI chunk is reached While 256 distinct values of priority are possible it is recommended that only the values 0 low priority 128 medium priority and 255 high priority be used Viewers that can only display a single image can look for one with priority 255 and stop after displaying it If the datastream contains a large number of frames and includes periodic initial frames that do not contain Delta PNG datastreams each initial frame could be preceded by a fPRI with priority 128 and followed by one with priority 0 and the best representative initial frame could be preceded by a fPRI chunk with priority 255 Then single image viewers would just display the representative frame slow viewers would display just the initial frames and fast viewers would display everything If a viewer has established a nonzero cost it must skip any portion of the datastream whose priority is less than that cost The cost must be established prior to processing the proloque segment If the decoder changes its cost it must process again according to the new cost unless it knows that there were no fPRI chunks in the prologue segment The SAVE SEEK and MEND chunks always have priority 255 decoders must look for these chunks in addition to the fPRI chunk while skipping a low priority portion of the datastream It is not permissible for a portion of the datastream to depend on any portion of the datastream having a lower value because a decoder might have skipped the lower value portion Use of the fPRI chunk is illustrated in Example 5 and Example 9 Viewers that care about the priority must assume priority 255 for any portion of the MNG datastream that is processed prior to the first fPRI chunk Multiple instances of the fPRI chunk are permitted 4 5 3 nEED Resources needed The nEED chunk can be used to specify needed resources to provide a quick exit path for viewers that are not capable of displaying the MNG datastream The nEED chunk contains a list of keywords that the decoder must recognize Keywords are typically private critical chunk names Keyword 1 79 bytes 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 critical chunks defined in this specification or in the PNG specification should be named in a nEED chunk because MNG compliant decoders are required to recognize all of them whether they appear in a nEED chunk or not The purpose of the nEED chunk is only to identify requirements that are above and beyond the requirements of this document and of the PNG specification Each keyword string must follow the format of a tEXt keyword It must consist only of printable Latin 1 characters and must not have leading or trailing blanks but can have single embedded blanks There must be at least one and no more than 79 characters in the keyword Keywords are case sensitive There is no null byte terminator within the keyword A null separator byte must appear after each keyword in the nEED chunk except for the last one Decoders that do not recognize a chunk name or keyword in the list should abandon the MNG datastream or request user intervention The normal security precautions should be taken when displaying the keywords 4 5 4 pHYg Physical pixel size global The MNG pHYg chunk is identical in syntax to the PNG pHYs chunk It applies to complete full frame MNG layers and not to the individual images within them Conceptually a MNG viewer that processes the pHYg chunk will first composite each image into a full frame layer then apply the pHYg scaling to the layer and finally composite the scaled layer against the frame MNG datastreams can include both the PNG pHYs chunk either at the MNG top level or within the PNG and JNG datastreams and the MNG pHYg chunk only at the MNG top level to ensure that the images are properly displayed either when displayed by a MNG viewer or when extracted into a series of individual PNG or JNG datastreams and then displayed by a PNG or JNG application The pHYs and pHYg chunks would normally contain the same values but this is not necessary The MNG top level pHYg chunk can be nullified by a subsequent empty pHYg chunk appearing in the MNG top level 4 6 Ancillary PNG chunks The namespace for MNG chunk names is separate from that of PNG Only those PNG chunks named in this paragraph are also defined at the MNG top level They have exactly the same syntax and semantics as when they appear in a PNG datastream iTXt tEXt zTXt tIME Same format as in PNG Can appear at most once in the prologue segment before the first SEEK chunk and at most once per segment between two consecutive SEEK chunks In the prologue it indicates the last time any part of the MNG was modified In a regular segment between SEEK chunks or between the final SEEK chunk and the MEND chunk it indicates the last time that segment was modified A MNG editor that writes PNG datastreams should not include the top level iTXt tEXt tIME and zTXt chunks in the generated PNG datastreams cHRM gAMA iCCP sRGB bKGD sBIT pHYs These PNG chunks are also defined at the MNG top level They provide default values to be used in case they are not provided in subsequent PNG datastreams Any of these chunks can be nullified by the appearance of a subsequent empty chunk with the same chunk name Such empty chunks are not legal PNG or JNG chunks and must only appear in the MNG top level In the MNG top level all of these chunks are written as though for 16 bit RGBA PNG datastreams Decoders are responsible for reformatting the chunk data to suit the actual bit depth and color type of the datastream that inherits them A MNG editor that writes PNG or JNG datastreams is expected to include the top level cHRM gAMA iCCP and sRGB chunks in the generated PNG or JNG datastreams if the embedded image does not contain its own chunks that define the color space When it writes the sRGB chunk it should write the gAMA chunk and perhaps the cHRM chunk in accordance with the PNG specification even though no gAMA or cHRM chunk is present in the MNG datastream It is also expected to write the pHYs chunk and the reformatted top level bKGD chunk in the generated PNG or JNG datastreams and the reformatted sBIT chunk only in generated PNG 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 value that takes precedence over those that might be provided in subsequent PNG or JNG datastreams and provides a value to be used when it is not provided in subsequent PNG or JNG datastreams It also takes precedence over the PLTE chunk in a subsequent PNG datastream when the PLTE and hIST chunks are being used as a suggested palette i e color type 3 This chunk can appear for any color type There can be multiple sPLT chunks in a MNG datastream If a palette name is repeated the previous palette having the same palette name is replaced It is not permitted at the MNG top level to redefine a palette after the SAVE chunk with the same palette name as one that appears ahead of the SAVE chunk It is permitted however to define and redefine other palettes with other palette name fields A single empty sPLT chunk can be used to nullify all sPLT chunks that have been previously defined in the MNG top level except for those that appeared ahead of the SAVE chunk when the SAVE chunk has been read When a decoder needs to choose between a suggested palette defined at the MNG level and a suggested palette defined in the PNG datastream either with the sPLT chunk or with the PLTE hIST chunks for grayscale or truecolor images it should give precedence to the palette from the MNG level to avoid spurious layer to layer color changes MNG editors that write PNG datastreams should ignore the sPLT data from the MNG level and simply copy any sPLT chunks appearing within the embedded PNG datastreams 5 The JPEG Network Graphics JNG Format JNG JPEG Network Graphics is the lossy sub format for MNG objects MNG LC and MNG VLC applications can choose to support JNG or not Those that do not can check bit 4 JNG is present absent of the MHDR simplicity profile to decide whether they can process the datastream Note This specification depends on the PNG Portable Network Graphics 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 grayscale image that is to be used as an alpha mask and an IEND chunk The alpha mask if present must have the same dimensions as the image itself The JDAT and IDAT chunks can be interleaved Some of the PNG ancillary chunks are also recognized in JNG datastreams While JNG is primarily intended for use as a sub format within MNG a single image JNG datastream can be written in a standalone file If so the JNG datastream begins with an 8 byte signature containing 139 74 78 71 13 10 26 10 decimal 8b 4a 4e 47 0d 0a 1a 0a hexadecimal 213 J N G r n 032 n ASCII C notation which is similar to the PNG signature with 213 J N G instead of 211 P N G in bytes 0 3 We may at some future time register an Internet Media Type for JNG files Until then the interim media type image x jng can be used It is recommended that the file extension jng lower case preferred be used JNG is pronounced Jing 5 1 Critical JNG chunks This section specifies the critical chunks that are defined in the JNG format 5 1 1 JHDR JNG header The format of the JHDR chunk introduces a JNG datastream It contains Width 4 bytes unsigned integer range 0 65535 Height 4 bytes unsigned integer range 0 65535 Color type 1 byte 8 Gray Y 10 Color YCbCr 12 Gray alpha Y alpha 14 Color alpha YCbCr alpha Image sample depth 1 byte 8 8 bit samples and quantization tables 12 12 bit samples and quantization tables 20 8 bit image followed by a 12 bit image Image compression method 1 byte 8 ISO 10918 1 Huffman coded baseline JPEG Image interlace method 1 byte 0 Sequential JPEG single scan 8 Progressive JPEG 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 is also embedded in the JDAT datastream They appear in the JHDR chunk for convenience Their values must be identical to their equivalents embedded in the JDAT chunk We use four bytes in the width and height fields for similarity to MNG and PNG and to leave room for future expansion even though two bytes would have been sufficient When the color type is 8 or 10 no alpha channel the last four bytes which describe the IDAT or JDAA data must be set to zero The alpha sample depth must be nonzero when the alpha channel is present 5 1 2 JDAT JNG image data A JNG datastream must contain one or more JDAT chunks whose data when concatenated forms a complete JNG JPEG datastream JNG decoders are required to read all baseline JNG JPEG and eight bit progressive JNG JPEG datastreams Twelve bit capability is not required JDAT chunks are like PNG IDAT chunks in that there may be multiple JDAT chunks the data from which are concatenated to form a single datastream that can be sent to the decompressor No chunks are permitted among the sequence of JDAT chunks except for interleaved IDAT chunks The ordering requirements of other ancillary chunks are the same with respect to JDAT as they are in PNG with respect to the IDAT chunk A JNG JPEG is a baseline extended sequential or progressive JPEG as defined by JPEG Part 1 ISO IEC 10918 1 JNG uses only JFIF compatible JFIF component interpretations and imposes a few additional restrictions that reflect limitations of many existing JPEG implementations In particular only Huffman entropy coding is permitted 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 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 1 s definition of baseline JPEG further restricted by JFIF restrictions and JNG specific restrictions JNG JPEG also includes progressive JPEG which is also defined in JPEG Part 1 and has JNG specific restrictions Baseline JNG JPEG restrictions A baseline JPEG according to JPEG Part 1 is DCT based lossy sequential JPEG using 8 bit sample precision and Huffman entropy coding with the following further restrictions Quantization

    Original URL path: http://dlc.openindiana.org/oi-build/source-archives/mng-1.0-20010209-pdg.html (2016-02-01)
    Open archived version from archive

  • MNG-LC 1.0
    decoders Applications must not write MNG VLC datastreams or independent PNG datastreams with either the png or mng file extension with the new filter method until and unless it should become officially approved for use in PNG datastreams 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 The PNG oFFs and pHYs chunks and any chunks in a future version of this specification 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 is zero 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 4 2 4 JHDR JNG chunks IEND A JNG JPEG Network Graphics datastream See the JNG specification 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 MNG LC applications are not expected to process JNG datastreams unless they have been enhanced with JNG capability 4 2 5 TERM Termination action The TERM chunk suggests how the end of the MNG datastream should be handled when a MEND chunk is found It contains either a single byte or ten bytes Termination action 1 byte unsigned integer 0 Show the last frame indefinitely 1 Cease displaying anything 2 Show the first frame after the TERM chunk 3 Repeat the sequence starting immediately after the TERM chunk and ending with the MEND chunk Action after iterations 1 byte 0 Show the last frame indefinitely after iteration max iterations have been done 1 Cease displaying anything 2 Show the first frame after the TERM chunk This and the subsequent fields must be present if termination action is 3 and must be omitted otherwise Delay 4 bytes unsigned integer Delay in ticks before repeating the sequence Iteration max 4 bytes unsigned integer Maximum number of times to execute the sequence Infinity is represented by 0x7fffffff The TERM chunk if present must appear either immediately after the MHDR chunk or immediately prior to a SEEK chunk Only one TERM chunk is permitted in a MNG datastream Simple viewers and single frame viewers can ignore the TERM chunk It has been made critical only so MNG editors will not inadvertently relocate it 4 3 Critical MNG image displaying chunks The chunks in this section cause existing objects and embedded objects to be displayed on the output device and control their location clipping and timing and the background against which they are displayed 4 3 1 BACK Background The BACK chunk suggests or mandates a background color against which transparent clipped or less than full frame images can be displayed This information will be used whenever the application subsequently needs to insert a background layer unless another BACK chunk provides new background information before that happens The BACK chunk contains 6 7 9 or 10 bytes If any field is omitted all subsequent fields must also be omitted Red background 2 bytes unsigned integer Green background 2 bytes unsigned integer Blue background 2 bytes unsigned integer Mandatory background 1 byte unsigned integer 0 Background color is advisory Applications can use it if they choose to 1 Background color is mandatory Applications must use it This byte can be omitted If so the background color is advisory The first layer displayed by a viewer is always a background layer that fills the entire frame The BACK chunk provides a background that the viewer can use for this purpose or must use if it is mandatory If it is not mandatory the viewer can choose another background if it wishes If the BACK chunk is not present or if the background is not fully opaque or has been clipped to less than full frame the viewer must provide or complete its own background layer for the first frame Each layer after the first must be composited over the layers that precede it until a FRAM chunk with framing mode 3 or 4 causes another background layer to be generated Viewers are expected however to composite every foreground layer against a fresh copy of the background when the framing mode given in the FRAM chunk is 3 and to composite the first foreground layer of each subframe against a fresh copy of the background when the framing mode is 4 Also when the framing mode is 3 or 4 and no foreground layer appears between consecutive FRAM chunks a background layer alone is displayed as a separate frame The images and the background are both clipped to the subframe boundaries given in the FRAM chunk Anything outside these boundaries is inherited from the previous subframe If the background layer is transparent and the subsequent foreground layers do not cover the transparent area with opaque pixels the application s background becomes re exposed in any uncovered pixels within the subframe boundaries Note that any background layer including the one that begins the first frame of the datastream must be inserted at the latest possible moment in case the background image is replaced or in case a new BACK chunk appears before that moment The three BACK components are always written as though for an RGBA PNG with 16 bit sample depth For example a mid level gray background could be specified with the RGB color samples 1 09 1 09 1 09 The background color is interpreted in the current color space as defined by any top level gAMA cHRM iCCP sRGB chunks that have appeared prior to the BACK chunk in the MNG datastream If no such chunks appear the color space is unknown The data from the BACK chunk takes effect the next time the decoder needs to insert a background layer and remains in effect until another BACK chunk appears For the purpose of counting layers when the background consists of both a background color and a background image these are considered to generate a single layer and there is no delay between displaying the background color and the background image Multiple instances of the BACK chunk are permitted in a MNG datastream The BACK chunk can be omitted If a background is needed and the BACK chunk is omitted then the viewer must supply its own background For the purpose of counting layers such a viewer supplied background layer is counted the same as a background supplied by the BACK chunk In practice most applications that use MNG as part of a larger composition should ignore the BACK data if mandatory background 0 and the application already has its own background definition This will frequently be the case in World Wide Web pages to achieve nonrectangular transparent animations displayed against the background of the page 4 3 2 FRAM Frame definitions The FRAM chunk provides information that a decoder needs for generating frames and interframe delays The FRAM parameters govern how the decoder is to behave when it encounters a FRAM chunk or an embedded image The FRAM chunk also delimits subframes If bit 1 of the MHDR simplicity profile is 0 and bit 0 is 1 the FRAM chunk must not be present An empty FRAM chunk is just a subframe delimiter A nonempty one is a subframe delimiter and it also changes FRAM parameters either for the upcoming subframe or until reset upcoming subframe refers to the subframe immediately following the FRAM chunk When the FRAM chunk is not empty it contains a framing mode byte an optional name string a zero byte separator plus four 1 byte fields plus a variable number of optional fields When the FRAM parameters are changed the new parameters affect the subframe that is about to be defined not the one that is being terminated by the FRAM chunk Framing mode 1 byte 0 Do not change framing mode 1 No background layer is generated except for one ahead of the very first foreground layer in the datastream The interframe delay is associated with each foreground layer in the subframe 2 No background layer is generated except for one ahead of the very first image in the datastream The interframe delay is associated only with the final layer in the subframe A zero interframe delay is associated with the other layers in the subframe 3 A background layer is generated ahead of each foreground layer The interframe delay is associated with each foreground layer and a zero delay is associated with each background layer 4 The background layer is generated only ahead of the first foreground layer in the subframe The interframe delay is associated only with the final foreground layer in the subframe A zero interframe delay is associated with the background layers except when there is no foreground layer in the subframe in which case the interframe delay is associated with the sole background layer Subframe name 0 or more bytes Latin 1 Text Can be omitted if so the subframe is nameless Separator 1 byte null Must be omitted if the subsequent fields are also omitted Change interframe delay 1 byte 0 No 1 Yes for the upcoming subframe only 2 Yes also reset default This field and all subsequent fields can be omitted as a group if no frame parameters other than the framing mode or the subframe name are changed Change timeout and termination 1 byte 0 No 1 Deterministic for the upcoming subframe only 2 Deterministic also reset default 3 Decoder discretion for the upcoming subframe only 4 Decoder discretion also reset default 5 User discretion for the upcoming subframe only 6 User discretion also reset default 7 External signal for the upcoming subframe only 8 External signal also reset default This field can be omitted only if the previous field is also omitted Change layer clipping boundaries 1 byte 0 No 1 Yes for the upcoming subframe only 2 Yes also reset default This field can be omitted only if the previous field is also omitted Change sync id list 1 byte 0 No 1 Yes for the upcoming subframe only 2 Yes also reset default list This field can be omitted only if the previous field is also omitted Interframe delay 4 bytes unsigned integer This field must be omitted if the change interframe delay field is zero or is omitted The range is 0 2 31 1 ticks Timeout 4 bytes unsigned integer This field must be omitted if the change timeout and termination field is zero or is omitted The range is 0 2 31 1 The value 2 31 1 0x7fffffff ticks represents an infinite timeout period Layer clipping boundary delta type 1 byte unsigned integer 0 Layer clipping boundary values are given directly 1 Layer clipping boundaries are determined by adding the FRAM data to the values from the previous subframe This and the following four fields must be omitted if the change layer clipping boundaries field is zero or is omitted Left layer cb or Delta left layer cb 4 bytes signed integer Right layer cb or Delta right layer cb 4 bytes signed integer Top layer cb or Delta top layer cb 4 bytes signed integer Bottom layer cb or Delta bottom layer cb 4 bytes signed integer Sync id 4 bytes unsigned integer Must be omitted if change sync id list 0 and can be omitted if the new list is empty repeat until all sync ids have been listed The range is 0 2 31 1 Framing modes The framing mode provides information to the decoder that it uses whenever it is about to display an image and when it is processing the next FRAM chunk Any of these events generates a layer even if no pixels are actually changed Decoding a IHDR IEND sequence at the MNG level when it defines a potentially visible image Decoding a JHDR IEND sequence at the MNG level when it defines a potentially visible image Also decoding a FRAM chunk when the current framing mode requires a background layer framing mode is 3 or 4 and none of the above have already caused the background layer to be inserted since the previous FRAM chunk Such background layers must be included in the nominal layer count field of the MHDR chunk When a decoder is ready to perform a display update it must check the framing mode to decide whether it should restore the background framing modes 3 and 4 or not framing modes 1 and 2 and whether it needs to wait for the interframe delay to elapse before continuing framing modes 1 and 3 or not framing modes 2 and 4 When the interframe delay is zero viewers are not required actually to update the display but can continue to process the remainder of the frame and composite the next image over the existing frame before displaying anything The final result must appear the same as if each image had been displayed in turn with no delay Regardless of the framing mode encoders must insert a background layer with a zero delay ahead of the first image layer in the datastream even when the BACK chunk is not present or has been clipped to less than full frame This layer must be included in the layer count but not in the frame count Framing mode 1 When framing mode is 1 the decoder must wait until the interframe delay for the previous frame has elapsed before displaying each image Each foreground layer is a separate subframe and frame Framing mode 2 Framing mode 2 is the same as framing mode 1 except that the interframe delay occurs between subframes delimited by FRAM chunks rather than between individual layers All of the foreground layers between consecutive FRAM chunks make up a single subframe In the usual case the interframe delay is nonzero and multiple layers are present so each frame is a single subframe composed of several layers When the interframe delay is zero the subframe is combined with subsequent subframes until one with a nonzero interframe delay is encountered to make up a single frame The decoder must wait until the interframe delay for the previous frame has elapsed before displaying the frame When framing mode 2 viewers are expected to display all of the images in a frame at once if possible or as fast as can be managed without clearing the display or restoring the background Framing mode 3 When framing mode 3 a background layer is generated and displayed immediately before each image layer is displayed Otherwise framing mode 3 is identical to framing mode 1 Each foreground layer together with its background layer make up a single subframe and frame 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 generated and displayed immediately before each frame i e after each FRAM chunk with no interframe delay before each image The decoder must wait until the interframe delay for the previous frame has elapsed before displaying the background layer Otherwise framing mode 4 is identical to framing mode 2 All of the foreground layers between consecutive FRAM chunks together with one background layer make up a single subframe A transparent or clipped background layer is handled as in framing mode 3 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 blanks There must be at least one unless the subframe name is omitted and no more than 79 characters in the keyword Keywords are case sensitive There is no null byte within the keyword Applications can use this field for such purposes as constructing an external list of subframe in the datastream The subframe name only applies to the upcoming subframe subsequent subframes are unnamed unless they also have their own frame name field It is recommended that the same name not appear in any other FRAM chunk or in any SEEK or eXPI chunk Subframe names should not begin with the case insensitive strings CLOCK FRAME or FRAMES which are reserved for use in URI queries and fragments as explained in the full MNG specification The interframe delay value is the desired minimum time to elapse from the beginning of displaying one frame until the beginning of displaying the next frame When the interframe delay is nonzero which will probably be the usual case layers are frames When it is zero a frame consists of any number of consecutive subframes until a nonzero delay subframe is encountered and completed Decoders are not obligated or encouraged to display such subframes individually they can composite them offscreen and only display the complete frame There is no interframe delay before the first layer the implicit background layer in the datastream nor after the final frame regardless of the framing mode The timeout field can be a number or infinity Infinity can be represented by 0x7fffffff Under certain termination conditions the application can adjust the interframe delay provided that it is not greater than the sum of the specified interframe delay and the timeout The termination condition given in the change timeout and termination field specifies whether and over what range the normal interframe delay can be lengthened or shortened It can take the following values deterministic The frame endures no longer than the normal interframe delay Even though this is the default a streaming encoder talking to a real time decoder might write a FRAM with a termination condition of deterministic to force the display to be updated while the encoder decides its next move decoder discretion If the interframe delay is nonzero the decoder can shorten or lengthen the duration of the frame to any duration between the interframe delay and the timeout A streaming decoder could take the opportunity to wait for its input buffer to fill to a comfortable level user discretion If the interframe delay is nonzero the decoder should wait for permission from the user e g via a keypress before proceeding but must wait no less than the smaller of the timeout and the interframe delay nor no longer than the greater of the timeout and the interframe delay If the decoder cannot interact with the user this condition degenerates into decoder discretion external signal If the interframe delay is nonzero the decoder should wait for the arrival of a signal whose number matches a sync id but must wait no less than the smaller of the timeout and the interframe delay nor no longer than the greater of the timeout and the interframe delay If the decoder cannot receive signals this condition degenerates into decoder discretion The sync id list can be omitted if the termination condition is not external signal When the sync id list is changed the number of sync id entries is determined by the remaining length of the chunk data divided by four This number can be zero which either inactivates the existing sync id list for one frame or deletes it The initial values of the FRAM parameters are Framing mode 1 Subframe name empty string Interframe delay 1 Left subframe boundary 0 Right subframe boundary frame width Top subframe boundary 0 Bottom subframe boundary frame height Termination deterministic Timeout 0x7fffffff infinite Sync id empty list The layer clipping boundaries from the FRAM chunk are only used for clipping not for placement The DEFI chunk can be used to specify the placement of each image within the layer The DEFI chunk can be used to specify clipping boundaries for each image Even when the left and top subframe boundaries are nonzero the image locations are measured with respect to the 0 0 position in the display area The left and top subframe boundaries are inclusive while the right and bottom boundaries are exclusive If the layers do not cover the entire area defined by the layer clipping boundaries with opaque pixels they are composited against whatever already occupies the area when the framing mode is 1 or 2 When the framing mode is 3 or 4 they are composited against the background defined by the BACK chunk or against an application defined background if the BACK chunk is not present or does not define a mandatory background The images as well as the background are clipped to the layer clipping boundaries for the subframe Any pixels outside the layer clipping boundaries remain unchanged from the previous layer The interframe delay field gives the duration of display which is the minimum time that must elapse from the beginning of displaying one layer until the beginning of displaying the next unless the termination condition and timeout permit this time to be shortened It is measured in ticks using the tick length determined from ticks per second defined in the MHDR chunk When the interframe delay is zero it indicates that the layer is to be combined with the subsequent layer or layers into a single frame until a nonzero interframe delay is specified or the MEND chunk is reached A viewer does not actually have to follow the procedure of erasing the screen redisplaying the background and recompositing the images against it but what is displayed when the frame is complete must be the same as if it had It is sufficient to redraw the parts of the display that change from one frame to the next The sync id list provides a point at which the processor must wait for all pending processes to reach the synchronization point having the same sync id before resuming perhaps because of a need to synchronize a sound datastream not defined in this specification with the display to synchronize stereo images and the like When the period defined by the sum of the interframe delay and the timeout fields elapses processing can resume even though the processor has not received an indication that other processes have reached the synchronization point Note that the synchronization point does not occur immediately but at the end of the first frame that follows the FRAM chunk The identifier sync id 0 is reserved to represent synchronization with a user input from a keyboard or pointing device The sync id values 1 255 are reserved to represent the corresponding ASCII letter received from the keyboard or a simulated keyboard and values 256 1023 are reserved for future definition by this specification If multiple channels not defined in this specification are not present viewers can ignore other values appearing in the sync id list Note that the rules for omitting the interframe delay timeout clipping boundary and sync id fields of the FRAM chunk are different from the general rule stated in MNG Chunks above Chapter 4 These fields are either present in the chunk data or omitted from it according to the contents of the corresponding change byte 4 4 SAVE and SEEK chunks Simple decoders that only read MNG datastreams sequentially can safely ignore the SAVE and SEEK chunks 4 5 Ancillary MNG chunks This section describes ancillary MNG chunks MNG compliant decoders are not required to recognize and process them 4 5 1 eXPI Export image The eXPI chunk takes a snapshot of an image associates the name with that snapshot and makes the name available to the outside world like a scripting language The chunk contains an object identifier snapshot id and a name Snapshot id 2 bytes unsigned integer Must be zero in MNG LC datastreams Snapshot name 1 79 bytes Latin 1 text When the snapshot id is zero the snapshot is the first instance of an embedded image following the eXPI chunk Note that the snapshot name is associated with the snapshot not with the snapshot id nor its subsequent contents changing the image identified by snapshot id will not affect the snapshot The snapshot name means nothing inside the scope of the MNG LC specification If two eXPI chunks use the same name it is the outside world s problem and the outside world s prerogative to regard it as an error It is recommended however that the snapshot name not be the same as that appearing in any other eXPI chunk or in any FRAM chunk A decoder that knows of no outside world can simply ignore the eXPI chunk This chunk could be used in MNG datastreams that define libraries of related images rather than animations to allow applications to extract images by their snapshot id Names beginning with the word thumbnail are reserved for snapshot images that are intended to make good icons for the MNG Thumbnail images are regular PNG images but they would normally have smaller dimensions and fewer colors than the MNG frames They can be defined with the potential visibility field set to invisible if they are not intended to be shown as a part of the regular display The snapshot name string must follow the format of a tEXt keyword It must consist only of printable Latin 1 characters and must not have leading or trailing blanks but can have single embedded blanks There must be at least one and no more than 79 characters in the keyword Keywords are case sensitive There is no null byte terminator within the snapshot name string nor is there a separate null byte terminator Snapshot names should not begin with the case insensitive strings CLOCK FRAME or FRAMES which are reserved for use in URI queries and fragments see Uniform Resource Identifier below Multiple instances of the eXPI chunk are permitted in a MNG datastream and they need not have different values of snapshot id 4 5 2 pHYg Physical pixel size global The MNG pHYg chunk is identical in syntax to the PNG pHYs chunk It applies to complete full frame MNG layers and not to the individual images within them Conceptually a MNG viewer that processes the pHYg chunk will first composite each image into a full frame layer then apply the pHYg scaling to the layer and finally composite the scaled layer against the frame MNG datastreams can include both the PNG pHYs chunk either at the MNG top level or within the PNG and JNG datastreams and the MNG pHYg chunk only at the MNG top level to ensure that the images are properly displayed either when displayed by a MNG viewer or when extracted into a series of individual PNG or JNG datastreams and then displayed by a PNG or JNG application The pHYs and pHYg chunks would normally contain the same values but this is not necessary The MNG top level pHYg chunk can be nullified by a subsequent empty pHYg chunk appearing in the MNG top level 4 6 Ancillary PNG chunks The namespace for MNG chunk names is separate from that of PNG Only those PNG chunks named in this paragraph are also defined at the MNG top level They have exactly the same syntax and semantics as when they appear in a PNG datastream iTXt tEXt zTXt tIME Same format as in PNG Can appear at most once in the prologue segment before the first SEEK chunk and at most once per segment between two consecutive SEEK chunks In the prologue it indicates the last time any part of the MNG was modified In a regular segment between SEEK chunks or between the final SEEK chunk and the MEND chunk it indicates the last time that segment was modified A MNG editor that writes PNG datastreams should not include the top level iTXt tEXt tIME and zTXt chunks in the generated PNG datastreams cHRM gAMA iCCP sRGB bKGD sBIT pHYs These PNG chunks are also defined at the MNG top level They provide default values to be used in case they are not provided in subsequent PNG datastreams Any of these chunks can be nullified by the appearance of a subsequent empty chunk with the same chunk name Such empty chunks are not legal PNG or JNG chunks and must only appear in the MNG top level In the MNG top level all of these chunks are written as though for 16 bit RGBA PNG datastreams Decoders are responsible for reformatting the chunk data to suit the actual bit depth and color type of the datastream that inherits them A MNG editor that writes PNG or JNG datastreams is expected to include the top level cHRM gAMA iCCP and sRGB chunks in the generated PNG or JNG datastreams if the embedded image does not contain its own chunks that define the color space When it writes the sRGB chunk it should write the gAMA chunk and perhaps the cHRM chunk in accordance with the PNG specification even though no gAMA or cHRM chunk is present in the MNG datastream It is also expected to write the pHYs chunk and the reformatted top level bKGD chunk in the generated PNG or JNG datastreams and the reformatted sBIT chunk only in generated PNG 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 5 The JPEG Network Graphics JNG Format JNG JPEG Network Graphics is the lossy sub format for MNG objects It is described in the full MNG specification and is also available as a separate extract from the full MNG specification Both documents are available at the MNG home page http www libpng org pub mng MNG LC applications can choose to support JNG or not Those that do not can check bit 4 JNG is present absent of the MHDR simplicity profile to decide whether they can process the datastream 6 The Delta PNG Format Omitted 7 Extension and Registration New public chunk types and additional options in existing public chunks can be proposed for inclusion in this specification by contacting the PNG MNG specification maintainers at png info uunet uu net png group w3 org or at mng list ccrc wustl edu New public chunks and options will be registered only if they are of use to others and do not violate the design philosophy of PNG and MNG Chunk registration is not automatic although it is the intent of the authors that it be straightforward when a new chunk of potentially wide application is needed Note that the creation of new critical chunk types is discouraged unless absolutely necessary Applications can also use private chunk types to carry data that is not of interest to other applications Decoders must be prepared to encounter unrecognized public or private chunk type codes If the unrecognized chunk is critical then decoders should abandon the segment and if it is ancillary they should simply ignore the chunk Editors must handle them as described in the following section Chunk Copying Rules 8 Chunk Copying Rules The chunk copying rules for MNG are similar to those in PNG Authors of MNG editing applications should consult the full MNG specification for details 9 Minimum Requirements for MNG LC Compliant Viewers This section specifies the minimum level of support that is expected of MNG LC compliant decoders and provides recomendations for viewers that will support slightly more than the minimum requirements All critical chunks must be recognized but some of them can be ignored after they have been read and recognized Ancillary chunks can be ignored and do not even have to be recognized 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 Limiting the feature set in a widely deployed WWW browser to anything less than MNG with 8 bit JNG support would be highly inappropriate Some subsets of MNG support are listed in the following table more or less in increasing order of complexity MHDR Profile bits Profile Level of support 31 10 9 8 7 6 5 4 3 2 1 0 value 0 0 0 0 1 0 0 0 0 0 1 65 MNG VLC without transparency 0 0 1 1 1 0 0 1 0 0 1 457 MNG VLC 0 0 1 1 1 0 1 1 0 0 1 473 MNG VLC with JNG 0 0 1 1 1 0 0 1 0 1 1 459 MNG LC 0 0 1 1 1 0 1 1 0 1 1 475 MNG LC with JNG Validity Simple MNG features Must be zero in MNG LC Transparency JNG Must be zero in MNG LC Validity of bits 7 8 and 9 Semitransparency Background transparency Must be zero in MNG LC One reasonable path for an application developer to follow might be to develop and test the application at each of the following levels of support in turn MNG VLC MNG LC MNG LC with JNG MNG according to the full MNG specification An equally reasonable development path might be MNG VLC with JNG MNG LC with JNG MNG according to the full MNG specification 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 9 1 Required MNG chunk support MHDR The ticks per second must be supported by animation viewers The simplicity profile frame count layer count and nominal play time can be ignored Decoders that provide less than minimal support can use the simplicity profile to identify datastreams that they are incapable of processing MEND The MEND chunk must be recognized but does not require any processing other than completing the last frame Global PLTE and tRNS Must be fully supported Bit 1 of the simplicity profile can be used to promise that these chunks are not present DEFI BACK MAGN Must be fully supported FRAM The

    Original URL path: http://dlc.openindiana.org/oi-build/source-archives/mng-lc-1.0-20010209-pdg.html (2016-02-01)
    Open archived version from archive

  • MNG-VLC 1.0
    a default value if omitted This is permitted only when explicitly stated in the specification for the particular chunk If a field is omitted all the subsequent fields in the chunk must also be omitted and the chunk length must be shortened accordingly 4 1 Critical MNG control chunks This section describes critical MNG control chunks that MNG VLC compliant decoders must recognize and process Processing a chunk sometimes can consist of simply recognizing it and ignoring it Some chunks have been declared to be critical only to prevent them from being relocated by MNG editors 4 1 1 MHDR MNG datastream header The MHDR chunk is always first in all MNG datastreams except for those that consist of a single PNG or JNG datastream with a PNG or JNG signature The MHDR chunk contains 28 bytes none of which can be omitted Frame width 4 bytes unsigned integer Frame height 4 bytes unsigned integer Ticks per second 4 bytes unsigned integer Nominal layer count 4 bytes unsigned integer Nominal frame count 4 bytes unsigned integer Nominal play time 4 bytes unsigned integer Simplicity profile 4 bytes unsigned integer bit 0 Profile Validity 1 Absence of certain features is specified by the remaining bits of the simplicity profile must be 1 in MNG VLC datastreams bit 1 Simple MNG features 0 Simple MNG features are absent must be 0 in MNG VLC datastreams bit 2 Complex MNG features 0 Complex MNG features are absent must be 0 in MNG VLC datastreams bit 3 Internal transparency 0 Transparency is absent or can be ignored All images in the datastream are opaque or can be rendered as opaque without affecting the final appearance of any frame 1 Transparency may be present bit 4 JNG 0 JNG and JDAA are absent 1 JNG or JDAA may be present must be 0 in MNG VLC datastreams bit 5 Delta PNG 0 Delta PNG is absent must be 0 in MNG VLC datastreams bit 6 Validity flag for bits 7 8 and 9 0 The absence of background transparency semitransparency and stored object buffers is unspecified bits 7 8 and 9 have no meaning and must be 0 1 The absence or possible presence of background transparency is expressed by bit 7 of semitransparency by bit 8 and of stored object buffers by bit 9 bit 7 Background transparency 0 Background transparency is absent i e the first layer fills the entire MNG frame with opaque pixels 1 Background transparency may be present bit 8 Semi transparency 0 Semitransparency i e an image with an alpha channel that has values that are neither 0 nor the maximum value is absent 1 Semitransparency may be present If bit 3 is zero this field has no meaning bit 9 Stored object buffers 0 Object buffers need not be stored must be 0 in MNG LC and MNG VLC datastreams If bit 2 is zero this field has no meaning bits 10 15 Reserved bits Reserved for public expansion Must be zero in this version bits 16 30 Private bits Available for private or experimental expansion Undefined in this version and can be ignored bit 31 Reserved bit Must be zero Decoders can ignore the informative nominal frame count nominal layer count nominal play time and simplicity profile fields The frame width and frame height fields give the intended display size measured in pixels and provide clipping boundaries see Recommendations for encoders below The ticks per second field gives the framing rate It must be nonzero if the datastream contains a sequence of images When the datastream contains exactly one frame this field should be set to zero When ticks per second is nonzero viewers should display the sequence of frames at the rate of one frame per tick If the frame count field contains a zero the frame count is unspecified If it is nonzero it contains the number of frames that would be displayed ignoring the TERM chunk If the frame count is greater than 2 31 1 encoders should write 2 31 1 representing an infinite frame count In MNG VLC datastreams the frame count is the same as the number of embedded images in the datastream or one the background layer if there are no embedded images If the nominal layer count field contains a zero the layer count is unspecified If it is nonzero it contains the number of layers including the background layer in the datastream ignoring any effects of the TERM chunk If the layer count is greater than 2 31 1 encoders should write 2 31 1 representing an infinite layer count In MNG VLC datastreams the layer count is the number of embedded images plus one for the background layer If the nominal play time field contains a zero the nominal play time is unspecified Otherwise it gives the play time in ticks when the file is displayed ignoring the TERM chunk Authors who write this field should choose a value of ticks per second that will allow the nominal play time to be expressed in a four bit integer If the nominal play time is greater than 2 31 1 ticks encoders should write 2 31 1 representing an infinite nominal play time In MNG VLC datastreams the nominal play time is the same as the frame count except when the ticks per second field is zero in which case the nominal play time is also zero When bit 0 of the simplicity profile field is zero the simplicity or complexity of the MNG datastream is unspecified and all bits of the simplicity profile must be zero The simplicity profile must be nonzero in MNG VLC datastreams 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 transparency flags bit 4 being a JNG flag bit 5 being a Delta PNG flag and bit 9 being a stored object buffers flag Bit 6 is a validity flag for bits 7 8 and 9 which were added at version 0 98 of this specification These three flags mean nothing if bit 6 is zero If a bit is zero the corresponding feature is guaranteed to be absent or if it is present there is no effect on the appearance of any frame if the feature is ignored If a bit is one the corresponding feature may be present in the MNG datastream Bits 10 through 15 of the simplicity profile are reserved for future MNG versions and must be zero in this version Bits 16 through 30 are available for private test or experimental versions The most significant bit bit 31 must be zero Transparency is absent or can be ignored means that either the PNG tRNS chunk is not present and no PNG or JNG image has an alpha channel or if they are present they have no effect on the final appearance of any frame and can be ignored e g if the only transparency in a MNG datastream appears in a thumbnail that is never displayed in a frame or is in some pixels that are overlaid by opaque pixels before being displayed the transparency bit should be set to zero Semitransparency is absent means that if the PNG tRNS chunk is present or if any PNG or JNG image has an alpha channel they only contain the values 0 and the maximum opaque value It also means that the JDAA chunk is not present The semitransparency flag means nothing and must be 0 if bit 3 is 0 or bit 6 is 0 Background transparency is absent means that the first layer of every segment fills the entire frame with opaque pixels and that nothing following the first layer causes any frame to become transparent Whatever is behind the first layer does not show through 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 Note that bit 3 does not make any promises about background transparency The stored object buffers flag must be zero in MNG VLC datastreams 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 7 and 8 transparency equal to zero If bit 4 JNG is 1 the datastream is a MNG VLC with JNG datastream It might contain a JNG datastream carrying 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 datastreams or avoid possible optimizations For example the simplicity profile 351 0x15f indicates that JNG critical transparency semitransparency and at least one complex MNG feature are all present but Delta PNG stored object buffers and background transparency are not This example would not qualify as a MNG VLC datastream because a complex MNG feature might be present If the simplicity profile promises that certain features are absent but they are actually present in the MNG datastream the datastream is invalid 4 1 2 MEND End of MNG datastream The MEND chunk s data length is zero It signifies the end of a MNG datastream 4 1 3 LOOP ENDL Define a loop The LOOP chunk can be ignored by MNG VLC decoders along with the ENDL chunk 4 2 Critical MNG image defining chunks The chunks described in this section create images and may cause them to be immediately displayed 4 2 1 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 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 Nor are they allowed in MNG VLC datastreams The PNG oFFs and pHYs chunks and any chunks in a future version of this specification 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 4 2 2 JHDR JNG chunks IEND A JNG JPEG Network Graphics datastream See the JNG specification 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 MNG VLC applications are not expected to process JNG datastreams unless they have been enhanced with JNG capability 4 2 3 TERM Termination action The TERM chunk suggests how the end of the MNG datastream should be handled when a MEND chunk is found It contains either a single byte or ten bytes Termination action 1 byte unsigned integer 0 Show the last frame indefinitely 1 Cease displaying anything 2 Show the first frame after the TERM chunk 3 Repeat the sequence starting immediately after the TERM chunk and ending with the MEND chunk Action after iterations 1 byte 0 Show the last frame indefinitely after iteration max iterations have been done 1 Cease displaying anything 2 Show the first frame after the TERM chunk This and the subsequent fields must be present if termination action is 3 and must be omitted otherwise Delay 4 bytes unsigned integer Delay in ticks before repeating the sequence Iteration max 4 bytes unsigned integer Maximum number of times to execute the sequence Infinity is represented by 0x7fffffff The TERM chunk if present must appear either immediately after the MHDR chunk or immediately prior to a SEEK chunk Only one TERM chunk is permitted in a MNG datastream Simple viewers and single frame viewers can ignore the TERM chunk It has been made critical only so MNG editors will not inadvertently relocate it 4 3 Critical MNG image displaying chunks The chunk in this section provides the background against which images are displayed 4 3 1 BACK Background The BACK chunk suggests or mandates a background color against which transparent or less than full frame images can be displayed This information will be used whenever the application subsequently needs to insert a background layer unless another BACK chunk provides new background information before that happens The BACK chunk contains 6 7 9 or 10 bytes If any field is omitted all subsequent fields must also be omitted Red background 2 bytes unsigned integer Green background 2 bytes unsigned integer Blue background 2 bytes unsigned integer Mandatory background 1 byte unsigned integer 0 Background color is advisory Applications can use it if they choose to 1 Background color is mandatory Applications must use it This byte can be omitted If so the background color is advisory The first layer displayed by a viewer is always a background layer that fills the entire frame The BACK chunk provides a background that the viewer can use for this purpose or must use if it is mandatory If it is not mandatory the viewer can choose another background if it wishes If the BACK chunk is not present the viewer must provide its own background layer for the first frame Each layer after the first must be composited over the layers that precede it The three BACK components are always written as though for an RGBA PNG with 16 bit sample depth For example a mid level gray background could be specified with the RGB color samples 1 09 1 09 1 09 The background color is interpreted in the current color space as defined by any top level gAMA cHRM iCCP sRGB chunks that have appeared prior to the BACK chunk in the MNG datastream If no such chunks appear the color space is unknown The data from the BACK chunk takes effect the next time the decoder needs to insert a background layer and remains in effect until another BACK chunk appears For the purpose of counting layers when the background consists of both a background color and a background image these are considered to generate a single layer and there is no delay between displaying the background color and the background image Multiple instances of the BACK chunk are permitted in a MNG datastream The BACK chunk can be omitted If a background is needed and the BACK chunk is omitted then the viewer must supply its own background For the purpose of counting layers such a viewer supplied background layer is counted the same as a background supplied by the BACK chunk In practice most applications that use MNG as part of a larger composition should ignore the BACK data if mandatory background 0 and the application already has its own background definition This will frequently be the case in World Wide Web pages to achieve nonrectangular transparent animations displayed against the background of the page 4 4 SAVE and SEEK chunks Simple decoders that only read MNG datastreams sequentially can safely ignore the SAVE and SEEK chunks 4 5 Ancillary MNG chunks This section describes ancillary MNG chunks MNG compliant decoders are not required to recognize and process them 4 5 1 eXPI Export image The eXPI chunk takes a snapshot of an image associates the name with that snapshot and makes the name available to the outside world like a scripting language The chunk contains an object identifier snapshot id and a name Snapshot id 2 bytes unsigned integer Must be zero in MNG VLC datastreams Snapshot name 1 79 bytes Latin 1 text When the snapshot id is zero the snapshot is the first instance of an embedded image following the eXPI chunk Note that the snapshot name is associated with the snapshot not with the snapshot id nor its subsequent contents changing the image identified by snapshot id will not affect the snapshot The snapshot name means nothing inside the scope of the MNG VLC specification If two eXPI chunks use the same name it is the outside world s problem and the outside world s prerogative to regard it as an error It is recommended however that the snapshot name not be the same as that appearing in any other eXPI chunk A decoder that knows of no outside world can simply ignore the eXPI chunk This chunk could be used in MNG datastreams that define libraries of related images rather than animations to allow applications to extract images by their snapshot id Names beginning with the word thumbnail are reserved for snapshot images that are intended to make good icons for the MNG Thumbnail images are regular PNG images but they would normally have smaller dimensions and fewer colors than the MNG frames The snapshot name string must follow the format of a tEXt keyword It must consist only of printable Latin 1 characters and must not have leading or trailing blanks but can have single embedded blanks There must be at least one and no more than 79 characters in the keyword Keywords are case sensitive There is no null byte terminator within the snapshot name string nor is there a separate null byte terminator Snapshot names should not begin with the case insensitive strings CLOCK FRAME or FRAMES which are reserved for use in URI queries and fragments see Uniform Resource Identifier below Multiple instances of the eXPI chunk are permitted in a MNG datastream and they need not have different values of snapshot id 4 5 2 pHYg Physical pixel size global The MNG pHYg chunk is identical in syntax to the PNG pHYs chunk It applies to complete MNG layers and not to the individual images within them MNG datastreams can include both the PNG pHYs chunk either at the MNG top level or within the PNG and JNG datastreams and the MNG pHYg chunk only at the MNG top level to ensure that the images are properly displayed either when displayed by a MNG viewer or when extracted into a series of individual PNG or JNG datastreams and then displayed by a PNG or JNG application The pHYs and pHYg chunks would normally contain the same values but this is not necessary The MNG top level pHYg chunk can be nullified by a subsequent empty pHYg chunk appearing in the MNG top level 4 6 Ancillary PNG chunks The namespace for MNG chunk names is separate from that of PNG Only those PNG chunks named in this paragraph are also defined at the MNG top level They have exactly the same syntax and semantics as when they appear in a PNG datastream iTXt tEXt zTXt tIME Same format as in PNG Can appear at most once in the prologue segment before the first SEEK chunk and at most once per segment between two consecutive SEEK chunks In the prologue it indicates the last time any part of the MNG was modified In a regular segment between SEEK chunks or between the final SEEK chunk and the MEND chunk it indicates the last time that segment was modified A MNG editor that writes PNG datastreams should not include the top level iTXt tEXt tIME and zTXt chunks in the generated PNG datastreams cHRM gAMA iCCP sRGB bKGD sBIT pHYs These PNG chunks are also defined at the MNG top level They provide default values to be used in case they are not provided in subsequent PNG datastreams Any of these chunks can be nullified by the appearance of a subsequent empty chunk with the same chunk name Such empty chunks are not legal PNG or JNG chunks and must only appear in the MNG top level In the MNG top level all of these chunks are written as though for 16 bit RGBA PNG datastreams Decoders are responsible for reformatting the chunk data to suit the actual bit depth and color type of the datastream that inherits them A MNG editor that writes PNG or JNG datastreams is expected to include the top level cHRM gAMA iCCP and sRGB chunks in the generated PNG or JNG datastreams if the embedded image does not contain its own chunks that define the color space When it writes the sRGB chunk it should write the gAMA chunk and perhaps the cHRM chunk in accordance with the PNG specification even though no gAMA or cHRM chunk is present in the MNG datastream It is also expected to write the pHYs chunk and the reformatted top level bKGD chunk in the generated PNG or JNG datastreams and the reformatted sBIT chunk only in generated PNG 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 5 The JPEG Network Graphics JNG Format JNG JPEG Network Graphics is the lossy sub format for MNG objects It is described in the full MNG specification and is also available as a separate extract from the full MNG specification Both documents are available at the MNG home page http www libpng org pub mng MNG VLC applications can choose to support JNG or not Those that do not can check bit 4 JNG is present absent of the MHDR simplicity profile to decide whether they can process the datastream 6 The Delta PNG Format Omitted 7 Extension and Registration New public chunk types and additional options in existing public chunks can be proposed for inclusion in this specification by contacting the PNG MNG specification maintainers at png info uunet uu net png group w3 org or at mng list ccrc wustl edu New public chunks and options will be registered only if they are of use to others and do not violate the design philosophy of PNG and MNG Chunk registration is not automatic although it is the intent of the authors that it be straightforward when a new chunk of potentially wide application is needed Note that the creation of new critical chunk types is discouraged unless absolutely necessary Applications can also use private chunk types to carry data that is not of interest to other applications Decoders must be prepared to encounter unrecognized public or private chunk type codes If the unrecognized chunk is critical then decoders should abandon the segment and if it is ancillary they should simply ignore the chunk Editors must handle them as described in the following section Chunk Copying Rules 8 Chunk Copying Rules The chunk copying rules for MNG are similar to those in PNG Authors of MNG editing applications should consult the full MNG specification for details 9 Minimum Requirements for MNG VLC Compliant Viewers This section specifies the minimum level of support that is expected of MNG VLC compliant decoders and provides recomendations for viewers that will support slightly more than the minimum requirements All critical chunks must be recognized but some of them can be ignored after they have been read and recognized Ancillary chunks can be ignored and do not even have to be recognized 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 simple MNG features and JNG are absent is called MNG VLC In MNG VLC datastreams bit 0 of the simplicity profile must be 1 and bits 1 2 and 4 must 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 VLC Limiting the feature set in a widely deployed WWW browser to anything less than MNG with 8 bit JNG support would be highly inappropriate Some subsets of MNG support are listed in the following table more or less in increasing order of complexity MHDR Profile bits Profile Level of support 31 10 9 8 7 6 5 4 3 2 1 0 value 0 0 0 0 1 0 0 0 0 0 1 65 MNG VLC without transparency 0 0 1 1 1 0 0 1 0 0 1 457 MNG VLC 0 0 1 1 1 0 1 1 0 0 1 473 MNG VLC with JNG Validity Must be zero in MNG VLC Must be zero in MNG VLC Transparency JNG Must be zero in MNG VLC Validity of bits 7 8 and 9 Semitransparency Background transparency Must be zero in MNG VLC One reasonable path for an application developer to follow might be to develop and test the application at each of the following levels of support in turn MNG VLC MNG LC according to the MNG or MNG LC specification MNG LC with JNG MNG according to the full MNG specification An equally reasonable development path might be MNG VLC with JNG MNG LC with JNG according to the MNG or MNG LC specification MNG according to the full MNG specification 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 9 1 Required MNG chunk support MHDR The ticks per second must be supported by animation viewers The simplicity profile frame count layer count and nominal play time can be ignored Decoders that provide less than minimal support can use the simplicity profile to identify datastreams that they are incapable of processing MEND The MEND chunk must be recognized but does not require any processing other than completing the last frame BACK Must be fully supported DEFI LOOP ENDL SAVE SEEK TERM Must be recognized but can be ignored 9 2 Required PNG chunk support IHDR PLTE IDAT IEND All PNG 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 necessarily be displayed on the fly the image can be displayed after it is fully decoded The alpha channel must be supported at least to the degree that fully opaque pixels are opaque and fully transparent ones are transparent It is recommended that alpha be fully supported Alpha is not present or can be ignored because it has no effect on the appearance of any frame if bit 3 of the simplicity profile is 0 Bit 1 of the simplicity profile can be used to promise that only filter methods defined in the PNG specification are present tRNS The PNG tRNS chunk although it is an ancillary chunk must be supported in MNG compliant viewers at least to the degree that fully opaque pixels are opaque and fully transparent ones are transparent It is recommended that alpha data from the tRNS chunk be fully supported in the same manner as alpha data from an RGBA image or a JNG with an alpha channel contained in IDAT chunks The tRNS chunk is not present or can be ignored because it has no effect on the appearance of any frame if bit 3 of the simplicity profile is 0 Other PNG ancillary chunks Ancillary chunks other than PNG tRNS can be ignored and do not even have to be recognized Color management It is highly recommended that decoders support at least the gAMA chunk to allow platform independent color rendering If they support the gAMA chunk they must also support the sRGB chunk at least to the extent of interpreting it as if it were a gAMA chunk with gamma value 0 45455 9 3 Optional JNG chunk support Bit 4 of the simplicity profile can be used to promise that JNG chunks are not present Viewers that choose not to support JNG can check this bit before deciding to proceed 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 necessarily be displayed on the fly the image can be displayed after it is fully decoded The alpha channel must be supported at least to the degree that fully opaque pixels are opaque and fully transparent ones are transparent It is recommended that alpha be fully supported JNG ancillary chunks All JNG ancillary chunks can be ignored and do not even have to be recognized JNG image sample depth Only image sample depth 8 must be supported The JSEP chunk must be recognized and must be used by minimal decoders to select the eight bit version of the image when both eight bit and twelve bit versions are present as indicated by image sample depth 20 in the JHDR chunk When image sample depth 12 minimal decoders are not obligated to display anything Such decoders can choose to display nothing or an empty rectangle of the width and height specified in the JHDR chunk 10 Recommendations for Encoders The following recommendations do not form a part of the specification 10 1 Use a common color space It is a good idea to use a single color space for all of the layers in an animation where speed and fluidity are more important than exact color rendition This is best accomplished by defining a single color space at the top level of MNG using either an sRGB chunk or the gAMA and cHRM chunks and perhaps the iCCP chunk and removing any color space chunks from the individual images after converting them to the common color space When the encoder converts all images to a single color space before putting them in the MNG datastream decoders can improve the speed and consistency of the display For single frame MNG datastreams however decoding speed is less important and exact color rendition might be more important Therefore it is best to leave the images in their original color space as recommended in the PNG specification retaining the individual color space chunks if the images have different color spaces This will avoid any loss of data due to conversion 11 Recommendations for Decoders 11 1 Using the simplicity profile The simplicity profile in the MHDR chunk can be ignored or it can be used for Deciding whether to abandon a datatream immediately if it is beyond the decoder s capabilities Decoders are of course free to plunge ahead rendering whatever is possible and abandoning any segments that contain critical chunks that they do not recognize or cannot handle Unmanageable features might not be present even when the simplicity profile indicates that the features might be present The profile never guarantees that a certain feature is present it only guarantees that certain features are not present or have no effect on the appearance of any frame Deciding whether to perform certain optimizations For example the transparency flags can be used to determine whether full alpha composition is going to be necessary and to choose appropriate code paths and internal representations of abstract objects accordingly 11 2 Decoder handling of fatal errors When a fatal error is encountered such as a bad CRC or an unknown critical MNG chunk minimal viewers should simply abandon the MNG datastream 11 3 Decoder handling of interlaced images Decoders are required to be able to interpret datastreams that contain interlaced PNG images but are only required to display the completed frames they are not required to display the images as they evolve Viewers that are decoding datastreams coming in over a slow communication link might want to do that but MNG authors should not assume that the frames will be displayed in other than their final form 11 4 Decoder handling of palettes When a PLTE chunk is received it only affects the display of the PNG datastream that includes it Decoders must take care that it does not retroactively affect anything that has already been decoded If a frame contains two or more images the PLTE chunk in one image does not affect the display of the other A composite frame consisting only of indexed color images should not be assumed to contain 256 or fewer colors since the individual palettes do not necessarily contain the same set of colors 11 5 Behavior of single frame viewers Viewers that can only display a single frame must display the first frame that they encounter 11 6 Clipping MNG VLC provides the following types of clipping in addition to any clipping that might be required due to the physical limitations of the display device Frame width and frame height The frame width and frame height are defined in the MHDR chunk and cannot be changed by any other MNG chunk This is the only type of clipping available in MNG VLC datastreams Decoders can use these parameters to establish the size of a window in which to display the MNG frames When the frame width or frame height exceeds the physical dimensions of the display hardware the contents of the area outside those dimensions is undefined If a viewer chooses it can create scroll bars or the like to enable persons to pan and scroll to the offscreen portion of the frame If this is done then the viewer is responsible for maintaining and updating the offscreen portion of the frame In the case of a MNG datastream that consists of a PNG or JNG datastream with the PNG or JNG signature the frame width and frame height are defined by the width and height fields of the IHDR or JHDR chunk The clipping boundaries are expressed in pixels measured rightward and downward from the frame origin The left and top clipping boundaries are inclusive and the right and bottom clipping boundaries are exclusive i e the pixel located at x y is only displayed if the pixel falls within the physical limits of the display hardware and all of the following are true 0 x frame width from the MHDR chunk 0 y frame height 12 Recommendations for Editors Omitted 13 Miscellaneous Topics 13 1 File name extension On systems where file names customarily include an extension signifying file type the extension mng is recommended for MNG including MNG VLC files Lowercase mng is preferred if file names are case sensitive The extension jng is recommended for JNG files 14 Rationale This incomplete as of version 1 0 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 subframes of layers are defined instead of having a simpler DELA chunk that occurs in the stream where the delay is wanted DHDR delta types Some delta types are not allowed when the parent object is a JNG image Explain why types 4 and 6 pixel replacement

    Original URL path: http://dlc.openindiana.org/oi-build/source-archives/mng-vlc-1.0-20010209-pdg.html (2016-02-01)
    Open archived version from archive