JP2003179760A - Image processor and data cache method therefor - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an image processor in which image data fragmented in a prescribed form are decoded and cached on the basis of that prescribed form and to provide a data cache method therefor. <P>SOLUTION: Before receiving encoded data, header data on an image are received from an external device (S602) and on the basis of these received header data, the quantity of tiles comprising the image and the quantity of encoded data required for comprising each of the tiles are calculated. Then, prescribed dummy encoded data in a quantity of the encoded data are set to each of the calculated tiles (S603) and among the set dummy encoded data, dummy encoded data corresponding to the encoded data actually received from the external device are replaced with the encoded data received from that external device (S606). <P>COPYRIGHT: (C)2003,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an image processing apparatus for transmitting and receiving encoded image data for processing, and a data cache method thereof.

[0002]

2. Description of the Related Art A user of an image processing apparatus such as a personal computer (hereinafter, simply referred to as a computer) capable of connecting to the Internet uses a function of a web browser of the apparatus to use a WWW (Wo) on the Internet.
rld Wide Web) Various document data and image data are browsed by accessing the server.

To browse information using such a web browser, a WWW server (hereinafter sometimes simply referred to as a server) that publishes various information on the Internet, a computer (user terminal) that browses the information, etc. The client can browse the information on the server by operating the web browser on the client side.

In this WWW server, various kinds of information that the information provider desires to be disclosed on the Internet are so-called.
It is stored as information described in HTML format called a home page, and the information is displayed on the client side computer by the function of the web browser on the client side. Further, the user on the client side can obtain the information desired by the user by following the link in the home page displayed on the display by operating the web browser.

As a method of downloading various data files managed by the server to the computer on the client side, there is a method of using a communication protocol called File Transfer Protocol (hereinafter abbreviated as FTP). This FTP defines a procedure for transferring a file on a server to a computer on a client side via a communication network.

On the other hand, in the information browsing system constructed on the Internet by the above-mentioned WWW server and web browser, Hyper Text Transfer Prot.
Communication between the server / client is performed using a communication protocol called ocol (hereinafter abbreviated as HTTP),
This HTTP operates as follows.

For example, when the user uses a web browser on the user terminal on the client side and the user clicks on a portion of the homepage where the link information is provided, the web browser decodes the link information of the clicked portion. And a new URL according to the decryption result
Open (Uniform Resource Locator). Here, opening means issuing a document information transmission request to the target server.

Upon receiving this transmission request, the server returns the entire document corresponding to the request to the client. At this time, the document sent from the server consists of header information and document information body,
It is the data of the entire document specified by the URL in the web browser, and is the document data that is transferred from the server to the computer on the client side at once.

The web browser on the client side that receives the document data first analyzes the header information included in the document data received from the server. Specifically, according to the MIME-TYPE included in the header information, the application that can open the document information following the header information is specified. After that, the web browser activates the specified application preinstalled in the user terminal, and passes the document information body following this header information to the activated application. As a result, the document data (document) received from the web browser is displayed on the display of the user terminal and can be browsed by the user.

As described above, in HTTP, basically, when an open request for a certain URL is transmitted from the client side to the server side, the server side sends the entire document data specified by the URL to the client side. Is done.

On the other hand, in the above-mentioned FTP, the document desired by the user is designated by using the URL as in the case of the above-mentioned HTTP. The document designated here is managed in the server. It is a file that has been created. Therefore, this server transfers the entire designated file to the computer on the client side and stores it as a file on the client side.

[0012]

DISCLOSURE OF THE INVENTION Problems to be Solved by the Invention
In a communication protocol such as TP, among the documents managed as files by the server, all the data forming the document to be downloaded is transmitted to the user terminal (computer) in response to a transmission request from the user terminal. It will be. Therefore, there is a problem that partial data access in a document such as access to only a certain image data file contained in the document cannot be performed from the user terminal.

For such a situation, as a protocol for displaying a desired image on the user terminal, for example, Fl
There is ashpix / IIP. This IIP (Internet Imaging Pro
tocol) is a protocol suitable for the file format of image data called Flashpix and realizes partial access to the image data file. However,
In this Flashpix / IIP, the unit that can partially access the image data is the tile unit defined in Flashpix. The tiles of this Flashpix are only the image data (including the case where they are compressed) that make up one tile, and the image data of that tile can be decoded and played back. Therefore, the application for decoding and displaying the image data activated on the user terminal on the client side does not need to temporarily store (cache) the received tile image data in its own device but in units of that tile. Images can be decoded and displayed.

In recent years, JPEG (Joint Photographic Experts Group) 2000 conforming to ISO / IEC-15444
Although the image coding technology of the system has been proposed, the above Flashpix / I can be used in a client / server environment configured on a general communication network including the Internet.
If the IP is directly applied to the image data encoded based on the JPEG2000 system (hereinafter, encoded data), JPEG
The coded data of each scalability in the 2000 system is difference data based on the scalability data which is one level lower than the scalability.

Therefore, as described above, in Flashpix, 1
While the image data of the tile can be decoded only with the image data that makes up one tile, when decoding based on the JPEG2000 method, the client computer (user terminal) can Coded data below the scalability of the image to be displayed is also required.

Further, when the computer on the client side caches the encoded data based on the JPEG2000 system, the computer receives partial encoded data from the server side. The encoded data can be organized as a data file of one encoded data. However, in this case, the editing process on the client side becomes complicated,
There is a problem in that it is not easy to reduce the cost of software that realizes the necessary functions.

It is also possible to configure the partial encoded data received from the server as a cache file of a unique format in the computer on the client side. However, in such a case, there is a problem in that the JPEG2000 method decoder operating in the client complicates the process of reading the cache file of this unique format.

The present invention has been made in view of the above-mentioned conventional example, and provides an image processing apparatus and a data cache method for decoding and caching image data fragmented in a predetermined format based on the predetermined format. The purpose is to do.

[0019]

In order to achieve the above object, the image processing apparatus of the present invention has the following configuration.
That is, an image processing device that receives and caches fragmented coded data of a user-desired image in a predetermined format from an external device that is communicably connected via a communication network. Prior to receiving, receiving means for receiving header data relating to the image from the external device, and based on the header data received by the receiving means, the number of tiles forming the image and individual tiles are formed. Calculation means for calculating the quantity of the coded data necessary for this purpose, and a dummy for setting a predetermined dummy coded data for each of the tiles calculated by the calculation means by the quantity of the coded data. Of the dummy coded data set by the data generating means and the dummy data generating means, the external device Indeed dummy coded data corresponding to the encoded data received, and having a data replacement means for replacing at the encoded data received from said external device from.

In order to achieve the above object, the data cache method in the image processing apparatus of the present invention comprises the following steps. That is, a data cache method in an image processing apparatus for receiving and caching fragmented coded data in a predetermined format for an image desired by a user from an external apparatus connected to be able to communicate with each other via a communication network, Prior to receiving the encoded data,
A receiving step of receiving header data related to the image from the external device, the number of tiles forming the image based on the received header data, and the encoded data necessary to form each tile. A calculation step of calculating the quantity, a dummy data generation step of setting predetermined dummy coded data for each of the tiles calculated in the calculation step by the quantity of the coded data, and the dummy data generation A data replacement step of replacing dummy coded data corresponding to the coded data actually received from the external device among the dummy coded data set in the step with the coded data received from the external device; , Are included.

[0021]

Preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

<First Embodiment> FIG. 1 is a block diagram showing the schematic arrangement of a computer device as an image processing apparatus according to the first embodiment of the present invention.

In FIG. 1, a CPU 101 executes a program stored in a primary storage 102 to control the operation of the entire computer device. In this embodiment, a primary storage unit (hereinafter abbreviated as primary storage)
A memory 102 is mainly assumed as an example of a storage medium, and a secondary storage unit (hereinafter abbreviated as secondary storage) 1
The programs and the like stored in 03 are read and stored. A storage medium such as a hard disk can be used as the secondary storage 103.

Generally, the data capacity that can be stored in the primary storage 102 is smaller than the data capacity that can be stored in the secondary storage 103, and programs and data that cannot be stored in the primary storage 102 are stored in the secondary storage 103. It In addition, the data that must be stored for a long time is stored in the secondary storage 1
It is stored in 03. In the present embodiment, the software program in which the operation control processing of the computer device is described is stored in the secondary storage 103, and the software program is stored in the primary storage 102 before being executed by the CPU 101. Is read.

The input device 104 is, for example, an auxiliary input device such as a mouse or an input device such as a keyboard, and is used to set a user's operation in the computer.
The output device 105 is, for example, a monitor or a printer. Reference numeral 106 denotes a communication interface capable of bidirectional communication with an external device.

Each of these parts shown in FIG.
Are connected to each other so that data can be transferred.
The operation control of the entire computer equipment by U101 is realized.

Various other configurations are conceivable for the configuration of the computer equipment as the image processing apparatus according to the present embodiment, but at present, general computer equipment and its peripheral devices can be used. Detailed description in this embodiment is omitted.

FIG. 2 is a diagram showing an outline of the communication network in the embodiment of the present invention, and shows a so-called server / client environment.

In the figure, 201 and 202 are user terminals as clients, and each user terminal is a computer device (computer system) as an image processing apparatus described above with reference to FIG. The user terminals 201 and 202 and the server 204 can perform data communication with each other via a general communication network (hereinafter, simply referred to as a network) 203 including the Internet.

The server computer (hereinafter, simply referred to as a server) 204 includes a large-capacity storage device 205 such as a hard disk for accumulating image files. In the present embodiment, the storage device 205 stores a large amount of image data previously encoded according to the JPEG2000 encoding method.

In the following description, a method of caching a data file of coded image data (coded data) coded according to the JPEG2000 coding method in the user terminal 201 (202) will be described in detail according to a concrete example. . In the present embodiment, specifically, the user terminal 201 (or 20)
The user of 2) operates the web browser operating on the user terminal and, through the network 203,
While accessing the desired homepage and clicking (selecting) the link to the image data of JPEG2000 format included in the homepage, the image data is acquired in the size and resolution desired by the user, and the user terminal concerned The case of displaying on the display will be described as an example.

Here, in order to facilitate understanding of the cache method according to the present embodiment, general JPEG2000 encoded data will be outlined.

FIG. 3 is a diagram showing the structure of JPEG2000 encoded data, which is a Layer-resolution level-component.
-A structure of a JPEG2000 file (encoded data file of JPEG2000 system) recorded according to a position progression (hereinafter, referred to as LRCP) is shown.

When this LRCP is applied, generally JPEG
2000 files are layer / re
solution / component / position (posit
Ion) are recorded in the order of the data blocks. The arrangement (array) of such data blocks is progress
called order. The concept of position above is JPEG
In the 2000 encoding method, it is considered in the technology called "precinct", and in the frequency components of each resolution obtained after performing the wavelet transform, even if the frequency components are different, the layer / resolution / component is the same type /
At the same level, a data group indicating the position of the same small area divided in the original image is arranged so as to be continuously arranged.

FIG. 4 is a diagram for explaining the resolution scalability of JPEG2000. The resolution (image size) and the resolution are shown in FIG.
It shows the relationship with the solution number.

As shown in the figure, the resolution number of the image with the smallest resolution is "0" and the resolution number is 1.
As the image size increases, the image size doubles in width and height.

Further, in the structure of the encoded data shown in FIG. 3, data is stored in each layer corresponding to the layer number in ascending order of the resolution number. The layer number corresponds to the S / N ratio of the image to be restored with respect to the original image (original image), and the smaller the layer number, the worse the S / N ratio with respect to the original image.

In one JPEG2000 file, resolu
The maximum value of the tion number, the layer number, and the component number are preset by an encoder conforming to the JPEG2000 system, and those parameters are stored in the encoded data. Each packet is composed of a packet header section that manages information of code blocks stored in the packet and encoded data of each code block.

[Creation of Cache File] Coded data of the JPEG2000 system as shown in FIGS. 3 and 4 is stored as a file in the user terminal 201 (202) according to the cache procedure described below in this embodiment. For example, even if all the encoded data corresponding to the desired image existing in the server 204 is not acquired by the user terminal, only the encoded data of the portion (resolution) required by the user is received from the server and the efficiency is improved. It becomes possible to browse the image.

As a unit of the received data at the user terminal, a JPEG2000 packet (packet) or a code block unit which is an encoding unit smaller than the packet can be considered, but in the present embodiment, the user terminal is the server 204. Packet units are assumed as the data units received from.

FIG. 5 is a diagram for explaining the communication protocol between the server and the client according to the embodiment of the present invention, and shows the concept of request and response in packet units.

In the figure, user terminals 201 and 202
Responds to the image tile (Ti
le) number, resolution level, layer, component, and position number are specified to request the corresponding image data from the server 204. When the server 204 receives this request, the storage device 205
After analyzing the code stream of the image data 503 (similar to the data structure shown in FIG. 3) stored in
Tile number specified by the user terminal, resolution lev
The packet data corresponding to el, the layer, the component, and the position number is extracted, and the extracted packet data is transmitted to the user terminal. The operation of the user terminal that realizes this series of operations will be described below.

In the example of FIG. 3, tile 1 from the user terminal,
Data of resolution 0, layer 0, component 0, position 0 is requested, and the data of packet 0 of tile 1 including this is returned from the server 204 to the user terminal.

FIG. 6 is a flow chart showing the cache processing of received data in the user terminal (201 or 202) according to the first to sixth embodiments of the present invention.
1 shows the procedure described in the software program executed by No. 1.

In the figure, first, in step S601, the user terminal sends the required image name and the main header of the image data to the server 204 storing a plurality of images via the network 203. Request. Next, the process proceeds to step S602 and step S601.
Request, the main header of the packet data transmitted from the server 204 is checked, and if it is received, the process proceeds to step S603, and this user terminal is shown in FIG. 7 based on the received main header. A file (hereinafter referred to as a main file) 701 for managing the information of the entire image and the cache file is created, and the main header acquired in step S602 is written in the area 703 of the main file 701.

That is, when the user terminal receives the main header, in step S603, the main file 701 for managing the information of the entire image having the data format as shown in FIG. In order to create a file with the file name in which the name of the original image is inserted at the beginning in (Temp folder of C drive, for example), the input operation of the file name is prompted. For example, when the user requests the “image.jp2” file, the user terminal creates a main file 701 named “image.iip2k” in the folder of the secondary storage 103 (note that the process in step S603 is performed). Details will be described later with reference to FIG. 9).

Next, in step S 604, the server 204 is requested via the network 203 for the image area, resolution, layer, and component required according to the user's selection operation on the user terminal. The user's selection operation in step S604 has no relation to the essence of the cache method, which is the main purpose of the present application, and therefore its description is omitted.

As a result, the server 204 transmits the image portion designated by the user terminal to the user terminal in JPEG2000 packet units.

Then, in step S605, when the packet data is received, the process proceeds to step S606, the received packet data is organized as a file, and the main file 70 created in step S603.
The description part of the information related to the packet data of 1 is rewritten (the details of the processing in step S606 will be described later with reference to FIG. 12).

Next, in step S607, it is determined whether or not an operation for requesting further image data is performed by the user, and if the requested operation is detected, step S604.
If the requested operation is not detected, the process returns.

FIG. 9 is a flowchart showing the main file creating process (step S603) in the first embodiment of the present invention.

In the figure, in step S901, by analyzing the main header received from the server 204, the height and width of the original image, the height and width of the tile at the maximum resolution, the number of resolution levels, the layer Number, number of components, number of positions, progress
Get ion order. Next, in step S902,
The number of tiles is calculated based on the height and width of the original image and the height and width of the tile at the maximum resolution. Next in step S9
03, the resolution l acquired in step S901
The number of packets included in each tile is calculated based on the number of evels, the number of layers, the number of components, and the number of positions.
Next, proceeding to step S904, the file containing a 1-byte value “0” indicating “zero length packet” in the encoded data of the JPEG2000 system (hereinafter referred to as a zero length packet file) S9
The same number as the number of packets included in each tile obtained in 03 is created. For example, for the packet whose tile number is "0" and packet number is "2" in the above-mentioned "image.jp2" file, "image_tile" containing a 1-byte value "0" is entered.
A file named "00000_pkt0002.iip2k" is created in the Temp folder (C: / Temp /) of the same C drive as the main file "image.iip2k". That is, in this step 904, for each packet, a main file 701 having a value (dummy encoded data) indicating a zero-length packet specified by the bitstream syntax of the JPEG2000 system is created. become.

Next, the process proceeds to step S905 and step S905.
The number of tiles obtained by analyzing the main header in 901,
The basic information of the original image such as the number of resolution levels, the number of layers, and the number of components, as well as the data length of the main header,
The area 70 of the main file 701 is used as image management information.
Write to 6. Area 7 of this main file 701
In 03, the received data of the main header is written.

Next, in step S906, basic information for each tile is created in the area 702 of the main file 701 as shown enlarged on the right side of FIG. 7 (note that the details of the processing in step S906 will be described below). , Which will be described later with reference to FIG. 10). Next, in step S907, the basic information of each tile created in step S906 is written in the area 702 of the main file 701, and the main file creation process ends.

FIG. 10 is a flowchart showing the tile basic information creation processing (step S906) according to the first embodiment. The flowchart shown in FIG. 10 is a flowchart showing a process performed only when the main file 701 is created, and this process is executed only in the initial state. In step S906, the operation of the flowchart shown in FIG. 10 is repeated by the number of tiles in the order of tile numbers, so that the area 702 of the main file 701 shown in FIG. 7 is created. Also this area 7
The detailed configuration of 02 is as shown in FIG.

In FIG. 10, first, step S1001.
Then, the number of packets included in each tile, which has already been calculated in step S903 of FIG. 9, is acquired. At this point, the user terminal has not yet received the packet data from the server 204, and the processing of step S904 described above is executed, so that all the packets in the main file 701 are zero-length packets. Therefore, in step S1002, the data length of each tile is
It is calculated by (length of tile header) + (number of packets included in tile) × 1 byte.

For example, if the marker included in the tile header is
If only one SOT marker is included in one tile and 36 packets are included, the data length of this tile is 14 + 1 × 36 =
It becomes 50 [bytes].

Next, in step S1003, a SOT marker to be included in the tile header in the JPEG2000 system is created from the tile number and tile data length. The tile number is "0" and the number of included packets is "3".
FIG. 11 shows the configuration of the SOT marker created for the “6” tile and its data size.

Next, proceeding to step S1004, in the main file 701, the tile data length 804, tile number 805, and the number of packets 806 included in that tile,
The number of resolutions, the number of layers, the number of components, etc. included in the tile are written in the tile data management data 704.
Next, in step S1005, the main file 701.
The tile header is written in the area 705. Next, the process proceeds to step S1006, the packet number is set to "0", and thereafter, the processes from step S1007 onward are repeatedly executed in the order of packet numbers.

First, in step S1007, pr of the original image
Re corresponding to the packet number according to the ogression order
solution level, layers, components, and posi
Specify the tion number. Next, in step S1008,
The data length 1 of the packet of interest, a pointer to the zero-length packet file corresponding to this packet data, resolution level, layer, component, posi
Information necessary for managing the packet of interest, such as an option number, is written in the area 802 of the area 702 of the main file 701. At this time, as the pointer to the zero-length packet file, for example, the file name “image_tile0000_pkt0002.iip2k” or the like is set to a value that specifies the file containing the data of the packet of interest in the area 8
Write in 03. Next, the process proceeds to step S1009, the packet number of the packet to be noted is incremented by 1, and step S1009 is performed.
In 1010, it is determined whether or not the series of processes from step S1007 has been performed on all the packets included in the tile, and if it is determined that all the packets have been completed, this operation ends. For example, if the number of packets is "36" and the packet number after step S1009 is "36", this flowchart ends. That is, in the initial state, the server 204
Data files having the same number of zero-length packet data as the number of packets included in the image file are cached in the user terminal.

When the data portion of the cache file created by the processing up to this point is sequentially sent to the JPEG2000 decoder of the user terminal, the image size, which is the basic information of the image data, remains unchanged. It can be decoded with the value of. So in the decoder,
All the packets are judged to be in the “absent” state and can be decoded.

FIG. 12 shows the first embodiment of the present invention.
The main file 701 in step S606 of FIG.
7 is a flowchart showing the overwriting process of FIG.

In the figure, in step S1201,
The tile number including the received packet data and the packet number are acquired. For example, when the response data in the binary format as shown in FIG. 13 is sent from the server 204 to the user terminal, TIdx (1301), PIdx
(1302) represents the tile number including the received packet data and the packet number thereof, and these values are used in step S1201. The response data is not limited to the binary format, and may be a text format such as XML. In step S1202,
The file in which the received packet data is written is created in the same folder as the folder in which the main file 701 is created. For example, for the packet with the tile number “0” and the packet number “2” of the “image.jp2” file, the zero-length packet with the name “image_tile00000_pkt0002.iip2k” in step S904 of FIG. 9 described above. Since the file is created in the Temp folder of the C drive, the file is rewritten with the newly received packet data.

Next, in each step after step S1203, the information regarding this packet (packet of interest) of the main file 701 is rewritten. In step S1203, when the main file 701 is created,
The area 807 in which “1” was written as the data length of the packet of interest is rewritten to the data length of the packet data actually received from the server 204. Next step S1
Proceeding to 204, pointer information 803 pointing to the zero-length packet file corresponding to the packet of interest
Is rewritten with pointer information to the file created in step S1202 as a file containing the packet data of interest. For example, a file name is written as pointer information to a file, and in step S904 of FIG. 9, a “image_tile00000_pkt0002” is assigned to a packet having a tile number “0” and a packet number “2” in the “image.jp2” file. If a zero-length packet file named ".iip2k" is created and the received packet data is overwritten in that file in step S1202 of FIG. 12, there is no need to rewrite.

Next, proceeding to step S1205, the data length of the tile containing the packet of interest is newly recalculated, and the main file 7 shown in area 801 of FIG.
The area 804 in which the data length of the tile of 01 is described is rewritten. For example, assuming that only one packet data is updated at a time, if the number of bytes of the packet data newly received this time is 512 bytes, the tile data length of the area 804 in FIG. 8 is the length of the zero length packet. Subtract "1" to newly receive the number of bytes "51
Since it is sufficient to add "2", the value is "511" (= 512
-1) is updated. Next, in step S1206,
A portion in which the tile data length of the SOT marker 705 of the tile including the packet data is described, that is, P in FIG.
The sot (1101) is updated with the value overwritten in the area 804.

Therefore, for example, when the number of tiles is “4” and the number of packets in each tile is “36”, in the present embodiment, the files shown in FIG. 14 are created in the Temp folder of the C drive of the user terminal. To be done. Step S6 of FIG.
03, main file 701 and zero length
Since the user created the packet file, the number of files in the cache shown in FIG. 14 (1 + 36 × 4 =) 1
The file name of 45 is not changed.

If the cache method according to the first embodiment described above is executed by the user terminal 201 (or 202),
Even if all the image data (differential encoded data) prepared in the server 204 is not received, the packet data of the unreceived portion is converted into zero length packet data in the process of step S904 of FIG. 9 in the main file 701. Since it is embedded, it can be stored as a stream conforming to the JPEG2000 predetermined format. Therefore, when a part of the data is received, the user terminal does not rewrite the main header received from the server 204, but rewrites the main header portion and the tile header portion included in the created main file 701 into the respective packets. By connecting one file as a data file, a file that can be decoded by a general JPEG2000 decoder can be easily organized in the user terminal.

<Second Preferred Embodiment> In the first preferred embodiment described above, a zero-length packet file created for a packet that the user terminal 201 (or 202) has not yet received is created for each packet. Was there. But,
The data of this zero-length packet file all have the same value. Therefore, one zero-length packet file may be created for one image, and all packets that have not received packet data may reference the file. In this case, the first embodiment described above is different from the first embodiment in the main file creation process of step S603 of the flowchart showing the client side (user terminal) cache creation process shown in FIG. Is different from the process of rewriting. In the second embodiment, such a configuration will be described.

FIG. 15 is a flow chart showing the process of creating the main file 701 according to the second embodiment of the present invention. The processes of steps S901 to S903, and steps S905 and S907 are shown in FIG.
Since the processing configuration is the same as that of the same step number in Embodiment 1 described above with reference to FIG.

In step S1504, a file containing a 1-byte value "0" indicating a zero-length packet in the encoded data of the JPEG2000 system, that is, only one zero-length packet file is created. For example, for the "image.jp2" file, "ima.
A file named "ge_zero.iip2k" is created in the Temp folder of the same C drive as the main file "image.iip2k". That is, one file of zero-length packet is created for one image.

Then, in step S1506, the basic information of each tile as shown by the area 702 in FIG. 7 is created. However, since it is a little different from the structure of the basic information of the tile created in the first embodiment, the figure This will be described with reference to 16.

FIG. 16 is a flowchart showing the tile basic information creation processing (step S1506) according to the second embodiment, and steps S1001 to S1.
007, and steps S1009 and S10
The process of 10 is the same as that of the first embodiment described with reference to FIG.
Since the processing configuration is the same as that of the same step number in step 1, description thereof will be omitted.

The flowchart shown in FIG. 16 is a flowchart showing the processing executed only when the main file 701 is created, as in the case of the first embodiment, and is a flowchart executed only in the initial state.

In step S1506 of FIG. 15, FIG.
The operation of the flowchart shown in FIG. 7 is repeated for the number of tiles in the order of the tile numbers, so that the area 702 of the main file 701 shown in FIG. 7 is created. Also,
The area 702 has a detailed structure inside as shown in FIG.

In step S1608, information necessary for managing the packet of interest, such as the data length 1 of the packet of interest, the pointer to the zero-length packet file, the resolution level, the layer, the component, and the position number. Is written in the area 802 of the main file 701. At this time, as a pointer to the zero length packet file, for example, "image_zero.iip
A value such as a file name such as “2k” that specifies the file containing the data of the packet is written in the area 803.

In the second embodiment, as described above, since only one zero length packet file is created, in the initial state, all the packet data files written in the main file 701 are written. The pointer, that is, the destination pointed to by the area 803 in FIG. 8 is “image_zer
o.iip2k ”.

Next, the overwriting process (step S606 in FIG. 6) of the main file 701 in the second embodiment will be described with reference to FIG.

FIG. 17 is a flowchart showing the main file overwrite processing according to the second embodiment of the present invention. The processing of steps S1201 to S1203, and steps S1205 and S1206 will be described with reference to FIG. Since the processing configuration is the same as that of the same step number in Embodiment 1, the description of the step is omitted.

In step S1704, the information of the pointer 803 pointing to the zero-length packet file as the file containing the data of the packet of interest is rewritten to the pointer information to the file created in step S1202. For example, the file name “image_zero.iip2k” written in the pointer 803 is
It is rewritten to the newly created file name "image_tile00000_pkt0002.iip2k".

FIG. 18 shows the structure of the cache file created by the user terminal according to the second embodiment. By adopting such a cache file configuration,
In the initial state, the main file 1801 and zero length
Only two files, packet file 1802, are created. In the initial state, the pointer 803 that points to the packet data file of the main file 701 has pointer information to the zero-length packet file 1802 written in all packets, and thereafter, every time packet data is received from the server 204. The number of files increases. As a result, the first embodiment described above
It is possible to reduce the number of files to be created as compared with the procedure of.

<Third Embodiment> In the first and second embodiments described above, a 1-byte zero-length packet file created for a packet that has not yet been received by the user terminal 201 (or 202) is created. Was there. But,
The packet data management portion 8 of the main file 701 indicates the value indicating that the packet data has not been received yet.
02, the 1-byte value “0” may be returned when the file is read. Therefore, in the third embodiment, unlike the above-described first and second embodiments, a method of not creating a zero-length packet file will be described.

In the processing configuration according to the third embodiment,
The first and second embodiments are different from each other in the main file creation process performed in step S603 of the flowchart showing the cache creation process shown in FIG. 6 and the data overwrite process of the received packet performed in step S606.

FIG. 19 is a flow chart showing the process of creating the main file 701 (corresponding to S603 in FIG. 6) according to the third embodiment of the present invention. The process of steps S901 to S903, and steps S905 and S907. 9 is the same as the processing configuration of the same step number in the first embodiment described above with reference to FIG. 9, and therefore description thereof will be omitted.

That is, in the main file creating process according to the third embodiment, there is no need to perform step S904 in FIG. 9, that is, the step of creating a zero-length packet file for a packet that has not been received.
Further, in response to this processing configuration, in the third embodiment,
The tile basic information created in step S1906 in FIG. 19 is different from that in the above-described first and second embodiments.
Therefore, a process of creating tile basic information according to the third embodiment will be described with reference to FIG.

FIG. 20 is a flow chart showing the tile basic information creation processing (S1906) according to the third embodiment. For the processing of steps S101 to S1007 and steps S1009 and S1010, refer to FIG. Since it is the same as the processing configuration of the same step number in the above-described first embodiment described above, the description thereof will be omitted.

In step S2008, the data length 1 of the packet of interest, a value indicating that this packet is a zero-length packet, resolution level, layer,
Information necessary for managing the packet of interest, such as the component and the position number, is written in the area 802 of the main file 701. As a value indicating that this is a zero-length packet file, for example, a value such as NULL may be written in 803.

In the third embodiment, since no file is created for the zero length packet, only the main file 701 is created in the user terminal in the initial state when the processing of the flowchart shown in FIG. 20 is finished.

According to the description of the main file 701, the data portion in the cache file created by the processing up to this point and the value “0” corresponding to each packet are
When sent sequentially to the JPEG2000 decoder, the image size, which is the basic information of the image data,
Decoding can be performed under the same conditions. That is, in the decoder, all the packets are judged to be in the “absent” state and can be decoded.

FIG. 21 is a flowchart showing the main file overwrite processing (S606) according to the third embodiment. Steps S1201 to S1203,
Also, since the processes of steps S1205 and S1206 are the same as the processes of the same step numbers in the above-described first embodiment described with reference to FIG. 12, the description thereof will be omitted.

In step S2104, the area 803 containing the value indicating that the packet of interest is a zero-length packet is rewritten with the pointer information to the file created in step S1202. For example, the area 803 in which the value NULL indicating that the packet is a zero-length packet is written is “image_tile00000_pkt0002.ii.
It is rewritten as the name "p2k".

According to the third embodiment in which such a caching method is performed in the user terminal, only the main file 701 and the file of the received packet data are created, so that the first and second embodiments described above are performed. It is possible to reduce the number of files to be created compared to.

<Fourth Embodiment> In the first to third embodiments described above, all files are created under the same folder. However, when the number of packets received from the server 204 is large, those packets may be distributed and managed in a plurality of folders.

FIG. 22 shows the fourth embodiment of the present invention.
It is a figure explaining the example which saves packet data in a folder for every tile. In this example, the file of the packet data contained in the same tile is saved in the same folder.

In FIG. 22, the original image 2201 is divided into four tiles. The server 204 responds to the request received from the user terminal by
Only the packet data 2202 is extracted from the image data and the packet data 2202 is sent to the user terminal. Then, this user terminal prepares four folders 2203, 2204, 2205, and 2206 for each tile, and stores the packet data file created from the packet data in the folder corresponding to the packet data received from the server 204. save.

The difference of the fourth embodiment from the above-described first to third embodiments is the process of step S603 in the operation process (FIG. 6) of caching the data received from the server 204 by the user terminal.

FIG. 23 is a flow chart showing the main file 701 creation processing (S603) according to the fourth embodiment. The processing of steps S901 to S903 and steps S904 to S907 is as follows.
Since the processing configuration is the same as that of the same step number in the first embodiment described with reference to FIG. 9, description thereof will be omitted.

In step S2301, step S90
By determining whether the number of packets obtained in 3 exceeds a predetermined number, it is determined whether or not to create a folder for each tile. This determination is not necessary if the system always creates a folder for each tile, but for example, based on the information indicating the processing capacity of the CPU 101 of the user terminal,
The number of files (threshold value) that can be handled with ease in one folder is determined, and if there are more packets than the threshold value, a folder is created for each tile. Various methods are conceivable as a method of obtaining this threshold value, but the description thereof is omitted because it is not a feature of the present application.

If it is determined in step S2301 that a folder for each tile is not created, the process advances to step S904. On the other hand, if it is determined in step S2301 that a folder is created for each tile, the process advances to step S2302, and the user terminal creates folders by the number of tiles.
For example, if the "image.jp2" file is divided into 50 tiles, "image_tile0000" to "image_ti"
The folder named "le0049" is the main file "im
It is created in the Temp folder of C drive, the same as "age.iip2k".

In the fourth embodiment, a zero length packet file corresponding to each packet is created in each folder. Therefore, step S90 in FIG.
The detailed procedure of the tile basic information created in 6 is
This is the same as the tile basic information creation process (FIG. 10) in the first embodiment. In this case, pointer information indicating each packet file, that is, the main file 701
In the area 803 of, a file name, for example, “image_tile00
The file name "00_pkt0002.iip2k" may be written, and the path including "C: / Temp / image_tile0000 / image"
"_tile0000_pkt0002.iip2k" may be written.

FIG. 24 is a conceptual diagram showing the structure of the cache file according to the fourth embodiment.

In the fourth embodiment, 1 is set for each packet.
Although only the method similar to that of the first embodiment in which one zero-length packet file is created is described, the method of creating one zero-length packet file as in the above-described second embodiment, or the third embodiment. , A value indicating that the packet is a zero-length packet, such as NULL, is created without creating a zero-length packet file at all.
It can also be realized by a method of writing in the area 803 of the main file 701. Further, as in the second embodiment described above,
When creating one zero-length packet file, the file may be created in the same folder as the main file 701, for example, in the Temp folder of the C drive.

Further, when there is a possibility that a user terminal handles a plurality of images, a folder may be created for each image. For example, as shown in FIG. 25, a folder for each image may be created in the Temp folder of the C drive, and the folder may be further divided into folders for each tile. Under the image-specific folder, it is possible to create the cache file described in the first to fourth embodiments.

As described above, according to the fourth embodiment, the cache file is composed of a plurality of packet data files. However, by dividing each tile into folders, the number of files created in one folder can be reduced. Since it can be restricted, there is an advantage that processing depending on the OS (operating system) of the user terminal, such as file creation and deletion, can be performed more quickly than in the other embodiments described above.

<Fifth Embodiment> In the present embodiment, a method of reading the cache file created in the above-described first, second, and fourth embodiments will be specifically described with reference to the drawings.

FIG. 26 is a flow chart showing the process of reading a cache file in the user terminal.
The details of the processing for reading the cache file created in the user terminal in the above-described first, second, and fourth embodiments will be described.

First, in step S2601, the main file 701 created in step S603 of FIG. 6 is opened. For example, if a main file with the file name "image.iip2k" is created in the Temp folder of the C drive for "image.jp2", "C: / Temp / imag
e.iip2k "is opened. Next, proceeding to step S2602, it is determined whether the data to be read is main header data. If it is determined that the main header is not read here, the process proceeds to step S2604, but if it is determined that the main header is read, the process proceeds to step S2603, and the main header data of the main file 701 acquired from the server 204 is written as it is. Area 7
The file pointer is moved to 03 and the data of the main header is read. And step S2604
Then, it is determined whether the data to be read is tile header data. If it is determined that the tile header data is read out, the process advances to step S2605. If it is determined that the tile header data is not read, the process advances to step S2606.

In step S2605, the file pointer is moved to the portion of the main file 701 where the tile header 705 to be read is described, and the tile header data is read.

Here, for example, in step S2605, when the tile number starts from “0” and the tile header to be read is the header of tile number 1,
Data 7 regarding the tile of tile number 1 that is stored after the image information 706, main header data 703, and data 702 regarding tile number 0 are skipped from the beginning of the main file 701 shown in FIG.
02, the file pointer is moved to the beginning of the tile header data 705 next to the management data 704 of the tile data therein, and then the data of the tile header 705 is read.

Next, in step S2606, it is determined whether the data to be read is packet data. Here, if it is determined that the packet data is read, the process proceeds to step S2607, and if it is determined that the packet data is not read, the process proceeds to step S2608. In step S2607, the data is read from the packet file in which the data of the packet to be read is stored (the details of step S2607 will be described later with reference to FIG. 27).

Next, in step S2608, it is determined whether or not there is data to be read, and if there is data to be read, the process returns to step S2602 and the above processing is repeated. On the other hand, if it is determined in step S2608 that all the data to be read has been read, step S260
9, the main file 701 that has been opened is closed, and this read processing ends.

FIG. 27 is a flowchart showing the packet data read processing (step S2607) according to the fifth embodiment of the present invention.

In the figure, first, step S2701.
Then, the file name is acquired according to the information of the pointer 803 to the file containing the data of the packet to be read. For example, when reading the data of the packet number 0 of the tile number 1, the area 702 where the tile information related to the tile number 1 is written from the main file 701.
And the packet data management data 802 with the packet number “0” is searched from among them. Then, the file name of the packet management data 802 is acquired based on the information of the pointer 803 to the file in which the packet data is described.

Next, proceeding to step S2702, the file with the file name obtained in step S2701 is opened. For example, the file name acquired in step S2702 is C
The file "image_zero.iip2" in the Temp folder of the drive
If it is "k", the file "image_zero.ii" in this folder
p2k "is opened. Also, the file name acquired in step S2702 is "C: / Temp / Tile0001 / image_tile0000_pkt0".
000.iip2k ”, Til in the Temp folder on the C drive
The file "image_tile0000_pkt000" in the e0001 folder
0.iip2k ”is opened.

Next, proceeding to step S2703, the data in the file opened in step S2702 is read. Next, the process proceeds to step S2704, and step S27
The file opened in 02 is closed, and the packet data read processing ends.

As described above, in the above-mentioned reading method according to the fifth embodiment of the present invention, when the user terminal reads the packet data, the information of the pointer 803 to the packet file described in the main file 701 is stored. The data in that file has been read since the file that it points to has been opened.

According to the fifth embodiment, the cache files created in the above-described first, second, and fourth embodiments can be efficiently read.

<Sixth Preferred Embodiment> The first and second preferred embodiments described above.
In Nos. 2 and 4, zero-length packet data is created even for packet data that has not yet been received by the user terminal, so all packet data is written in the file.

However, in the above-described third embodiment, since the file is created only for the received packet, the file corresponding to the unreceived packet does not exist in the user terminal. Therefore, in the reading method according to the fifth embodiment described above, there is packet data that cannot be read. Therefore, in the sixth embodiment, a method of reading the cache file created in the third embodiment will be described.

In the sixth embodiment, since the processing configuration of step S2607 is different from the cache file reading processing (FIG. 26) described in the fifth embodiment, the following description will be focused on this point. To do.

FIG. 28 shows the sixth embodiment of the present invention.
28 is a flowchart showing a read process of packet data, and since the processes of steps S2702 to S2704 are the same as the process configuration of the same step numbers in the fifth embodiment described with reference to FIG. 27, the description thereof will be omitted. .

In the figure, first, step S2801.
Then, the information of the pointer 803 for the packet to be read from the main file 701 is acquired. Next, proceeding to step S2802, it is determined whether the information of the pointer 803 acquired in step S2801 is a pointer to a packet data file. For example, the acquired information is "C: / Tem
If the file name is “p / image_tile0000_pkt2.iip2k”, it is determined that it is pointer information to the file, and if the acquired information is NULL, it can be determined that the file is not pointed. If it is determined in step S2802 that the pointer information 803 is information indicating a file, the process proceeds to step S2702, and the subsequent processing is the same as that in the fifth embodiment.

On the other hand, if it is determined that the pointer 803 does not point to the file, step S2803.
And there is no file for the packet, so
It is determined that the data is unreceived data, and a 1-byte value “0” indicating a zero-length packet is returned as read information.

According to the sixth embodiment, the cache file created in the above-described third embodiment can be efficiently read.

Since the sixth embodiment described above is a read method when a zero-length packet file is not created for unreceived data, as described in the fourth embodiment, each tile is read. Alternatively, even when a folder is created for each image, the same reading method can be applied when a zero-length packet file is not created for unreceived data.

<Seventh Embodiment> In the first to sixth embodiments described above, each packet data is stored and managed in one cache file. However, a plurality of packets are stored in one file. It is also possible to manage. That is, it is possible to perform storage management with one cache file for one image.

FIG. 29 is a flow chart showing the cache processing of received data in the user terminal (image processing apparatus: 201 or 202) according to the seventh embodiment of the present invention. In this figure, the steps that perform the same operations as in FIG. 6 described above are given the same numbers.

First, in step S601, the server 204 storing a plurality of images is requested via the network 203 from the user terminal for the required image name and image main header. This allows the server 2
The packet data sent from 04 is received, and in step S602, it is determined whether the main header has been received. If the main header is received, the process proceeds to step S2903, and based on the received main header, as shown in FIG. A file (hereinafter referred to as a collective cache file) for storing the entire image information and information for managing the cache data, and the cache data itself is created, and the main header acquired in step S602 is stored in the collective cache file area 703. Write. The batch cache file created here is the same as in the first to fourth embodiments described above.
Although the data format is the same as that of the main file 701 created in (see FIG. 7 for the data structure), the following two points are different. (1) The actual cache data itself is also written (2) The pointer 803 included in the management data 802 of the packet data in FIG. 8 has an offset value 3002 (see FIG. 3).
Has been changed to 0).

FIG. 30 shows packet management data 802 in area 702a (corresponding to area 702 in FIG. 8) of batch cache file 701a (FIG. 31) according to the seventh embodiment.
It is a figure which shows the structure of a.

That is, when the user terminal receives the main header in step S602, the user terminal proceeds to step S603, and sets the batch cache file 701a in the desired area of the secondary storage 103 (for example, the Temp folder of the C drive) and the name of the original image. Create as a file with the file name inserted at the beginning. For example, when the user requests the "image.jp2" file, the user terminal displays "image.iip2".
A batch cache file with a name such as “k” is created in the folder of the secondary storage 103.

Next, in step S604, the server 204 is requested via the network 203 for the necessary image area, resolution, layer, and component in accordance with the user's selection operation. Here, step S60
Since the user's selection operation in 4 is not related to the essence of the cache method, which is the main purpose of the present application, detailed description thereof will be omitted.

As a result, the server 204 transmits the image portion instructed by the user terminal to the user terminal in JPEG2000 packet units. By this, step S
When the packet data is received at 605, step S
In step 2906, the information for managing the cache data relating to the received packet data is rewritten, and as shown in FIG. 31, the packet data is written in the area 3101 in a format of appending after the batch cache file 701a. Next, in step S607,
It is determined whether or not an operation requesting further image data is performed by the user, and if the requested operation is detected, the process returns to step S604 to execute the above-described operation, but if the requested operation is not detected, the process returns. .

FIG. 32 is a flow chart for explaining the creation processing of the collective cache file 701a in step S2903 of FIG. Note that the same operations as those in the flowchart showing the main file creation processing shown in FIG.

First, in step S901, by analyzing the main header received from the server 204, the height and width of the original image, the height and width of the tile at the maximum resolution, and the reso
Number of solution levels, layers, components, positi
Get on number and progress order. Then step S
Proceeding to 902, the number of tiles is calculated based on the height and width of the original image and the height and width of the tile at the maximum resolution. Next, the procedure proceeds to step S903, and the information acquired in step S901
The number of packets included in each tile is calculated based on the number of resolution levels, the number of layers, the number of components, and the number of positions.

Next, proceeding to step S3204, basic information of the original image such as the number of tiles, the number of resolution levels, the number of layers and the number of components obtained by analyzing the main header in step S901, the zero length packet data, In addition, the data length of the main header is used as image management information in the area 706a of the batch cache file 701a.
(Fig. 31). This batch cache file 7
The data of the received main header is written in the area 703a of 01a. Next, in step S3205,
Basic information of each tile is created in the area 702a of the collective cache file 701a as shown enlarged on the right side of FIG. Then, the process proceeds to step S3206, the basic information of each tile created in step S3205 is written to the batch cache file 701a, and the batch cache file creation process ends.

FIG. 33 is a flowchart showing the process of creating the basic information of tiles in step S3205 of FIG. 32 according to the seventh embodiment, and the steps common to the flowchart shown in FIG. ing. In this step S3205, the operation shown in the flowchart of FIG. 33 is repeated for the number of tiles in the order of tile numbers, so that the area 702a of the collective cache file 701a shown in FIG. 30 is created.

In FIG. 33, first, step S1001.
Then, already calculated in step S903 of FIG. 32,
Get the number of packets contained in each tile. At this point, the user terminal has not received the packet data from the server 204, and it is assumed that all the unreceived packets are processed as zero-length packets. Therefore, in the next step S1002, each tile is processed. Data length is calculated by (length of tile header) + (number of packets included in tile) × 1 byte.

For example, if the marker included in the tile header is
When 36 packets are included in one tile with only the SOT marker, the data length of the tile is 14 + 1 × 36 = 50.
It becomes [byte].

Next, proceeding to step S1003, an SOT marker to be included in the tile header in the JPEG2000 system is created from the tile number and tile data length.
Here, the tile number is "0" and the number of included packets is "3".
The configuration of the SOT marker created for the 6 ”tile,
The data size and specific values are shown in FIG.

Next, proceeding to step S3304, the tile data length 804a, the tile number 805a and the number of packets included 806a, the number of resolutions included in the tile, the number of layers, the number of components, etc. are used for tile data management of the batch cache file 701a. Write to the data 704a. Next, proceeding to step S3305, the tile header is written in the area 705a of the batch cache file 701a. Next, proceeding to step S1006, "0" is set to the packet number, and thereafter, the processing from step S1007 onward is repeated in the order of packet numbers.

In step S1007, the original image progre
According to ssion order, resolu corresponding to packet number
tion level, layers, components, and position
Identify the number. Next, proceeding to step S3308, the data length 1 of the packet of interest and the offset value up to the zero-length packet data written in the area 706a of the batch cache file 701a as the offset value of this packet data at step S3204, resoluti.
Area 80 of the batch cache file 701a stores information necessary for managing currently focused packets such as on level, layer, component, and position number.
Write to 2a.

Next, the processing proceeds to step S1009, the packet number of the packet to be noted is incremented by 1, and step S10
In step 10, it is determined whether or not the series of processes from step S1007 has been performed on all the packets included in the tile, and if it is determined that all the packets have been completed, this operation ends. For example, if the number of packets is "3
In the case of "6", if the packet number after step S1009 is "36", this processing ends.

FIG. 34 is a flow chart showing the process of overwriting the collective cache file 701a in step S2906 of FIG. 29, and the process steps common to the process shown in FIG. 12 are given the same numbers.

First, in step S1201, information for identifying a tile number and a packet number including a packet to be written in the cache is acquired. Next, step S3402.
Then, the file length (last_byte) of the batch cache file 701a is acquired. Next, proceeding to step S3403, the length of this packet data written in the batch cache file 701a is rewritten to the data length of the received packet, that is, the packet to be written in the cache. Next, proceeding to step S3404, the offset value 3002 of the data of this packet is overwritten with the value of last_byte acquired at step S3402 in the batch cache file 701a. And step S34
In step 05, the data length 804a of the tile of the area 801a in FIG. 30 written in the batch cache file 701a is recalculated and overwritten as the information of the tile included in this packet. For example, if the data length of the packet to be written in the cache is 128 bytes, the batch cache file 701a calculates the data length of the unreceived packet as 1 byte, which is zero length / packet length. Therefore, the data length of the tile recalculated here is (128-1) = 127 [bytes]. This value is the data length of the tile that has already been written 804
The data length of a new tile is obtained by adding it to a. Next, proceeding to step S1206, in the same manner as in FIG.
The portion indicating the tile length in the tile header is calculated in step S3.
It is rewritten with the value recalculated in 405. Then step S
Proceeding to 3407, the packet data 3101 is appended to the batch cache file 701a. That is, this packet data is written at the end of the batch cache file 701a, and this routine ends.

When the cache method according to the seventh embodiment described above is used, one cache file has only to be managed for one image, so that the management of data can be prevented from becoming complicated.

<Embodiment 8> In Embodiment 8, a method of reading the batch cache file 701a created in Embodiment 7 described above will be specifically described with reference to the drawings.

FIG. 35 is a flow chart showing the process of reading the batch cache file 701a in the user terminal according to the eighth embodiment of the present invention. The cache file created in the user terminal in the above-described seventh embodiment is read out. The details of the processing are shown. Incidentally, the steps having the same operations as those in FIG. 26 are given the same numbers. The difference from this FIG. 26 is that instead of reading the cache file that stores only the table called the main file in FIG. 26, the packet with the table data called the collective cache file in the seventh embodiment is read. The point is to read the cache file 701a that also caches data. Therefore, step S3507 in FIG. 35 is different in that packet data is read from the file opened in step S2601.

FIG. 36 shows FIG. 35 according to the eighth embodiment.
14 is a flowchart showing a packet data reading process in step S3507 of FIG.

First, in step S3601, regarding the packet data read by this routine, from the data length 807a and offset value 3002 of the cache management data 802a shown in FIG. 30, the data length (p_length) of the packet data and the head of the batch cache file 701a are calculated. To the start value of the actually cached packet data (p_offset), respectively.
Next, proceeding to step S3602, the offset value (p_offset) and data length (p_leng) acquired at step S3601.
th)), the target packet data is read out, and this read processing is terminated.

That is, the batch cache file 701a
The target packet data can be obtained by moving the pointer from the beginning of the to the position of the byte indicated by the offset value (p_offset) and reading the number of bytes of data indicated by the data length (p_length) from the pointer position.

By using the cache write method described in the seventh embodiment and the cache read method according to the eighth embodiment, the data corresponding to the unreceived packet data is actually written in the cache file 701. In this case, it is possible to read the packet data by the same operation without providing a conditional branch for whether or not the packet data is unreceived when reading the data. <Embodiment 9> In the above-described Embodiment 7, A zero-length packet was inserted at the position of unreceived packet data, and the zero-length packet was written in the area 706a of the batch cache file 701a. On the other hand, in the ninth embodiment, the value of the zero-length packet data corresponding to the unreceived packet data is not actually written in the batch cache file 701a, but a value indicating that the packet has not been received is set in the packet of FIG. Data for data management 8
In the area 3002 where the offset value of 02a is written, “NUL
Write "L".

The cache file 7 created in this way
When reading 01a, the difference from Embodiment 8 described above resides in the packet data reading method shown in step S3507 in FIG.

FIG. 37 shows the ninth embodiment of the present invention.
In the flowchart showing the packet data reading process, the same steps as those in FIG. 36 described above are denoted by the same reference numerals. The flowchart of FIG. 37 differs from the flowchart of FIG. 36 in that step S3 in FIG.
This is after the conditional branch of 702.

In step S3702, step S36.
It is determined whether the offset value (p_offset) acquired in 01 is "NULL", and if so, the process proceeds to step S3704, and if not, the process proceeds to step S3602. That is, if the offset value (p_offset) is NULL, it is determined that this packet has not been received and the process proceeds to step S3704, and if it is a value other than NULL, it is determined that the packet is a received and cached packet and step S3602. Proceed to. The process of step S3602 is a process of reading packet data by the same operation as that of FIG. 36 described above.

On the other hand, in step S3704, since the data is not received in the cache file 701a because it is unreceived data, it is written in the read buffer of the zero-length packet data which replaces the unreceived data.

According to the ninth embodiment, since the seek of the file for reading the unreceived data is reduced,
The data reading speed can be increased.

In the above description, for convenience, all cache files or cache file folders are created in the Temp folder of the C drive, but the location where the cache files and cache folders are created is not limited to this. It is also possible to change the place where the cache file is created as appropriate according to the environment variable.

The image data cache read / write method described above (that is, the cache file creation method according to the first to fourth embodiments, the cache file read method according to the fifth and sixth embodiments, and the seventh embodiment). Cache file creation method according to Embodiment 9 and Embodiment 8;
According to the cache file reading method according to No. 9,
The fragmented encoded data is converted into the user terminal 201 (or 20
It can be easily managed in 2), and by sequentially reading the created cache file, even if not all fragmentary encoded data of the image to be displayed is actually received, JPEG2000 It becomes possible to read out as one encoded data conforming to the format of the encoded data. For this reason, the general specification JPEG20
If the 00 decoder is prepared for the user terminal, the user terminal can display an image with the resolution desired by the user.

Even if the cache file is not completely filled with the encoded data of one image, the sequential reading as described above results in the encoded data read into the primary storage 102 of the user terminal. Is encoded data that is fully compliant with the JPEG2000 encoded data format and is a special JPEG for this cache file.
The advantage is that no 2000 decoder is needed.

Further, even when the encoded data is added during the fragmentary transmission from the server 204, there is an advantage that the file can be added at a high speed by replacing the corresponding packet data file.

[Other Embodiments] The object of the present invention is to provide a storage medium (or recording medium) recording a program code of software for realizing the functions of the above-described embodiments.
The computer (or CPU) of the system or the device is supplied to the device that operates as the image processing device described above.
Or MPU) reads and executes the program code stored in the storage medium. Alternatively, if the image data to be processed is available from the outside and the processing is up to the display of the compressed image on the display,
Even in a general information processing device such as a personal computer, the same object can be achieved by executing the program code of software that realizes the functions of the above-described embodiments. In these cases, the program code itself read from the storage medium realizes the functions of the above-described embodiments, and is acquired as a computer program product via the storage medium storing the program code, the telecommunication line, or the like. The program code
It constitutes the present invention.

Further, by executing the program code read by the computer, not only the functions of the above-described embodiment are realized, but also the operating system (OS) running on the computer is executed based on the instruction of the program code. ) And the like perform part or all of the actual processing, and the processing realizes the functions of the above-described embodiments.

Furthermore, after the program code read from the storage medium is written in the memory provided in the function expansion card inserted in the computer or the function expansion unit connected to the computer, based on the instruction of the program code. The case where the CPU or the like included in the function expansion card or the function expansion unit performs a part or all of the actual processing and the processing realizes the functions of the above-described embodiments is also included.

[0163]

As described above, according to the present invention, image data fragmented in a predetermined format can be decoded based on the predetermined format and easily cached.

[Brief description of drawings]

FIG. 1 is a block diagram showing a schematic configuration of a computer device which is an image processing apparatus according to an embodiment of the present invention.

FIG. 2 is a diagram showing an outline of a communication network according to the present embodiment.

FIG. 3 is a diagram showing a configuration of JPEG2000 encoded data.

FIG. 4 is a diagram illustrating the resolution scalability of JPEG2000.

FIG. 5 is a diagram illustrating a communication protocol between a server and a client according to the present embodiment.

FIG. 6 is a flowchart showing received data cache processing in the user terminal according to the first to sixth embodiments of the present invention.

FIG. 7 is a diagram illustrating a data structure of a main file that manages the entire image information according to the present embodiment.

8 is a configuration diagram of management data of tile data included in the main file shown in FIG. 7. FIG.

9 is a flowchart showing a main file creation process in step S603 of FIG.

FIG. 10 is a flowchart showing a tile basic information creation process in step S906 of FIG.

FIG. 11 is a diagram illustrating the configuration of an SOT marker.

FIG. 12 is a flowchart showing the main file overwrite processing in step S606 of FIG.

FIG. 13 is a diagram showing a configuration example of response data from a server.

FIG. 14 is a diagram showing a configuration example of a cache file in a user terminal according to the first embodiment.

FIG. 15 is a flowchart showing a main file creating process according to the second embodiment of the present invention.

16 is a flowchart showing a tile basic information creation process in step S1506 of FIG.

FIG. 17 is a flowchart showing main file overwrite processing according to the second embodiment.

FIG. 18 is a diagram showing a data structure of a cache file in the user terminal according to the second embodiment.

FIG. 19 is a flowchart showing a main file creating process according to the third embodiment of the present invention.

20 is a flowchart showing the tile basic information creation processing shown in step S1906 of FIG.

FIG. 21 is a flowchart showing main file overwrite processing (S606) according to the third embodiment.

FIG. 22 is a diagram illustrating an example in which packet data according to the fourth embodiment of the present invention is stored in a folder for each tile.

FIG. 23 is a flowchart showing a main file creating process according to the fourth embodiment.

FIG. 24 is a conceptual diagram of a cache file configuration according to the fourth embodiment.

FIG. 25 is a conceptual diagram showing a cache folder for each image according to the fourth embodiment.

FIG. 26 is a flowchart showing a process of reading a cache file in a user terminal according to the fifth embodiment of the present invention.

FIG. 27 is a flowchart showing a packet data read process in step S2607 of FIG.

FIG. 28 is a flowchart showing a packet data reading process according to the sixth embodiment of the present invention.

FIG. 29 is a flowchart showing a cache process of received data in the user terminal according to the seventh embodiment of the present invention.

FIG. 30 is a diagram illustrating packet data management data in a batch cache file according to the seventh embodiment.

FIG. 31 is a diagram illustrating a state after writing packet data in the batch cache file according to the seventh embodiment.

32 is a flowchart showing the batch cache file creation processing in step S2903 of FIG. 29. FIG.

FIG. 33 is a flowchart showing a tile basic information creation process in step S3205 of FIG. 32.

FIG. 34 is a flowchart showing a process of overwriting a cache file in step S2906 of FIG.

FIG. 35 is a flowchart showing a process of reading the batch cache file created in the seventh embodiment in the user terminal according to the eighth embodiment of the present invention.

FIG. 36 is a step S35 in FIG. 35 according to the eighth embodiment.
It is a flowchart which shows the packet data reading process in 07.

FIG. 37 is a flowchart showing a packet data read process according to the ninth embodiment of the present invention.

─────────────────────────────────────────────────── ─── Continued Front Page (51) Int.Cl. ⁷ Identification Code FI Theme Coat (Reference) H04N 7/173 640 H04N 7/173 640A 7/24 7/13 Z

Claims (26)

[Claims] 1. An image processing device for receiving coded data fragmented in a predetermined format for an image desired by a user from an external device connected so as to be able to communicate with each other via a communication network and caching the coded data. Receiving means for receiving header data relating to the image from the external device prior to reception of the encoded data; the number of tiles constituting the image based on the header data received by the receiving means; And a calculation means for calculating the quantity of the coded data necessary to configure the above, and for each of the tiles calculated by the calculation means, a predetermined number of dummy coded data corresponding to the quantity of the coded data are provided. Of the dummy data generation means to be set and the dummy encoded data set by the dummy data generation means, Dummy coded data corresponding to the encoded data actually received from the Kigaibu device,
An image processing device, comprising: a data replacement unit that replaces the encoded data received from the external device. 2. A management file creating means for creating a management file of the encoded data based on attribute information included in the header data prior to setting the dummy encoded data by the dummy data generating means. The data replacement unit manages the dummy coded data and the coded data based on different area reference information inside the storage medium using the management file, and rewrites the area reference information. The dummy encoded data is thereby replaced with the encoded data actually received from the external device.
The image processing device according to item 1. 3. The image processing device according to claim 1, wherein the encoded data fragmented in the predetermined format is encoded data in packet units based on the JPEG2000 system. 4. The dummy encoded data is the JPEG20.
The image processing apparatus according to claim 3, wherein the data is zero length packet data defined by a bitstream syntax conforming to the 00 system. 5. The dummy data generating means is configured to perform the zero operation.
The image processing apparatus according to claim 4, wherein the data of length packet is set for each of the packets. 6. The fragmented coded data in the predetermined format is coded data in packet units based on the JPEG2000 system, and the dummy data generation means is configured to perform the zero l
The data of the ength packet is composed of one file in one cache, and the data replacing means refers to the one file according to the file name of the management file that manages the encoded data in packet units. The image processing apparatus according to claim 2, wherein: 7. The fragmented coded data in the predetermined format is coded data in packet units based on the JPEG2000 system, and the dummy data generation means is configured to perform the zero l
7. The image processing device according to claim 2, wherein NULL is set as the data of the ength packet. 8. The dummy data generation means, according to the number of the packets as the quantity of the encoded data,
The image processing apparatus according to claim 3, wherein the packets are distributed and stored in a plurality of folders. 9. The image processing apparatus according to claim 3, wherein the dummy data generation unit generates a folder for each of the encoded data. 10. The cache file replaced by the data replacement unit is sequentially read, and a decoding unit is provided for decoding the read data based on a decoding procedure conforming to the predetermined format. The image processing apparatus according to claim 1. 11. A management file creating means for creating a management file of the encoded data based on attribute information included in the header data, prior to setting the dummy encoded data by the dummy data generating means. The data replacement unit stores the dummy coded data and the coded data in the same file as the management file, and rewrites the area reference information in the management file to thereby write the dummy code. The image processing apparatus according to claim 1, wherein the encoded data is replaced with the encoded data actually received from the external device. 12. The fragmented coded data in the predetermined format is coded data in units of packets based on the JPEG2000 system, and the dummy data generating means stores one zero length packet data in one cache. The data replacement means generates the ze according to offset information indicating a storage location of the encoded data in packet units.
The image processing apparatus according to claim 11, wherein the data of ro length packet is referred to. 13. A data cache method in an image processing apparatus, which receives fragmented coded data in a predetermined format for an image desired by a user from an external apparatus connected so as to be able to communicate with each other via a communication network and caches the coded data. A receiving step of receiving header data related to the image from the external device prior to receiving the encoded data; the number of tiles forming the image based on the received header data; For each of the tiles calculated in the calculation step, and a calculation step for calculating the number of the coded data necessary for configuring
A dummy data generating step of setting predetermined dummy encoded data by the number of the encoded data; and the code actually received from the external device among the dummy encoded data set in the dummy data generating step. A data replacement step of replacing dummy coded data corresponding to the coded data with the coded data received from the external device, the data cache method in the image processing apparatus. 14. A management file creating step of creating a management file of the encoded data based on attribute information included in the header data prior to setting the dummy encoded data in the dummy data generating step. Further, in the data replacing step, the dummy coded data and the coded data are managed based on different area reference information inside the storage medium using the management file, and the area reference information is stored. 2. The dummy encoded data is replaced by the encoded data actually received from the external device by rewriting.
3. The data cache method described in 3. 15. The data cache method according to claim 13, wherein the encoded data fragmented in the predetermined format is encoded data in packet units based on the JPEG2000 system. 16. The dummy encoded data is the JPEG
The data cache method according to claim 15, wherein the data is zero length packet data defined by a bitstream syntax conforming to the 2000 system. 17. The dummy data generating step comprises:
The data cache method according to claim 16, wherein zero length packet data is set for each packet. 18. The fragmented encoded data in the predetermined format is encoded data in packet units based on the JPEG2000 system, and in the dummy data generating step, the ze
The data of ro length packet is 1 in one cache
15. The file is configured with one file, and in the data replacing step, the one file is referred to according to a file name of the management file that manages the encoded data in the packet unit. Data cache method. 19. The fragmented coded data in the predetermined format is coded data in packet units based on the JPEG2000 system, and in the dummy data generating step, the ze
19. The data cache method according to claim 14, wherein NULL is set as the data of the ro length packet. 20. The dummy data generating step according to claim 15, wherein the packets are distributed and stored in a plurality of folders according to the number of the packets as the quantity of the encoded data. Data caching method. 21. The data cache method according to claim 15, wherein a folder is generated for each of the encoded data in the dummy data generating step. 22. The method further comprises a step of sequentially reading out the cache file replaced in the data replacing step and decoding the read data based on a decoding procedure conforming to the predetermined format. 22. The data cache method according to any one of items 13 to 21. 23. Prior to the setting of the dummy encoded data in the dummy data generating step, a management file creating step of creating a management file of the encoded data based on attribute information included in the header data is further included. In the data replacing step, the dummy coded data and the coded data are stored in the same file as the management file, and the dummy code is rewritten by rewriting area reference information in the management file. 14. The data cache method according to claim 13, wherein the encoded data is replaced with the encoded data actually received from the external device. 24. The fragmented coded data in the predetermined format is coded data in units of packets based on the JPEG2000 system, and the dummy data generating step generates one zero length packet data in one cache. And generating the data in the data replacement step according to offset information indicating a storage location of the encoded data in packet units.
The data cache method according to claim 23, wherein the data of the ro length packet is referred to. 25. A computer program for causing a computer to operate so as to execute the data cache method according to any one of claims 13 to 24. 26. A computer-readable storage medium having the computer program according to claim 25 stored therein.