Interactive Streaming of Sequences of High Resolution JPEG2000 Images

ABSTRACT

Interactive Streaming of Sequences of High Resolution JPEG2000 Images. The JPEG2000 image coding system was created with the intention of superseding the original JPEG standard, using a novel wavelet-based method. The main advantage of JPEG2000 is the flexibility of its code-stream, which provides new functionality related to the interactive transmission of images. For this task, JPEG2000 uses the JPIP protocol, which enables real-time spatial random access while the retrieved image is progressively displayed (streaming). The standard also foresees the compression and transmission of sequences of images by repeating this approach for each image. In this framework, this paper presents the Continue data-flow control strategy, a JPIP-compliant solution for the interactive streaming of sequences of images that are transmitted over time-varying communication channels. In this context, the random fluctuation of the capacity of the transmission channel over the time forces the clients to prefetch a minimal amount of the code-stream of each image of the beginning of the transmitted sequence before the playback starts, and the server to decide, in real-time, which amount of the code-stream of each compressed image is going to be transmitted. The estimated channel capacity is performed by clients and the rate-control at the server is straightforward, resulting in a highly scalable image retrieval system. The experiments conducted in this study demonstrate that the proposed method keeps a constant playback frame-rate under severe variations of the channel capacity, even when short prefect times are used.

ARCHITECTURE

JPEG2000 WHICH SHOWS THE COMPRESSION PROCESS OF AN IMAGE

EXISTING SYSTEM

Interactive Streaming of Sequences of High Resolution JPEG2000 Images. One of the weaknesses of all encryption systems is that the form of the output data (the cipher text), if intercepted, alerts the intruder to the fact that the information being transmitted may have some importance and that it is therefore worth attacking and attempting to decrypt it. This aspect of cipher text transmission can be used to propagate disinformation, achieved by encrypting information that is specifically designed to be intercepted and decrypted. In this case, system assume that the intercept will be attacked, decrypted and the information retrieved.

The ‘key’ to this approach is to make sure that the cipher text is relatively strong and that the information extracted is of good quality in terms of providing the attacker with ‘intelligence’ that is perceived to be valuable and compatible with their expectations, i.e. information that reflects the concerns/ interests of the individual and/or organization that Encrypted the data.

This approach provides the interceptor with a ‘honey pot’ designed to maximize their confidence especially when they have had to put a significant amount of Work in to ‘extracting it’. The trick is to make sure that this process is not too hard or too easy. ‘Too hard’ will defeat the object of the exercise as the attacker might give up; ‘too easy’, and the attacker will suspect a set-up.

Limitations of existing system

  • This system allows limited participation to avoid traffic flow and from attack. It provides more security.
  • It is applicable for authentication of e-documents.
  • It is most important for securing certificates, personnel documents, bond-papers that are send via email.

PROPOSED SYSTEM

The experiments conducted in this study demonstrate that the proposed method keeps a constant playback frame-rate under severe variations of the channel capacity, even when short prefetch times are used.To achieve this, Dagher et al. proposed a leaky-bucket rate allocation method that provides constant quality video under buffer constraints by sending approximately the same number of quality layers of each image.Propose a complete stream synchronization protocol to ensure a proper rendering of the multimedia presentation at the receiver.We think that this approach is valid and therefore propose a similar solution.Smooth images to highly textured images, the performance of the proposed rate control algorithm could be inferior.

MODULES

Modules

  1. User Registration
  2. Upload Image
  3. Discrete cosine transform

4.New Algorithm for Interactive Streaming

5. Specific Quantization Noise Distribution

A.Flow control and perfecting.

B.Rate Control.

6. Experimental Results.

  1. Optimal number of quality layers.
  2. Optimal precinct size.
  3. Impact of the prefetch time in Continue.
  4. S&W vs. Continue.
  5. Rate control performance.

Modules Description

Discrete cosine transform

Traces of JPEG compression may be found directly in the spatial domain (image intensity domain). Quantizing the high-frequency DCT (discrete cosine transform) coefficients with a quantization table containing large quantization steps produces ringing effects when a JPEG image is decompressed.

New Algorithm for Interactive Streaming

This section describes Continue, a novel and fully standard-compilant proposal for the interactive streaming of JPEG2000 image sequences, transmitted over time-varying channels. Continue defines a novel flow control scheme on the client-side and a more scalable procedure for the generation of the replies of JPIP servers.

FLOW CONTROL AND PERFECTING

In essence, Continue clients control the transmission bit-rate by sending to a Continue-aware server4 periodically (1 Hz by default) an expected channel capacity, mew (see maximum band-width request field in [9]), for the next period of time (1 second), measured in bits/second. Figure 5 shows an example. A Continue client requests 160 images and initially defines a maximum bandwidth of 10 Mbps (first message from the client to the server). After receiving data at least for a complete second, the client detects that the channel capacity has changed from 10 to 11 Mbps and informs of this to the server (second message from the client to the server). During the next second, the user changes the frame-rate of the visualization from 20 to 18 frames/second, which trigger that in the next interaction the srate4Any standard JPIP server should be able to communicate with a Continue client, although the server would send all the code-stream which refers to each requested WOI. On the contrary, if a S&W client communicates with a pure-Continue server, which is unable to process the Len request field, the server would send, as in the previous situation, all the full code-streams. Obviously, to avoid these problems, JPIP servers should implement both alternatives: S&W and Continue.Parameter is used to communicate this fact to the server (third message). This process continues until the image sequence has been fully retrieved or the user interrupts the transmission

RATE CONTROL

Algorithm 4 shows the rate control scheme used in Continue. The JPIP server runs this code for each request, which should arrive with a cadence of one second. Each request can define a playback frame-rate restate (see the streams-per-second request field in bandwidth estimate ri.mbw,

The length of the sequence in images F (although this parameters needs only to be defined at the beginning of the transmission). With this information, the server extracts bits from each image The packets are stored in the reply that will be sent to the clients. Comparing the S&W and Continue Algorithms shows that both methods effectively perform the same rate control policy. The Continue server does not perform any type of transcending or RD optimization in order to maximize scalability and under similar bandwidth and playback frame-rate constrains, both algorithms will send the same packets.

(1) Continue retrieves the code-stream of each image in a much more efficient way from disk because all the packets of a image are read sequentially

(2) Two or more requests are not nested (the implementation does not need to be reentrant)

EXPERIMENTAL RESULTS

As the ESA JPIP server does not transcode the data stream, the choice of compression parameters of the images significantly influences the quality of the reconstructions. For this reason, a study of these parameters needs to be performed before comparing the performance of the S&W and Continue algorithms. More specifically, the number of quality layers and the precinct size has been analyzed in the context of two realistic transmission scenarios

OPTIMAL NUMBER OF QUALITY LAYERS.

Both sequences have been compressed using 5 levels of the DWT (with the 9/7 filters in the case of Sun and with the 5/3 filters in the case of Stockholm). The precinct size for both sequences is 128 and the code-block size is 64. If not otherwise indicated, these encoding parameters will remain constant for the rest of the experiments.

The results, displayed in Figure 6, show that the number of quality layers has a large impact on the quality of the reconstructions, in particular in Sc.2 where only a small portion of each image can be transmitted. It is evident that this parameter should be higher if the channel capacity is lower (Sc.2) or if the number of served images per second is higher. Another important aspect to take into account is that the computational overhead of the generation of the replies at the server is proportional to the number of quality layers (at least for S&W). For these reasons, we consider 8 quality layers a good compromise for both sequences and scenarios.

OPTIMAL PRECINCT SIZE

In order to reduce the amount of redundantly transmitted data when a WOI has been requested, precincts should be used .A suitable precinct size for the JHelioviewer system has been determined through an experiment that simulates a user who requests a sequence of WOIs that are located in a different place for each image.In this study, the whole Sun sequence has been retrieved using a 1024 1024 WOI which is moved from the upper left corner of each image to the lower right corner, 4 pixels to the right and down, in each iteration. A similar study has been performed for Stockholm. In both cases, Figure 7 shows an optimal precinct size of 128 128 pixels.

IMPACT OF THE PREFETCH TIME IN CONTINUE

The prefetch time (parameter of Algorithm 3) extends the options of adapting the Continue flow control strategy to the variations of bit-rate and latency in the channel. To quantify the influence of, a series of transmissions have been carried out using different prefetch times. Figure 9 shows the results of the transmission of the two image sequences in both scenarios for four different frame-rates and two values.

As expected, the quality (PSNR) of the received images becomes more stable when is increased because the system can better accommodate the channel capacity variations.

RATE CONTROL PERFORMANCE

A comparison between the performance (PSNR vs bit-rate) of the Cacadu 7.5 server (a highly proficient JPIP server) and the Continue ESA JPIP server is presented in Figure 11 to measure the efficiency of the rate control method used in Continue for the test sequences. In the case of the Sun sequence, the figure shows the result of an experiment where a user retrieves resolution level 2 of the images ((2; (0; 0); (1024; 1024)) WOI), and when the quality has reached some threshold (55 dB in the example).

SYSTEM REQUIREMENT SPECIFICATION

HARDWARE REQUIREMENTS

  • System: Pentium IV 2.4 GHz.
  • Hard Disk: 80 GB.
  • Monitor: 15 VGA Color.
  • Mouse: Logitech.
  • Ram: 512 MB.

SOFTWARE REQUIREMENTS

  • Operating system : Windows 7 Ultimate
  • Front End:Visual Studio 2010
  • Coding Language: C#.NET
  • Database:SQL Server 2008

Output: