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 timevarying 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, bondpapers 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.
A. Optimal number of quality layers.
B. Optimal precinct size.
C. Impact of the prefetch time in Continue.
D. S&W vs. Continue.
E. 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 srate 4Any 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: