INTERACTIVE TRANSMISSION OF JPEG 2000 IMAGES USING WEB PROXY CACHING

Anmol Sharma & Vidhyaa Muralidharan

Juan Pablo García Ortiz, Vicente González Ruiz,Manuel Francisco López, and Inmaculada García

IEEE TRANSACTIONS ON MULTIMEDIA, VOL. 10, NO. 4, JUNE 2008

Presenters:

How we’ll go about it….

IntroductionWeb Proxy CachingJPIP for Interactive TransmissionJPEG 2000 Image Compression• Core Coding System• The Current JPIP JPIP-W Proposal JPIP W Client-Server Messages Interaction example Performance Evaluation Conclusion and Critical Review

Authors’ Aim Present a new

Interactive Transmission protocol JPIP-W for JPEG 2000 Images.

Enhancement over the existing JPIP scheme

Improves JPEG image transmission by using web-proxy caching on the internet.

Introduction Remote Browsing Applications• Enables users to access images

stored on remote servers via the Internet.

• Common Examples: medical imaging, astronomical

observations, high-resolution maps and graphs.

• Image transmission is on-demand from the user.

• Users may only demand certain Window of Interest (WOI).

Traditional approach: User follows thumbnail/link to request image. Request goes to the server.Image broken into data-units, packetized, transmitted to client. --As switches en-route use a FIFO scheduling, Internet does not guarantee delivery-time.

Web Proxy Caching

Web Architecture supports Caching Internet and web-based services

designed to exploit remote access of data and images.

Caching fastens delivery by exploiting content redundancy.

Proxy Servers: Manage requests on behalf of the server, search local storage for desired content before asking for content recovery

Large-scale proxy infrastructure is now available, untapped for remote browsing.

JPIP for Interactive Transmission

JPIP / JPeg 2000 Interactive Protocol ISO/IEC 15444-9 (part 9) Client/Server Communication

Protocol. Delivers JPEG Images ensuring least bandwidth for

transmission. Enables relatively quick viewing of large images. Supports user described WOI, saving processing on both

ends. Does not support web-proxy caching schemes: Entire

image needs to be downloaded by the client to select a WOI.

Unable to tap the available infrastructure, slows performance for large JPEG 2000 Images.

JPEG 2000 Image Compression Standard

ISO/IEC15444-1: The ISO/ITU-T standard for image compression.

In this section we will discuss:

a.) The JPEG 2000 Core Coding System

b.) Elaborate on JPIP

JPEG 2000 Core Coding System

Based on Discrete Wavelet Transforms (DWT). Can use reversible filter for lossless coding or an irreversible

filter for lossy compression. JPEG 2000 gives better compression ratios for same quality

as in previous JPEG standards. Ideal standard for image compression for remote browsing

applications. Supports: multiple resolutions, arbitrary shaped WOI, Error

Resilience, Progressive Decoding and Random Access to Code Streams.

Advantages of the DWT include: (i) low entropy (ii) multi-resolution display, and (iii) spatial-frequency image display

Wavelet Transform Perform DWT onto the image

to an arbitrary depth.

Embedded Dead Zone Scalar Quantizer

Resultant coefficients are quantized to condense the no.

of bits in them.

EBCOT (Embedded Block Coding with Optimized Truncation)

Divides sub-bands into rectangular areas (code-blocks), progressively

and independently.

PrecintsCode Blocks joined to form rectangular blocks called

‘precints’. Precint size determined by the resolution.

SegmentationCode Block’s bit-stream

divided into ‘l’ quality layers selected for the image.

PacketizationSegments of a given quality

layer (li) are grouped together.

Image is divided by DWT into 1+3(r-1) frequency sub-bands where ‘r’ is the number of resolution levels of the image

Each resolution level is made up of HH, LH, HL sub-bands (High pass, Low pass Filters). LL band makes up a low resolution version of image.

Decoder’s default progression scheme set by the priority order of packet storage: LRCP,RLCP,RPCL,PCRL or CPRL, where L - quality layer, R - resolution, C- component and P- precinct

JPEG 2000 Interactive Protocol.

Used for developing applications for remote interactive browsing of images

Client side – User specifies WOI using application browser.

WOI passed to the JPIP client and decompressor modules.

Client manages communication with the server

Client’s request is read and the response is stored in the internal cache.

Decompressor module gathers the required cache information for image reconstruction.

JPIP Continued … Reconstructed image

shown to the user by the browser module.

Decompressor and browser modules run concurrently.

JPEG images stored in the server side.

Server receives a request for a WOI, reads and processes the associated image, extracts information needed by the client to reconstruct the requested WOI.

JPIP … Server optionally implements a cache

model to avoid resending redundant information.

Data bins – Pieces of data used by JPIP to manage the JPEG 2000 file contents.

Cache model and server responses organized into data bins.

JPIP can run on any transport mechanism.

Implementations use the HTTP Protocol.

Implementing JPIP using HTTP 2 Approaches: First Approach – Use HTTP for the

requests and responses; akin to typical Web communication.

Second Approach – Use HTTP for the messages and a secondary TCP connection for data transmission.

Client and server will both use HTTP messages but server responses will not contain data bins.

Implementation Approach 2 Continued

Server responses segmented in chunks which are sent over the TCP channel.

Client acknowledges every chunk received

Server manages data flow and maintains network efficiency and responsiveness.

JPIP Client Request. Consists of a common GET Image URL parameters indicated; used to

define the WOI. Example: Client requests a WOI of a resolution

with size <= 1024 x 768 pixels, offset of 100 x 100 pixels and region size 640 x 480

pixels. GET /image0.j2c?rsiz =640, 480&roff =100,100&fsiz = 1024, 768 HTTP/ 1.1 ⏎Host: get.jpeg.org⏎

JPIP Server Response Server answers with a HTTP image. Example: HTTP/ 1.1 200 OK ⏎ JPIP – roff: 0,0 ⏎ line header used by the server to notify the client that the initial offset has been

changed to 0,0

Content – type : image/ jpp-stream <Data-bins> Server can modify any parameter requested by the

client, or even modify the compression parameters when the image is sent.

Evaluation of the progression order of the transmissions

•PSNR of the image received (Lena, 512 x 512 pixel and 24 bit / pixel resolution) was evaluated as a function of the amount of data transmitted.

•Image was compressed using JPEG 2000 selecting 6 resolution levels, 16 quality layers and a 64 * 64 precinct.

•Compressed file was transmitted using all types of progression supported by the JPEG 2000 standard.

More on Evaluation of the Progression Order of the Transmissions

LRCP transmission produces the best image quality.

Similar results found for other images; better LRCP progression quality for larger images.

LRCP progression order most commonly used for progressive transfer of JPEG 2000 images.

JPIP – W Proposal Following features proposed to support proxy caching efficiently. Blocks – Web objects referenced by URLs. Contain sets of packets selected according to the progression

order used for transmission. JPEG 2000 packets grouped into blocks. For a given block size S, JPIP – W generates blocks of size s’ that

include the minimum number of packets whose total size is higher than or equal to S.

After a WOI request, the JPIP – W server sends the list of blocks the client needs to determine the URL of each block.

The JPIP – W response is always identical for the same JPIP – W request.

JPIP – W uses only HTTP as the transport protocol. Each JPIP – W response includes HTTP information to ensure

cacheability in proxies

JPIP-W Messages:Client requests Server

Client sends JPIP-W ‘GET’ message to server.GET/image0.j2c?rsiz=640X480&roff=100,100 &fsiz=1024,768

HTTP/1.1 ⏎Host: get.jpeg.org ⏎Connection: keep-alive ⏎JPIP-W: Yes ⏎ Persistent Connection ensured with Connection field: Keep-

alive would not close connection until Client satisfied. Persistent Connections ensure good performance. New header field JPIP-W indicates to the server that the

client side is operating JPIP-W for transaction. If server not configured to JPIP-W, it would ignore this field,

or set to ‘No’ in response.

JPIP-W Messages:Server’s Response to Client request

Server receives Client Request. Selects all blocks with at least one packet relevant to the requested WOI. Server’s response: List of all block indexes with their offsets (which help define

inter-relationship in packet decoding). Block Indexes &Offsets Format: Dependent-VBAS. Typical Server Response

HTTP/1.1 200 OK ⏎Connection: keep-alive ⏎JPIP-W-bsiz:1000 ⏎ //minimum block size associated with the block listJPIP-W: YES ⏎⏎<vbas(4)><vbas(58)><vbas(0)> // server returns Block 4 index coded in VBAS with its list of offset till

its 0.

<vbas(6)><vbas(22)><vbas(83)><vbas(0)> // next block index 10(4+6) sent with dependent offsets.

…

JPIP-W Messages:Client’s Response to Server

Once the list of blocks is received, the client would generate URL like filepaths within an image.

Each block’s URL is Image’s URL + block size + block index.

Client then sends GET by URL for each block.GET /image0.j2c/bsiz/1000/blk/5 HTTP/1.1 ⏎Host: get.jpeg.org ⏎Connection: keep-alive ⏎⏎ Simple scheme for addressing allows easy retrieval

at the server, better caching results at the proxies.

JPIP-W MessagesServer to client’s GET Block request.

Server manages response to each Block requested by Client through its URL.

Server’s response includes cacheability, lifetime details as headers for each block.

HTTP/1.1 OK ⏎Cache-Control: public ⏎ // signals that proxies can cache the blockDate: Thu, 3 Dec 2009 7:05:00 EST ⏎ Expires: Fri, 4 Dec 2009 7:05:00 EST ⏎ // helps avoid obsolete

dataConnection: keep-alive ⏎Content-length: 1340 ⏎ // Advisable for correct proxy behavior. Content-Type: application/octet-stream ⏎⏎…

Illustrative Example: JPIP

Client A requests ||WOI X||Client B requests || WOI Y||

WOI X and WOI Y share data-bins 0,1,2.

The overlapping data-bins have to be simply transported to the again as there are no proxies.

This could scale-up very fast in a real-time scenario and increase traffic especially on a critical server.

Illustrative Example: JPIP-W

Client A requests ||WOI X||Client B requests || WOI Y||

WOI X and WOI Y share data-bins 0,1,2

•List of blocks must be transmitted.•The first block-transfer in JPIP was faster.

JPIP-W gets faster from the second block transfer and speed increase is directly proportional to the number of overlaps.

Performance Evaluation. The impact of block size under different

transmission conditions was determined The efficiencies of JPIP and JPIP – W were

compared A set of clients communicates with a server

using a Squid Proxy Server. The available bandwidth between clients and

proxy was established to 100 Mbytes / s The available bandwidth between proxy and

server was set too 100 Kbytes / s, simulating a low speed channel.

Performance Evaluation … ISO 12640-2:2004 : set of 15 standard color images

(encoded as both 16-bit XYZ and 8-bit RGB digital data provided in electronic data files) that

Standard images used for the evaluation of changes in image quality during coding, image processing (including transformation compression and decompression), displaying on a color monitor.

The experiments were performed using two sets of natural 8 – bit RGB images. Set I contained three images ( woman with glass, fishing goods and silver) with size 3072 * 4096

Set II contained five images (flowers, Japanese goods, field fire, pier and threads) with a size of 4096 x 3072.

Numerical results shown in the figures are the average values of the PSNR for the two sets of images.

The average values of the PSNR of the reconstructed WOI are shown as a function of the block size, for a 3s transmission time.

Compression parameters used: Lossy compression Precinct size of 128 x 128 Code – block size of 64 x 64 Sixteen quality layers Eight resolution levels A WOI defined as (x, y, w, h, R) starts at coordinates

(x,y), has a size of w x h and has R resolution levels (0 is the highest resolution level)

LRCP progression order was used for the transmission of the images

Determination of Block Size Block size – Parameter which affects the efficiency of

any JPIP – W based application. Each block is transmitted with an HTTP header. The influence of block size was experimentally verified. For small sizes of block, (50 bytes or less), the header

overhead penalizes the performance. The data overhead decreases the PSNR when the size

of the block is bigger than about 1000 bytes. Highest PSNR values were observed for a block size

that ranges from 100 to 1000 bytes. Hence block size of 500 bytes was chosen for the

experiments.

Comparison between JPIP and JPIP-W

The performance of JPIP and JPIP-W are compared in two cases.

In the first case, the experiment aimed at calculating the efficiencies of the two protocols when WOIs with different percentages of overlapping are transmitted.

In the second case, the experiment focused on a typical user who is interested in a small region of a huge image.

Case 1 : Comparison with Different Overlappings

To compare the efficiencies of JPIP – W and JPIP, the quality of the WOIs received was evaluated as a function of the transmission time.

It is assumed that there is a WOI stored in the proxy cache.

Three percentages of spatial overlapping of the requested WOI with the cached one were used (0%, 25% and 50%).

Case 1 – Experimental Results Although the JPIP – W

latency is worse than JPIP latency, after an initial period of time (Approximately 2s), the quality obtained by JPIP – W is much better than that provided by JPIP.

Even in the case of 0% of WOI overlapping, JPIP – W is better than JPIP.

Comparison in Typical Image Browsing.

Goal : To compare the performance of JPIP-W and JPIP in a scenario where a user interested in a WOI zooms in successively on a huge image.

The client indicates the URL of a remote image, with no further parameters.

The browser requests the maximum resolution that fits in the user screen from the server.

This is the default size of the WOIs, unless the user modifies it.

Small user display of 800 x 600 used. The test involved the browser initially

requesting a (0,0,348,512,3) WOI for the images of the set II.

The user zooms in successively, without modifying either the height or the width of the initial sequence of requested WOI, until the user acquires the lower right hand corner.

The sequence of requested WOIs was (0,0,348,512,3) , (348, 512, 348, 512, 2) and (1152, 1536, 348, 512, 1) for images of set 1

The sequence of requested WOIs was (0,0,512, 348, 3), (348, 512, 348, 512, 2) and (1536, 1152, 512, 384, 1) for the images of set II. Lines with triangles represent the case where the proxy cache starts out empty. Lines with squares represent the case of a non-empty proxy cache.

Results … In the case of the JPIP – W protocol, two different

cases were assumed. Case 1: The proxy cache starts out empty. Case 2: In the beginning, the proxy cache contains

the result of the interaction of another user on the same image: the WOI (0,0,348,512,3) for the set I, and the WOI (0,0,512,348,3) for the set II.

JPIP – W (initially cached) outperforms JPIP, after the initial delay, in all three different situations. Also, when the cache is empty, the efficiency of JPIP – W is only a little worse than JPIP.

Conclusion

JPIP-W proven to enhance the current JPIP. Minimal overhead in upgrading to JPIP-W Scope and need of Interactive

Transmission of high-quality image content over the internet is increasing rapidly.

Internet encourages utilization of existing infrastructure (web proxies) and protocols (JPEG 2000/HTTP).

Critical Review The suggested enhancement requires no

new protocols, no special processing. The scheme can be implemented with

ease and would result in better performance of Remote Browsing Applications.

Experimentation results are carefully modeled.

Implementation level testing needed for practical performance evaluation.

Thank You!

Questions?