Interactive Transmission of JPEG2000 Images ... - Semantic Scholar

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

629

Interactive Transmission of JPEG2000 Images Using Web Proxy Caching Juan Pablo García Ortiz, Vicente González Ruiz, Manuel Francisco Lopez, and Inmaculada García

Abstract—This paper describes and analyzes JPIP-W, an innovative proposal for the interactive transmission of JPEG2000 images on the Internet. JPIP-W is an extension of JPIP, the current JPEG protocol proposed for interactive JPEG2000 image browsing. One of the JPIP characteristics of greatest interest is its ability to use the Web for retrieving images. However, JPIP is unable to exploit the large infrastructure of today’s Web caching systems (proxies), used to reduce response time and network traffic. To overcome this drawback, JPIP-W defines a new server-client interaction consisting of splitting JPEG2000 images into data blocks that can be cached by the proxies. These blocks can be shared among several clients, allowing fast recovery of some portions of the images. Experimental results demonstrate that JPIP-W significantly reduces JPIP retrieving times. Index Terms—JPEG2000, JPIP, progressive image transmission, remote browsing of images, web caching.

I. INTRODUCTION

R

EMOTE image browsing is widely used in today’s applications, such as remote surveillance, e-commerce, teleconference, medical diagnosis, remote astronomy, telemicroscopy and remote image databases, among others. In these applications, users visualize digital images stored in remote servers using the Internet as the communication media. In a remote browsing scenario, images are transmitted on demand from a server to a client (see Fig. 1). Basically, the server splits the image into pieces of data that are encapsulated in packets which are going to be transmitted to the client. As a consequence of the FIFO scheduling mechanism used by the switches to dispatch the incoming packets, the Internet does not provide a service that promises how long it will take to deliver the data from the sender to the receiver. Therefore, regardless of the underlying protocol, each packet spends a finite, but unpredictable, amount of transmission time between the server and the client. Let be the transmission time of the first packet the client receives. After this initial delay, and depending on the network bandwidth available, the remaining packets arrive after seconds. Therefore, the user can visualize the full image after a delay of seconds. To minimize , images must be transmitted in a compressed format. In general, is approximately reduced by a factor of Manuscript received february 1, 2007; revised December 2, 2007. This work was supported in part by Grants TIN2005-00447 (Spanish Ministry of Education and Science) and P06-TIC-01426 (Consejería de Innovación, Ciencia y Empresa, Junta de Andalucía). The associate editor coordinating the review of this manuscript and approving it for publication was Dr. S.-H. Gary Chan. The authors are with the Computer Architecture and Electronic Department, University of Almería 04120 Almería, Spain (e-mail: [email protected]; [email protected]; [email protected]; [email protected]). Digital Object Identifier 10.1109/TMM.2008.921738

Fig. 1. Remote browsing scenario.

2 using lossless compression, and by a factor between 10 and 200 using lossy compression. However, for large images, is a significant time even with lossy compression. To reduce the browsing delay even more, progressive (or scalable) image compression systems, must be used. In progressive display, because just a few data packets are enough to show a low-quality version of the image. Furthermore, remote browsing applications usually allow users to retrieve a lower resolution version of the image and/or a spatial portion of the image, called Window Of Interest (WOI). The JPEG2000 image compression standard achieves high compression ratios and supports lossless or lossy compression, progressive transmission and spatial scalability. The Web is an Internet application used to retrieve remote data. One of its most interesting features is that it operates on demand: users wish to receive what they want, when they want it. On the Web, the transmission time for retrieving objects is considerably reduced by means of caching. This technique exploits the redundancy in the traffic between clients and servers by using intermediate proxy servers [1]. A proxy server is a network entity that manages HTTP requests on behalf of an origin server and allows to reduce the response time of the clients requests [2]. Thus, when the proxy receives a request, it searches for the object in a local storage system and sends it to the client. Today, an important proxy server infrastructure is available, reducing Web response time and network congestion. JPEG2000 provides a specific protocol for developing remote browsing applications, called JPIP (JPeg2000 Interactive Protocol) [3]. JPIP is suitable for its use with the Internet Web platform, but it does not exploit the inherent caching system at all. In this kind of applications, the images are usually large and clients are interested in recovering only a part of them (WOI). Proxy servers only process complete Web objects (in this case,

1520-9210/$25.00 © 2008 IEEE Authorized licensed use limited to: University of Florida. Downloaded on October 17, 2009 at 10:23 from IEEE Xplore. Restrictions apply.

630


full images). Therefore, the current remote browsing applications based on JPIP do not use proxies efficiently because they would need to download the whole image in advance to allow the user to view any region. Proxy caching of multimedia objects is becoming more important every day for the improvement of Web application performance [4], [5]. Deshpande and Zeng proposed an architecture for streaming JPEG2000 images over Hypertext Transfer Protocol [6]. This approach uses byte-ranging as defined in HTTP/1.1 but most Web proxies do not cache byte-ranges. Liang and Chang focused on an HTTP streaming mechanism for JPEG2000 images that improves bandwidth performance by splitting image data [7]. This paper proposes a modified JPIP standard, called JPIP-W (JPIP for the Web), that is able to use proxies for reducing client response time and server bandwidth usage. Results show that JPIP-W outperforms JPIP when cached data is shared between clients. The rest of the paper is organized as follows: Section II describes the JPEG2000 standard and its JPIP protocol. JPIP-W is described in Section III and evaluated and compared to JPIP in Section IV. Finally, Section V presents the conclusions. II. JPEG2000 IMAGE COMPRESSION STANDARD JPEG2000 (ISO/IEC 15444-1) [8] is an ISO/ITU-T standard for still image coding. Compared to JPEG (ISO/IEC 10918-1) [9], JPEG2000 compression ratios are better for the same image quality, especially at very low bit-rates. Some features of JPEG2000 are progressive decoding, error-resilience, arbitrarily shaped WOI coding and random access to the code-stream. Therefore, JPEG2000 is ideal for coding and remote retrieving of large images. A. The Core Coding System JPEG2000 is based on the dyadic DWT (Discrete Wavelet Transform) that can be performed with either a reversible filter (which provides for lossless coding) or an irreversible one (more suitable for lossy compression due to its linearity). The DWT spatial frequency subdecomposes images into bands, where is the number of resolution levels. Each level , and , where is composed of three subbands stands for the low-pass filter used in the DWT and stands subband is a low-resolution verfor the high-pass filter. The sion of the original image. The main advantages of the DWT domain are: i) low entropy, ii) multiresolution display, and iii) spatial-frequency image display, which enables fine-grain distortion scalability when the wavelet coefficients are coded by bit-planes. The DWT transformation is followed by a quantization stage. It uses an embedded dead-zone scalar quantizer, which in the reversible path is equivalent to selecting the bit-planes of the coefficients, starting with the most significant. Then, each subband is divided into rectangular areas (the so called code-blocks), typically 64 64 or 32 32 coefficients, progressively and independently coded using EBCOT (Embedded Block Coding with Optimized Truncation) [10]. The code-blocks are grouped into rectangular areas called precincts, the size of which can change with each resolution

Fig. 2. Client-server architecture of JPIP.

level. The bit-stream of each code-block is divided into segments, where is the number of quality layers selected for the compressed image. The size of each segment depends on the contribution of the code-block to the quality layer. The segments belonging to the same quality layer, for a given precinct, are grouped in a packet. The JPEG2000 standard is described in several parts. The Core System (Part 1) describes how to build the simplest codestream containing the packets generated by the compression process [11]. The order selected to store the packets determines the default progression used by the decompressor to reconstruct the image. The standard defines the following kinds of progressions: LRCP, RLCP, RPCL, PCRL and CPRL, where L stands for quality layer, R for resolution, C for component and P for precinct. The image can be transmitted using any existing progression order, regardless of the order chosen to store the image in the server. B. The JPEG2000 Interactive Protocol Applications for remote interactive browsing of images can be developed using the JPIP protocol defined in Part 9 of the standard [3], [12]. Fig. 2 shows the communication model utilized by the client and the server defined by JPIP. On the client side, the user specifies a WOI using the application browser. This WOI is passed to the JPIP client and decompressor modules. The first one manages communication with the server, making the request and reading the responses. When the information is read, it is stored in the internal cache. The decompressor module gathers the required cache information for WOI reconstruction, which is shown to the user by the browser module. The decompressor and the browser modules run concurrently. The JPEG2000 images are stored on the server side. When the JPIP server receives a client request for a specific WOI, it reads and processes the associated image, extracting the information that must be sent to the client to reconstruct the requested WOI.

Authorized licensed use limited to: University of Florida. Downloaded on October 17, 2009 at 10:23 from IEEE Xplore. Restrictions apply.

ORTIZ et al.: INTERACTIVE TRANSMISSION OF JPEG2000 IMAGES

The server optionally implements a cache model that is used to avoid resending redundant information. The cache model and the server responses are organized in structures called data-bins which are pieces of data used by JPIP to manage the JPEG2000 file contents. JPIP can run on any transport mechanism and its implementations commonly use the HTTP protocol, e.g., Kakadu or 2KAN [13], [14]. In this context, it can work in two different ways. The straightforward way is to use HTTP for the requests and responses, as in a typical Web communication. The alternative is to use HTTP for the messages and a secondary TCP connection for data transmission. In this case, both the client and the server use HTTP messages, but the server responses do not contain data-bins; these responses are segmented in “chunks” which are sent over the TCP channel. The client confirms to the server every chunk received, allowing the server to manage the data flow and maintain network efficiency and responsiveness. The client request consists of a common GET, indicating the image URL parameters required to define the WOI. An example would be as follows: GET =image0:j2c?rsiz = 640; 480&roff = 100; 100 &fsiz = 1024; 768 HTTP=1:1 Host: get.jpeg.org

-

-

where the client would request a WOI of a resolution with size less or equal to 1024 768 pixels, with an offset of (100,100) pixels and a region size of 640 480 pixels. The server answers with an HTTP message, for example as follows: -

HTTP/1.1 200 OK JPIP-roff: 0,0

-

Content-type: image/jpp-stream

-

Additional information other than data-bins sent by the server is included by means of line headers. In the previous example, using the JPIP-roff: 0,0 line header, the server notifies the client that the initial offset has been changed to (0,0). JPIP servers can modify any parameter requested by the client, or even modify the compression parameters when the image is sent. For example, the JPIP server implementation provided by Kakadu optimizes the sequence of data transmitted according to the current bandwidth of the communication channel. C. Evaluation of the Progression Order of the Transmissions The PSNR of the image received (Lena, 512 512 pixels and 24 bit/pixel resolution) has been evaluated as a function of the amount of data transmitted (see Fig. 3). This image was compressed using JPEG2000, selecting six resolution levels, 16 quality layers and a 64 64 precinct. After that, the compressed file was transmitted using all the types of progression supported by the JPEG2000 standard. It can be seen that at any given moment during transmission, the LRCPprogressionproducesthebestimagequality.Similarresults have been found for other images, although the larger the image, the better the LRCP progression quality is compared to the others.

631

Fig. 3. Transmission of the image Lena using the five standard progressions of JPEG2000. The PSNR of the reconstructions is plotted versus the amount of received data.

That is the reason why LRCP is the progression order most commonly used for progressive transmission of JPEG2000 images. III. JPIP-W: AN IMPROVED JPIP FOR THE WEB This section describes the JPIP-W protocol. JPIP-W is an extension of JPIP that is able to use Web proxies to improve JPEG2000 image transmission over the Internet. A. Motivation The JPIP protocol is incompatible with Web-aware proxies because • objects in Web proxies are indexed by their URLs. In JPIP a URL specifies a WOI. Therefore, only when two different clients request exactly the same WOI, could a proxy serve the response; • the URLs in JPIP are specified by the format used for dynamic Web objects, caching of which is usually rejected by proxies; • JPIP header lines are incomprehensible to proxies; • The JPIP standard specifies that server responses should include an HTTP “Cache-Control” header line with a “nocache” value [12]. B. JPIP-W Proposal The following features have been proposed to efficiently support proxy caching. • JPIP-W groups the JPEG2000 packets into blocks which are Web objects referenced by URLs. This decreases the overhead produced by the HTTP headers if small packets are transmitted. • A block contains a set of packets selected according to the progression order used for the transmission. • For a given block size , JPIP-W generates blocks of size that include the minimum number of packets whose total size is higher than or equal to . • 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.


632


Unfortunately, using blocks as the minimal requesting unit may generate a certain amount of data overhead. This data overhead comes from the fact that a block is a group of JPEG2000 packets and some packets may contain information from outside of the requested WOI. An example that shows JPIP-W data overhead is described in the Section III-D. However, this data overhead is negligible compared to the improvements provided by the use of the proxy caches. C. JPIP-W Messages Communication begins when the user specifies the requested WOI from the client side. The JPIP-W client sends a request to the server following the format defined in Section II-B, but adding the following line header JPIP-W: yes: GET =image0:j2c?rsiz = 640; 480&roff = 100; 100 &fsiz = 1024; 768 HTTP=1:1 -

-

Host: get.jpeg.org

Connection: keep-alive JPIP-W: yes

-

-

This header is passed to proxy servers to inform them that JPIP-W is going to be used for the transaction. If the server does not support the JPIP-W protocol or it has not been configured for providing this type of service, the server will ignore the header or send back the same header with the response, but with the value no. Notice also that the header line Connection: keep-alive has been included to ensure persistent connections. A connection is persistent if it does not close until the client ask for it. The performance of the JPIP-W protocol is seriously deteriorated if persistent connections are not used because each HTTP message would need an extra RTT to be transmitted. After analyzing a request, the server selects all the blocks the client will need to reconstruct the required WOI. The blocks selected are those which contain at least one packet of the WOI. The server responds to the client with a message that contains all the block indexes, as well as the offsets associated with each block. These offsets are necessary because the packets generated by JPEG2000 are not completely independent, i.e., to decode a certain packet it is sometimes necessary to decode another packet beforehand. Block indexes and offsets are coded in VBAS format [12] and specified as an increment over their predecessor. This procedure takes advantage of VBAS flexibility and efficiency. The server response could be -

Connection: keep-alive JPIP-W-bsiz: 1000 JPIP-W: yes

-

-

-

...

In this example, the server sends Block index coded in VBAS format. Next it sends the list of offsets associated with it, ending in zero, which would be 58. The following block index

-

GET /image0.j2c/bsiz/1000/blk/5 HTTP/1.1 Host: get.jpeg.org

-

Connection: keep-alive

-

HTTP/1.1 200 OK

, and its associated offsets would be 22 and would be 10 . The list of block indexes that the server returns 105 does not include Block 0, since it is assumed that the client has always to ask for it. When the client recovers this block, which contains the image header, it is able to determine the structure of the JPEG2000 image. The server specifies the minimum block size associated to the block list by means of the header JPIP-W-bsiz. When the client receives the list of blocks, it requests the blocks. In a block request, the client builds the URL using the image URL and the block size, with /bsiz, plus the block index, with /blk. The blocks are referenced like file paths within the image file. So for example, a request for Block 5, using a minimum block size of 1000 bytes, could be as follows:

-

This request format enables the server to easily obtain the parameters, and avoid caching rejection by the proxies. The server responds with the result corresponding to each block requested, which includes the appropriate header lines to ensure its cacheability. The minimum set of header lines necessary is composed of Cache-Control, Date and Expires. The first one has to be set to the value public, to ensure that the information content can be cached. The last two header lines inform the client that the data required will not change over a period of time. The header line Expires can also be replaced by Cache-Control, with an appropriate value of max-age. An example of a response to the request shown above is HTTP/1.1 200 OK

-

Cache-Control: public

-

Date: Mon, 2 Jan 2006 11:34:20 GMT Expires: 22 Jan 2006 11:34:20 GMT

-

Connection: keep-alive Content-Length: 1340

-

-

Content-Type: application/octet-stream

-

...

In this example, an expiration time of 20 days has been set. The header lines Content-Length and Content-Type are used to identify the length of the message and the type of information, respectively. Although these lines are not compulsory, their inclusion is advisable to ensure correct proxy behavior. For dynamic images (images that change encoding format or visual content) these header lines must be correctly defined to avoid caching obsolete information. However, this is not a problem in situations where the images do not change for long periods of time [15], [16]. D. An Interaction Example To see the operating differences between JPIP and JPIP-W, Fig. 4 shows the timelines for the interaction between two



633

Fig. 4. Illustrative example of the data interactions and operation of JPIP and JPIP-W.

clients (A and B) and a server. In this example, the client A requests a WOI (“GET WOI ” in the figure) and after that, other client B requests an overlapped WOI (“GET WOI ”). shares data-bins 0, 1 and 2 with . Obviously, no proxies are included for JPIP transmission. For the sake of simplicity, it is assumed that all the datagrams are of the same size. The bandwidth is constant over time and the bandwidth between the proxy and the client is much larger than the bandwidth between the server and the client. The end-to-end network delay is constant with time and distance. Finally, the size of the data-bins, the size of the blocks and the data overhead rate per block (1/4 in this example) are also constant. As expected, JPIP interaction is faster than JPIP-W for the first transmission, because i) the proxy cache is empty, ii) the list of blocks must be transmitted before they can be requested, and iii) in most cases, the blocks include data unnecessary for reconstruction of the WOI (in the example, one more datagram of data per block). Nevertheless, JPIP-W transmits the second WOI faster than JPIP, and the increase in speed will depend on how much the WOIs overlap and the ratio between the proxy-server bandwidth and the proxy-client bandwidth. In the figure, in the instant of time , the JPIP-W client has retrieved the first datagram of Block from the proxy while the JPIP client is still receiving the first datagram in Data-bin 1. From this point of time, the JPIP-W WOI reconstruction quality is better. IV. PERFORMANCE EVALUATION This section describes a series of experiments to evaluate the performance of the JPIP-W protocol. The first study, described in Section IV-A, was done to determine the impact of block size

Fig. 5. JPIP-W performance for different block sizes and different WOI overlappings. Average values of PSNR over all the images are given.

under different transmission conditions. Later, in Section IV-B, the efficiencies of JPIP and JPIP-W are compared. In the sequel, a set of clients communicates with a server using a Squid proxy server [17]. The available bandwidth between clients and proxy was established to 100 Mbyte/s, and the available bandwidth between proxy and server was set to 100 Kbyte/s, simulating a low speed channel. The experiments were performed using two sets of natural -bit RGB images provided by the ISO 12640-2 [18]. The set I contains three images (woman with glass, fishing goods and silver) with a size of 3072 4096. The set II contains five images (flowers, japanese goods, field fire, pier and threads) with a size of 4096 3072. Numerical results in Figs. 5–7 are the average values of the PSNR for the two sets of images.


634


Fig. 6. A comparison between JPIP-W and JPIP in terms of PSNR versus transmission time and using three different degrees of overlapping. Average values of PSNR over all the images are given.

The JPEG2000 compression parameters used in the experiments were as follows. • Lossy compression. • Precinct size of 128 128. • Code-block size of 64 64. • Sixteen quality layers. • Eight resolution levels. starts at coordiHereafter, a WOI defined as , has a size of and has resolution levels, nates where 0 is the highest level. The transmission of the images or WOIs was done using the LRCP progression order that is the most efficient (see Fig. 3). Anyway, JPIP-W is able to use any progression order for the transmissions. A. Determination of the Block Size The block size is a parameter which affects the efficiency of any JPIP-W-based application. For its selection it must be considered that: • Some JPEG2000 packets that belong to a WOI are not located consecutively in the code stream. Therefore, the bigger the JPIP-W block size is, the higher the data overhead will be. • Each block is transmitted with an HTTP header. If the block size is too small, the header overhead will be high. An experiment was performed to measure the influence of the above. The block sizes that have been tested are those that prevent from happening frame fragmentation in most transmission technologies. In Fig. 5, the average values of PSNR of the reconstructed WOI are shown as a function of the block size, for a -s transmission time. In the experiments four curves were plotted. The empty cache line shows a case in which the client retrieves the WOI (0, 0, 700, 700, 0) using an empty proxy. In the other three curves, the WOI (0, 0, 700, 700, 0) is stored in the proxy and the client retrieves another WOI which spatially overlaps with the cached one at three different percentages (0%, 25% and 50%). Results demonstrate that for small sizes of block (50 bytes or less), the header overhead penalizes the performance. On the other hand, the data overhead decreases the PSNR when the size of block is bigger than about 1000 bytes. It can be seen that the

Fig. 7. Comparison between JPIP-W and JPIP in a typical browsing scenario. Average values of PSNR over all the images are given.

highest PSNR values are observed for a block size that ranges from 100 to 1000 bytes. Therefore, a block size of 500 bytes has been chosen for the following experiments. B. Comparison Between JPIP and JPIP-W This subsection compares the performance of JPIP and JPIP-W in two cases. In the first one, an experiment shows the efficiencies of the two protocols when WOIs with different percentages of overlapping are transmitted. The second experiment focuses on a typical user who is interested in a small region of a huge image. The type of stream used for JPIP was JPP. The protocol mode was JPIP-H. It has been utilized the JPIP implementation provided by the Kakadu package. 1) Comparison With Different Overlappings: In order 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%). The results of these experiments are shown in Fig. 6. Although JPIP-W latency is worse than JPIP latency, after an initial period of time (approximately 2 s), the quality obtained by JPIP-W is much better than that provided by JPIP. Notice that, even in the case of 0% of WOI overlapping JPIP-W is better than JPIP. This is due to the fact that two WOIs that are not spatially overlapped may share those JPEG2000 packets that represent the lowest spatial resolution levels. 2) Comparison in Typical Image Browsing: The goal of this experiment, shown in Fig. 7, is 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. In this case, 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 following WOIs, unless the user modifies it. In this test a small user display of 800 600 was used. This involves the Kakadu browser initially requesting a (0, 0, 348, 512, 3) WOI for the images of the set I and a (0, 0, 512, 348, 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 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 the images of the set I and (0, 0, 512, 348, 3), (512, 384, 512, 384, 2) and (1536, 1152, 512, 384, 1) for the images of the set II. In the case of the JPIP-W protocol, two different cases were assumed. 1) The proxy cache starts out empty. In the figure, it is represented by lines with triangles (empty cache). 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. This is shown by lines with squares (non-empty cache). The results in Fig. 7 show that JPIP-W (initially cached) outperforms JPIP, after the initial delay, in all three different situations. Notice the excellent performance of JPIP-W when all the required data is cached (see the graph at the top of the figure). Moreover, when the cache starts out empty, the efficiency of JPIP-W is only a little worse than JPIP. V. CONCLUSIONS This paper presents JPIP-W, that is an extension that improves JPIP protocol for interactive Internet JPEG2000 image browsing. JPIP-W takes advantage of the Web proxy infrastructure to reduce image retrieval transmission time, user latency and network traffic. JPIP-W uses a server-client model similar to JPIP, but when the JPIP-W server receives a WOI request, it sends a message that can be cached by Web proxies. Therefore, a request for an overlapped WOI is partly served by proxies. JPIP-W is not an alternative to JPIP, but a totally compatible add-on. The JPIP-W server can also work as a JPIP server if required.

635

Experimental results show that JPIP-W outperforms JPIP when there is cached data. Although the initial JPIP-W delay is a little longer than for JPIP, the benefits of being able to use Web proxies are clear throughout the transmission. Furthermore, when there is no cached data, JPIP-W efficiency is very nearly as good as JPIP. REFERENCES [1] A. Luotonen, Web Proxy Servers. Upper Saddle River, NJ: PrenticeHall, 1997. [2] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, Hypertext Transfer Protocol—http/1.1 June 1999 [Online]. Available: http://www.ietf.org/rfc/rfc2616.txt [3] D. S. Taubman and R. Prandolini, “Architecture, philosophy, and performance of JPIP: Internet protocol standard for JPEG2000,” in Proc. SPIE, Visual Communications and Image Processing 2003, T. Ebrahimi and T. Sikora, Eds., 2003, vol. 5150, pp. 791–805, SPIE. [4] D. Zeng, F.-Y. Wang, and M. Liu, “Efficient web content delivery using proxy caching techniques,” IEEE Trans. Syst., Man, Cybern. C, vol. 34, no. 3, pp. 270–280, Aug. 2004. [5] J. Z. Wang and P. S. Yu, “Fragmental proxy caching for streaming multimedia objects,” IEEE Trans. Multimedia, vol. 9, no. 1, pp. 147–157, Jan. 2007. [6] S. Deshpande and W. Zeng, “Scalable streaming of JPEG2000 images using hypertext transfer protocol,” in ACM Multimedia, 2001, pp. 372–381. [7] S. T. Liang and T.-S. Chang, “A bandwidth effective streaming of JPEG2000 images using HyperText Transfer Protocol,” in IEEE Int. Conf. on Multimedia and Expo, 2002. [8] D. Taubman and M. Marcellin, JPEG2000. Image Compression Fundamentals, Standards and Practice. Norwell, MA: Kluwer, 2002. [9] G. Wallace, “The JPEG still picture compression standard,” Commun. ACM, vol. 34, no. 4, pp. 30–40, 1991. [10] D. Taubman, “High performance scalable image compression with EBCOT,” IEEE Trans. Image Process., vol. 9, no. 7, pp. 1158–1170, Jul. 2000. [11] Information Technology—JPEG 2000 Image Coding System—Part 1: Core Coding System, ISO/IEC 15444-1:2004, Int. Org. Standardization, Oct. 2004. [12] Information Technology—JPEG 2000 Image Coding System—Interactivity Tools, APIs and Protocols, ISO/IEC 15444-9:2005, Int. Org. Standardization, Nov. 2005. [13] Kakadu, a Comprehensive Framework for JPEG2000 [Online]. Available: http://www.kakadusoftware.com/ [14] 2KAN Research and Development Project [Online]. Available: http:// www.2kan.org/ [15] E. Politou, G. Pavlidis, and C. Chamzas, “JPEG2000 and dissemination of cultural heritage over the internet,” IEEE Trans. Image Processing, vol. 13, no. 3, pp. 293–301, Mar. 2004. [16] Google Maps [Online]. Available: http://maps.google.com/ [17] Squid Web Proxy Cache [Online]. Available: http://www.squid-cache. org/ [18] Graphic Technology—Prepress Digital Data Exchange—Part 2: XYZ/ sRGB Encoded Standard Colour Image Data (XYZ/SCID), ISO/IEC 12640-2:2004, Int. Org. Standardization, July 2004.

Juan Pablo García Ortiz received the M.Sc. degree in computer science from the University of Almería, Spain, in 2003. He is a member of the Supercomputing-Algorithms Research Group of the Computer Architecture and Electronics Department of the University of Almería, where he is currently pursuing the Ph.D. degree in image coding and transmission over heteregeneous networks.


636


Vicente González Ruiz received the M.Sc. degree in computer science from the University of Granada in 1992 and the Ph.D. degree in computer science from the University of Almería in 2000. He became an Assistant Professor of computer architecture in 1992 and an Associate Professor of computer architecture in 2003 at the University of Almería, where he is a member of the Supercomputing-Algorithms Research Group. His research interests are in the area of image and video coding and transmission.

Inmaculada García received the B.Sc. degree in Physics in 1977 from the Complutense University of Madrid, Spain, and the Ph.D. degree in 1986 from the University of Santiago de Compostela, Spain. From 1977 to 1987, she was an Assistant Professor at the University of Almería and, since 1997, is a Full Professor at the University of Almería and the head of the Department of Computer Architecture and Electronics. During 1994–1995, she was a Visiting Researcher at the University of Pennsylvania, Philadelphia. She is head of the supercomputing-algorithms research group. Her research interest lies in the field of parallel algorithms for irregular problems related to image processing, global optimization and matrix computation.

Manuel Francisco Lopez received the M.Sc. degree in computer science from the University of Almería in 2002. He is a member of the Supercomputing-Algorithms Research Group of the Computer Architecture and Electronics Department of the University of Almería, where he is currently pursuing the Ph.D. degree in image and video coding and transmission over computer networks.
