1 / 40

Interactive Transmission of JPEG 2000 Images using web proxy caching

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. Interactive Transmission of JPEG 2000 Images using web proxy caching. Anmol Sharma & Vidhyaa Muralidharan. Presenters:.

chip
Download Presentation

Interactive Transmission of JPEG 2000 Images using web proxy caching

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 Interactive Transmission of JPEG 2000 Images using web proxy caching Anmol Sharma & Vidhyaa Muralidharan Presenters:

  2. How we’ll go about it…. Introduction Web Proxy Caching JPIP for Interactive Transmission JPEG 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

  7. 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

  8. 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

  9. 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.

  10. 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.

  11. 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.

  12. ImplementingJPIPusingHTTP • 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.

  13. 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.

  14. JPIPClientRequest. • 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⏎

  15. 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.

  16. 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.

  17. 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.

  18. 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

  19. 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.

  20. 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 list JPIP-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. …

  21. 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.

  22. 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 block Date: Thu, 3 Dec 2009 7:05:00 EST ⏎ Expires: Fri, 4 Dec 2009 7:05:00 EST ⏎ // helps avoid obsolete data Connection: keep-alive ⏎ Content-length: 1340 ⏎ // Advisable for correct proxy behavior. Content-Type: application/octet-stream ⏎ ⏎ …

  23. 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.

  24. 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.

  25. 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.

  26. 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.

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

  28. 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

  29. 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.

  30. 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.

  31. 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%).

  32. 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.

  33. 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.

  34. 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.

  35. 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

  36. 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.

  37. 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.

  38. 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).

  39. 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.

  40. Questions? Thank You!

More Related