The Lossless JPEG standard
100
191
100
180
•
•
•
•
•
•
•
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}
MSB=0 fpr
numbers < 0
Let Huff. code(6) = 1110
Code(-35)=1110011100
10 bits
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
The JPEG-LS standard
• Context Model
c
a
b
X
d
• 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
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=yx 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
The JPEG-LS standard
• The parameter k for Golomb-Rice encoding is
obtained by

A[i ] 
log
2

N [i ] 

• 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
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
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
Representing digital raster
images
• Issues:
•
•
•
•
Raw versus compressed
Single-image versus multi- image
Color representation
Singe versus multi-resolution
The GIF Format
Control block
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
Not used for
decoding
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
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
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
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
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
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