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