Dear All,
in this post we are going to briefly introduce the JPIP (JPEG 2000 Interactive Protocol) protocol, sharing part of the knowledge we have gained over the last years while working with this technology.
The basicsThe JPIP protocol is defined in an ISO standard, specifically ISO/IEC 15444 part 9 drafted by the JPEG ISO committee. Such standard defines an interactive protocol that takes full advantage of JPEG 2000’s scalability properties by means of additional signaling JPIP in order to interactively deliver pieces of a JPEG 2000 image in essentially arbitrary order, in response to real-time application requests using potential very low bandwidth even for very large raster data. These requests are called View-Window requests and typically correspond to user actions like zooming and panning. JPIP also takes advantage of JPEG 2000’s resolution hierarchy to minimize the redundant retransmission of data and to circumvent the need for storing multiple versions of an image at different resolutions. It is correct to say that the JPIP protocol enables scalability with respect to five different defined image progression orders. The idea is similar to progressive JPEG, but the packetized structure of a JPEG 2000 codestream makes it possible to convert between different progression orders by the systematic reordering of packets, without any low-level decoding. The protocol also allows for the negotiation of client and server capabilities and limitations. The client may request information about an image as defined in JPIP index tables from the server, which enables the client to refine its View-Window request to image specific parameters (e.g., byte range requests). The server's cache model is based on the capabilities defined by the client and the statefulness of the HTTP session.
Through the JPIP protocol, a client does not directly access the compressed file. Rather, it formulates requests using a simple descriptive syntax which identifies the current “focus window” of the client-side application. The JPIP protocol is a more efficient service for interactive imaging, with fewer round-trip delays, and the opportunity for servers to efficiently manage their resources. JPIP requests identify the client’s spatial region of interest, resolution and image components of interest, allowing the server to determine the most appropriate response elements and to optimally sequence them. As we shall see, JPIP allows the server to adjust the sequence in which data is returned so as to minimize disk thrashing while optimizing the image quality available at the client. A single JPIP request is sufficient to obtain an arbitrary region of an image, at a selected size/resolution, so that JPIP requests can be embedded as static targets within HTML pages. For interactive applications, multiple JPIP requests can be issued and efficiently served within an interactive browsing session, allowing the server to avoid the delivery of redundant data. The JPIP protocol has features which commend its use for collaborative remote image interaction, for providing services on unreliable transports (e.g., wireless transmission), for flexible and domain-specific delivery of meta data, and for applications which involve low data-rate networks.
Window-View request explained
JPIP requests consist of a sequence of “key=value” pairs. When carried by a text-oriented transport protocol such as HTTP, the name and value components of each request field are ASCII strings and request fields are separated by the “&” character. This convention allows the entire JPIP request to be embedded in the query component (after the ‘?’ character) of a conventional HTTP GET request (notice that alternate representations may be preferred for other transports).
A basic JPIP request should contain some means for identifying the target file, together with the focus window in it. As an example, the following request is for a target file known to the server as “images/huge.jp2”, at a resolution whose full image size is 12000x8000 (width by height), within a region of size 600x400, at an offset of 5000 pixels from the left and 6000 pixels from the top of the requested image resolution.
target=images/huge.jp2&fsiz=12000,8000&rsiz=600,400&roff=5000,6000
This request might be embedded in a URL such as:
http://www.unsw.edu.au/bin/jpip.cgi?target=images/huge.jp2&fsiz=12000,8000&rsiz=600,4
00&roff=5000,6000It is worth to point out that the Discrete Wavelet Transform used in JPEG2000 provides D+1 decending image resolutions, whose dimensions WdxHd are smaller than those of the original image by 2d, where 0 ≤ d ≤ D and D is the number of DWT levels. If the dimensions supplied by the fsiz (full size) query field are not identical to those of one of these image resolutions, the JPIP server is expected to round to the nearest available resolution, WdxHd. The rounding direction may optionally be made explicit using a request field of the form:
“fsiz=12000,8000,round-up” or “fsiz=12000,8000,round-down” or “fsiz=12000,8000,closest”
Wherever this happens, the region size and offset parameters supplied by the rsiz and roff query fields must be scaled so as to preserve their relationship to the fsiz parameters.
Bandwidth Control, Sessions and Caching
It is worth to notice that the JPIP protocol provides a keyword to control the maximum response length and the delivery rate that a server can send to a client by means of the len keyword. This field specifies a restriction on the amount of data the client wants the server to send in response to this request. The unit shall be bytes. If not present, the server should send image data to the client until such point as all of the relevant data has been sent, a quality limit is reached or the response is interrupted by the arrival of a new request. The client should use len=0 if it requires response headers and no response data.
A client can provide fine grain control over the bandwidth employed by using this field in order to limit the amount of data requested on each request.
A JPIP client typically caches the contents transferred by the server in responses. JPIP identifies each request as either stateless or stateful. Stateful requests are made in the context of a communication session, whose state is maintained by the server. Although sessions require the server to allocate some persistent resources, sessions can significantly reduce its computational and I/O load. A stateless server may need to open the image, interpreting, extracting and reordering its contents each time a request arrives. On the other hand, a stateful server can generally minimize its interaction with the original image file, relying on information accumulated while processing previous requests. Moreover a stateful server may keep track of the number of bytes from each data-bin which it has already sent to the client. In this way, only the missing information need be sent in response to future requests. This is usually called cache modeling. For stateless requests, the client should instead explicitly identify the amount of data from each relevant data-bins which it already has in its cache, in each separate request. This tends to make stateless requests much larger. On the other hand, if a client cannot cache all information it has received from the server, stateful requests must explicitly identify the elements which have previously been received, but have since discarded from the cache.
Clients may re-use their cache contents both within a session and between sessions. In fact, a stateless request is essentially just a session which terminates after the request has been serviced; it is obvious that clients must be able to re-use their cache contents between stateless requests. Moreover, clients may share their cache contents with others. For these reasons, JPIP servers must agree to maintain the integrity of each data-bin’s contents across multiple requests, sessions and clients. To facilitate this, JPIP allows servers to assign a unique target-id to each target file or jpeg2000 codestream. If the contents of any data-bin associated with the target change (e.g., due to image editing), a new target-id must be issued to alert clients to the fact that their previous cache contents should no longer be considered valid.
If you have questions or if you just want to talk to us about our experience with JPIP as well as about how we can help your organization reach your goals, please, subscribe to the mailing list
here. In any case, do not hesitate to
contact us.
Regards,
Primero, agradecerles por ser responsables de una buena cantidad de mis éxitos. Por hacer caso a ideas veces descabelladas, veces ilusas, otras tan comunes como el obvio sentido común. También agradecerles por no hacerme caso cuando han considerado que mis iniciativas podrían ser refutadas, 
EL MAPA, IMAGEN EN INTERNET
Ha regresado la feria científica de mi hijo, y luego de varias deliberaciones con la maestra sobre posibilidades de proyectos, finalmente le han aprobado uno con el que saltaba casi un metro de alegría… yo casi los dos porque es un tema que nos apasiona a ambos. También porque este proyecto es original, decidimos no buscar más en Internet lo que ya todos han hecho y la principal razón por la que la mitad suelen ser rechazados o repetidos.
Y finalmente explicará como este sistema, junto con el receptor gps que traen ahora los móviles y aplicaciones desarrolladas permiten la geolocalización, mostrando Google Earth y la ubicación donde se encuentran en el colegio. Oh, eso quiero verlo porque el juguete se lo maneja como si fuera un Game Boy.
