Page 170 - ITU Journal, ICT Discoveries, Volume 3, No. 1, June 2020 Special issue: The future of video and immersive media
P. 170

ITU Journal: ICT Discoveries, Vol. 3(1), June 2020



               The sequential lossless mode is not based on DCT but is a predictive coding technique. The predicted value
               of each pel position is calculated from up to three of its nearest neighbours above and to the left, and the
               difference between the predicted value and the actual value is entropy encoded losslessly. For the lossless
               mode of operation, sample precisions from 2 bits per sample to 16 bits per sample are allowed.
               In the hierarchical mode, an image (or image component) is transmitted with increasing spatial resolution
               between progressive stages by first downsampling the image a number of times to produce a reference
               stage, which is transmitted by one of the other three modes of operation. The output of each hierarchical
               stage is used as the prediction for the next stage and the difference is coded. The coding of the differences
               may be done using only DCT-based processes, only lossless processes or DCT-based processes with a final
               lossless process for each component.
               All decoders that include any DCT-based mode of operation shall provide a default decoding capability,
               referred to as the baseline sequential DCT process. This is a restricted form of the sequential DCT-based
               mode, using Huffman coding and 8 bits per sample precision for the source image.”
          This  quote  is  a  very  good  description  of  what  the  JPEG  toolkit  does,  but  in  practice  ITU-T  T.417 |
          ISO/IEC 8613-7  [21]  including  the  raster  graphic  content  architecture  was  too  complex,  with  not  many
          implementations. On the web, hypertext markup language (HTML) standards including JPEG-1 dominate.

          4.1.6  ISDN Videophone still image transmission: ITU-T H.261 [10]
          Annex D of ITU-T H.261 [10] reads,
               “This  annex  describes  the  procedure  for  transmitting  still  images  within  the  framework  of  this
               Recommendation. This procedure enables an H.261 video coder to transmit still images at four times the
               normal video resolution by temporarily stopping the motion video. Administrations may use this optional
               procedure as a simple and inexpensive method to transmit still images. However, Recommendation T.81
               (JPEG) is preferred when the procedures for using T.81 within audiovisual systems are standardized.”
          ITU-T H.261 [10], which became the mother of all later video coding standards in the ITU (and also ISO/IEC
          JTC1/SC29 MPEG), was specified in CCITT SGXV by the so-called Okubo Group. JPEG had liaison and contacts
          with the Okubo group and some harmonization effort took place, e.g. on Huffman coding. However, it was
          completely coincidental that both the Okubo Group and JPEG found in the tests and selection that a DCT-based
          image-coding  standard  provided  the  best  quality  images  and  should  be  the  base  for  both  standards.
          Nevertheless,  it  was  not  easy  for  SGXV  to  accept  that  in  Annex  D  of  ITU-T  H.261  [10],  they  should  give
          preference to the JPEG format. However, in practice, there are only a few use cases of ITU-T H.320 [9] ISDN
          videophones, e.g. in Germany; however, the few thousand implementations cannot compete with web-based
          videophones, e.g. Skype and Zoom, etc.

          4.2   JPEG file interchange format

          The development of the JPEG file interchange format (JFIF) [22][23] was a most useful and successful gap-
          filling activity for the ISO/IEC JTC1 side. While in the ITU-T there was, from the very beginning, a clear strategy
          to include ITU-T T.81 in several ITU-T applications (see 4.1), on the JTC1 side this was completely ignored. So,
          it had to be filled by an ad hoc activity from members of the IT Industry:
          Wikipedia [23] reads,
               “Development of the JFIF document was led by Eric Hamilton of C-Cube Microsystems, and agreement on
               the first version was established in late 1991 at a meeting held at C-Cube involving about 40 representatives
               of various computer, telecommunications, and imaging companies. For nearly 20 years, the latest version
               available was v1.02, published September 1, 1992

               In 1996, RFC 2046 specified that the image format used for transmitting JPEG images across the internet
               should be JFIF. The MIME type of "image/jpeg" must be encoded as JFIF. In practice, however, virtually all
               Internet software can decode any baseline JIF image that uses Y or YCbCr components, whether it is JFIF
               compliant or not.







          148                            © International Telecommunication Union, 2020
   165   166   167   168   169   170   171   172   173   174   175