The document discusses several image compression standards and formats: 1. The JPEG-LS standard describes near-lossless image encoding that reconstructs the input with a pre-specified error threshold. It uses context modeling, run-length encoding, and Golomb-Rice encoding of prediction errors. 2. The GIF format represents raster images using blocks including screen, graphic, and image descriptors along with color tables and LZW compression of pixel data. 3. Network-aware formats aim to balance compression efficiency with progressive transmission performance over packet-based networks by chunking images into maximum transmission unit sizes.

1. The Lossless JPEG standard
• y=(a+b)/2 = 145
• r=145-180=-35
• Category (r) = 6, Magnitude (r) = 100011
• 1’s complement of cat (r) = 011100
• Rep(35)={6,011100}
• Let Huff. code(6) = 1110
• Code(-35)=1110011100
100 191
100 180
MSB=0 fpr
numbers < 0
10 bits

2. The JPEG-LS standard
• Loco project (http://www.hpl.hp.com/loco/)
• Near-lossless encoding
• decoder output does not differ from the input
by no more than a pre-specified value
• JPEG-LS coder
• Context modeling – encoding of a pixel depends on the
previous pixels
• Run-length encoder – for smooth parts of the image
• Predictor – like in the lossless JPEG scheme
• Error Coder – to reconstruct the difference between the
prediction and the signal

3. The JPEG-LS standard
• Context Model
• two probability models: flat areas and edge-areas
• compute d1=d-a, d2=a-c, d3=c-b
• quantize d1, d2, d3 to Q1, Q2, Q3 using thresholds
T1, T2, T3. For 8-bit images they are 3, 7, 21
• any Q can take up to 9 possible values based on
the threshold interval it is in
• This produces 93
-1=728 combinations for
{Q1,Q2,Q3}, or 364 using symmetry
c a d
b X

4. The JPEG-LS standard
• Run-mode coder
• If gradients are close to 0, the encoder gets into a run-mode
• So long as |x-b| ≤ ε, the encoder reads subsequent samples
• Then it returns the run-length
• If end-of-line is reached, it encodes the last sample
• At the pixel x the predictor computes prediction error e=y-
x where
min(a,b) if c ≥ max(a,b)
y= max(a,b) if c ≤ min(a,b)
a+b-c
• Remove any prediction bias
• Remap e to e′ = 2e for positive e and –2e-1 for negative e
• Encode e′ with Golomb-Rice encoding

5. The JPEG-LS standard
• The parameter k for Golomb-Rice encoding is
obtained by
• k =
• A[i]: accumulated sum of prediction errors
• N[i]: number of prediction residuals seen in context i
• Removal of prediction bias
• Idea: the prediction error must follow a 2-sided
geometric distribution
• Computed using A[i] – how?
• B[i], sum of errors after correction and C[i], the
correction itself are also stored






][
][
log 2
iN
iA

6. Lempel-Ziv-Welch Compression
• Non-prefix encoding scheme
• Algorithm
• Step 1: Initialize string table with basic characters
• Step 2: Initialize prefix […] ← empty
repeat until no character left
• Step 3: Create variable currentStream by reading the next character C
from characterstream
• Step 4: Check if currentString in the string table
• If yes then […] ← […] C; go to step 3
• Else add to […] C the string table
• Output code for [...] to codestream
• […] ← next character
• Go to step 3

7. Lempel-Ziv-Welch Compression
• Take a 4 character alphabet: p q r s
• Consider a message “p q p r p q p”
• Construct String table
• 0:p, 1:q, 2:r, 3:s
• Initialize prefix
• prefix=[]
• currentstring = [] p
• This is in table, so prefix =[p]
• currentstring =[p] q
• Not in table, update table, and output code for p 0 →
• prefix=[q], code character : 0:p, 1:q, 2:r, 3:s, 4:pq
• currentstring =[q]p
• Not in table, update table, and output code for q 1 →
• Prefix=[p], code character : 0:p, 1:q, 2:r, 3:s, 4:pq, 5:qp

8. Representing digital raster
images
• Issues:
• Raw versus compressed
• Single-image versus multi- image
• Color representation
• Singe versus multi-resolution

9. The GIF Format
A file generated from the grammar
<GIF Data Stream> ::= Header <Logical Screen><Data>* Trailer
<Logical Stream> ::= Logical Screen Descriptor [Global Color Table]
<Data> ::= <Graphic Block> <Special Purpose Block>
<Graphic Block> ::= [Graphic Control Extension] <Graphic Rendering Block>
<Graphic Rendering Block> ::= <Table-Based Image> | Plain Text Extension
<Table-Based Image> ::= Image Descriptor [Local Color Table] Image Data
<Special Purpose Block> ::= Application Extension | Comment Extension
Control block
Not used for
decoding

10. The GIF Format
• Structure of a block
• Block Size:byte
• Data Value: byte
• Logical Screen Descriptor
• Logical Screen Width
• Logical Screen Height
• Packed Bits
• Global Color Table Flag
• Color Resolution: number of bits per primary color - 1
• Sort Flag
• Size of Global Color Table
• Background Color Index
• Pixel Aspect Ratio

11. The GIF Format
• Image Descriptor
• Image Separator
• Image Left Position
• Image Top Position
• Image Width
• Image Height
• Packed Fields
• Local Color Table Flag
• Interlace Flag: Interlace patter is 4-pass
• Sort Flag
• Size of Local Color Table

12. The GIF Format
• Table-Based Image Data
• LZW Minimum Code Size: same as number of color bits
• Compression Steps
– Establish Code Size
– Perform Compression
– Build Series of Bytes
– Package bytes into blocks
• Image Data in sub-blocks of at most 255 bytes
• Graphic Control Extension
• Extension Introducer
• Graphic Control Labrl
• Block Size
• Packed Bits
• Disposal method, user input flag, transparent color flag
• Delay Time
• Transparent Color Index

13. Network-Aware Formats
• A tradeoff problem
• Compression efficiency vs. progressive transmission
performance
• Network factors
• Packet loss
• Asynchronous arrival of packets at destination
• Progressive Transmission Factors
• % of picture visible as a function of time
• Same given a certain amount of packet loss

14. Network-Aware Formats
• Recent Research in University of Delaware
• NETCICATS project
(http://www.eecis.udel.edu/~iren/netcicats.html)
• Primary idea
• Break the picture into maximum transmission unit (MTU)
sized chunks that a link layer will carry without the IP layer
further fragmenting it
• The MTU sized picture fragments (also called application data
units) should be “self contained” to the extent possible

15. The GIFNC Proposal
• The Screen Descriptor
• An ADU could be a color map or data
• An ADU has an extra byte that identifies
• The image number of an image
• A local color map and the image identifier to which it belongs
• If an ADU is a color map
• The start and end indices of the color map
• The image descriptor
• The image is always interlaced
• L and G flags for the last image and all ADUs of the last image
respetively