JP2007053445A - Server and its control method, computer program, storage medium - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a technology for reducing hardware requirements requested for the data receiving side in a configuration for transmitting/receiving image data encoded hierarchically. <P>SOLUTION: The server comprises a means for storing image data consisting of one or more packets for each resolution level, a means for receiving a transmission request including designation of the resolution level of image data and information about the storage capacity of an external unit from the external unit, a means for determining whether a predetermined processing is performed or not, based on comparison of the image data size and the capacity information, a means for performing a processing for creating return data when a decision is made to perform the processing by the determining means by adding a packet included in a resolution level below a specified level to the return data and adding a packet not included in a resolution level to the return data while replacing the length by ZLP, and a means for delivering the created return data to the external unit. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a technique for transmitting and receiving image data.

  In recent years, the resolution of displays used in computer display devices and the like has improved. The resolution of the display that was once popular was about VGA (640 × 480 pixels) or SVGA (800 × 600 pixels) or less. On the other hand, even a notebook PC (Personal Computer) now has a display of XGA (1024 × 768 pixels) or more. A display having a resolution of about SXGA (1280 × 1024 pixels) or UXGA (1600 × 1200 pixels) is widely used as a display attached to a desktop PC or the like. It can be easily guessed that displays that support high resolution such as QXGA and QUXGA will become widespread in the future.

  On the other hand, there is known an application that displays a large number of image data taken by a digital camera or the like as thumbnail images (reduced images) and displays one of them in detail at the size of the original image based on a predetermined event. Yes. Such applications generally use display technologies such as zoom and scroll.

  In such an application, when displaying a large number of image data at the same time, high speed is regarded as important. Therefore, thumbnail image data created in advance different from the main image data is often used. On the other hand, in the single image display selected from the thumbnail display, the entire image is often displayed until it can be displayed on the window size of the application or the display device using the main image data. For enlarged display beyond that, a part of the image is often displayed.

  In such an application that uses a plurality of types of image data having an image size smaller than that of the original image data when displaying one image data, the following processing is performed. That is, the decoding process is performed as necessary, and the image size of the original image data is reproduced once, and then the process of reducing the image data so as to obtain the target image size is performed.

  On the other hand, the image data is uncompressed or compressed by a sequential encoding method such as JPEG baseline. Alternatively, the image data is compressed by a hierarchical encoding method, and the image size required for display is decoded and displayed.

  As a hierarchical encoding method, for example, there is a JPEG2000 encoding method. JPEG2000 is a hierarchical encoding method in which one piece of image data is divided into one or more tiles, and an image having one or more resolutions is hierarchically stored for each divided tile. JPEG2000 is also known as an image encoding method standardized by ISO / ITC in 2001.

  The JPEG2000 encoding method has many encoding options at the time of encoding. However, a decoder that supports all functions requires a large development cost, and requires more advanced computing resources (CPU clock, memory capacity, etc.) than usual to operate.

  JPIP is known as a protocol for accessing only a necessary part of a code data file encoded with JPEG2000 on a network in a fragmentary manner and is currently being formulated. However, JPIP is an abbreviation for JPEG2000 image coding system-Part 9: Interactivity tools, APIs and protocols.

  In addition, an image distribution system including a server and a client using JPIP is known.

  Patent Document 1 discloses a system that transmits and receives partial data of image data encoded by JPEG2000 using a server and a client. In this configuration, the client determines which part of the codestream stored in the server is already stored in the client's buffer, and requests the server for the portion of compressed data that is not yet stored in the buffer. The unit of data requested by the client can be selected from, for example, packets, tiles, and code blocks in the JPEG2000 code, or can be requested in byte units. On the other hand, the server extracts the partial data of the requested compressed data and returns it to the client. The client integrates the received data and the data already stored in the buffer for decoding, and acquires an image.

Patent Document 2 discloses a technique for displaying JPEG2000 code data stored on the server side in a progressive manner on the client side. In this configuration, the client issues a request specifying the desired resolution level and sends it to the server. The server extracts subband code data of the resolution level designated by the client from the stored image file and transmits it to the client. The client restores the image data based on the decoded subband coefficient of the resolution level of the displayed image and the subband coefficient obtained by decoding the code data received from the server. Thus, progressive display in the resolution direction can be performed.
JP 2003-023630 A JP 2004-040673 A

  In the configuration for transmitting and receiving the hierarchically encoded image data as described above, in order to perform data transmission efficiently, the code data received once by the client is cached, and only the code data of the unreceived portion is stored. To request to the server. However, in order to realize such a configuration, the client needs to have a large-capacity storage device.

  For example, in the configuration as described above, when all the image data can be displayed without requesting addition on the client side, all the compressed image data stored in the server is transmitted to the client side. That is, in such a case, it means that the client side has a cache capacity equal to or larger than that of the compressed image data file stored in the server.

  In addition, when converting cache data into JPEG2000 code data, it is necessary to create / manage two types of data: cache data and code data. For this reason, the client side requires a memory or file capacity that is at least twice the size of the compressed image file stored in the server.

  The size of the image data will be described with a specific example. Here, when the image size of the compressed image file in the server is very large, for example, when the image size is 10240 × 10240 pixels × 3 colors, the image data in the uncompressed state is 300 Mbytes. In the case of 102400 × 102400 pixels × 3 colors, it is 30000 Mbytes, that is, about 30 Gbytes. If this is compressed to 1/20, the former is 15 Mbytes and the latter is 1500 Mbytes.

  Such data with a large data size may be processable if the client device is realized by a personal computer (PC, personal computer). However, in the case of a device such as a small PC, PDA, portable terminal, etc., in many cases, it cannot be dealt with by limiting the CPU performance in addition to the limitation of the storage device such as memory capacity or file capacity.

  Even when the client is realized by a normal PC, if the image communication process is performed in parallel with other various processes, hardware resources allocated to the image communication are limited, and a large amount of image data Processing can be difficult in practice. Further, even in a normal PC, it is not easy to create a temporary file or a file exceeding 1 Gbyte as a memory, and it is extremely difficult to secure an area of this capacity on the memory.

  Further, it is possible to stop the JPEG2000 decoding operation halfway without caching the received code data, add differential code data, and continue decoding. However, in such a configuration, it is necessary to hold a DWT coefficient that is an intermediate result of the calculation. Even when each pixel is 8 bits, this DWT coefficient is 16 bits or more, and is 32 bits in a normal implementation. Therefore, holding this DWT coefficient requires a memory capacity larger than holding the decoded image data. That is, it means that a much larger memory capacity is required than when the code data is cached.

  Since the configuration disclosed in Patent Document 1 is premised on caching on the client side, it requires a cache capacity equal to or greater than the number of bytes of the requested compressed image data file. Therefore, if the requested compressed image data file size is larger than the client's capability, the client may not be able to continue processing.

  In the configuration disclosed in Patent Document 2, the decoding process is stopped halfway and the DWT coefficient used in the decoding process is held. For this reason, a large-capacity memory for holding the DWT count is required as compared with the case of holding the code data. Also, a special decoder is required to stop the decoding operation halfway or add subband data.

  Furthermore, the file size of the requested image data cannot be obtained from the current JPIP request / response data format. For this reason, the file size or the like cannot be checked before requesting code data on the client side.

  As described above, in the conventional configuration in which image data encoded hierarchically is transmitted and received, the hardware requirements required for the client device are very high. This problem is particularly noticeable when the image data size is large.

  The present invention has been made in view of the above problems, and an object of the present invention is to provide a technique for reducing hardware requirements required on the data receiving side in a configuration for transmitting and receiving hierarchically encoded image data. .

In order to achieve the above object, a server apparatus according to the present invention comprises the following arrangement. That is,
Storage means for storing image data composed of one or more packets for each resolution level;
Receiving means for receiving, from an external device, a transmission request including at least the designation of the resolution level of the image data, and capacity information relating to the storable capacity of the external device;
Determining means for determining whether or not to execute a predetermined process on the image data based on a comparison between the size of the image data and the capacity information;
When the determination means determines to execute the process, the packet included in the specified resolution level and the resolution level lower than the specified resolution level is added to the return data, and is not included in the resolution level. Generation means for executing processing for generating return data by replacing the packet with a packet indicating that the length is 0 and adding the packet to the return data;
Sending means for sending the generated return data to the external device.

  ADVANTAGE OF THE INVENTION According to this invention, the technique which reduces the hardware requirement requested | required by the data receiving side in the structure which transmits / receives the image data encoded hierarchically can be provided.

  Embodiments according to the present invention will be described below in detail with reference to the accompanying drawings. However, the constituent elements described in this embodiment are merely examples, and are not intended to limit the scope of the present invention only to them.

<< First Embodiment >>
(System configuration)
First, the configuration of the system in the present embodiment will be described with reference to FIG. FIG. 1 is a diagram showing a state in which a plurality of computers are connected on a network represented by the Internet.

  In FIG. 1, reference numeral 100 denotes a network represented by the Internet.

  Reference numeral 101 denotes a server computer (server) in which software necessary for functioning as a WWW server is installed. Such software includes, for example, a program for functioning as a JPIP server, which is a JPEG2000 communication protocol for transmitting image data. The server 101 is realized by an information processing apparatus such as a workstation (WS) or a personal computer (PC).

  Reference numeral 104 denotes an HD (Hard Disk) device for storing large-capacity image data, which stores compressed image data encoded by the JPEG2000 encoding method. The HD device 104 is communicably connected to the server 101.

  Reference numerals 102 and 103 denote client computers (hereinafter collectively referred to as the client 102). The client 102 is realized by, for example, a PC, WS, a mobile phone, a PHS, a personal digital assistant (PDA), or the like. The client 102 is installed with software such as a Web browser necessary for browsing a Web page, software for decoding / displaying JPEG2000 encoded data, and software implementing a JPIP client function. .

(Configuration of information processing device)
Next, the configuration of the server 101 will be described with reference to FIG. FIG. 2 is a block diagram illustrating a hardware configuration of the server 101.

  A CPU (Central Processing Unit) 201 controls the entire system. A keyboard 202 is used together with the mouse 201a for the user to input information and the like to the system.

  A display unit 203 includes a CRT (Cathode Ray Tube) or a liquid crystal display. Reference numeral 204 denotes a ROM (Read Only Memory), and 205 denotes a RAM (Random Access Memory), which constitutes a storage device of the system and stores programs executed by the system and data used by the system.

  Reference numeral 206 denotes a hard disk device, and 207 denotes a floppy (registered trademark) disk device, which constitutes an external storage device used for the file system of the system.

  Reference numeral 208 denotes a printer. Reference numeral 209 denotes a part for controlling the network, and communicates with an external device such as the client 102 connected on the network such as the Internet.

  In the present embodiment, the client 102 is assumed to have the hardware configuration shown in FIG.

(JPEG2000 encoded data)
Next, an outline of general JPEG2000 encoded data will be described with reference to FIG. FIG. 3 is a schematic diagram of JPEG2000 encoded data.

  As shown in FIG. 3, JPEG2000 encoded data is composed of head Main Header data 301 and one or more tile data.

  The main header data 301 describes information about the coding conditions of the entire image, such as the number of resolution levels and the number of layers.

  Each tile data includes a tile part header (Tile Header) 302 and encoded data 306. The tile part header 302 is header data describing information including tile coding conditions.

  The encoded data 306 following the tile part header 302 is composed of encoded unit data called one or more packets (packets) 303. As shown in FIG. 3, the packet 303 includes a packet header (packet header) 304 and a packet body (packet body, packet data) 305. The packet header 304 stores information including the encoding condition of the packet. Such information includes, for example, the presence / absence of a code block, 0-bit plane information, the number of encoding passes, the compressed data length of the code block, and the like. The packet data (packet body) 305 stores compressed data of code blocks present in the packet.

  FIG. 3 exemplifies a JPEG2000 file in which packet data is recorded in accordance with Layer-Resolution level-Component-Position progression (LRCP). As shown in FIG. 3, in the case of conforming to LRCP, encoded data is configured in a nested manner in the order of Layer / Resolution / Component / Position. Such an arrangement order of data is called a Progression Order. In addition to the LRCP, the Progression Order includes a code order such as SNR Progression, for example. In this embodiment, in order to simplify the description, the JPEG 2000 encoded data of Resolution Progression will be described as an example. Note that “Position (position)” described here is Precinct in JPEG2000 encoded data.

  When Progression Order is LRCP as shown in FIG. 3, data is stored in each layer in ascending order of Resolution (resolution) number. For this reason, LRCP is also called Resolution Progression. The layer number corresponds to the S / N ratio with respect to the original image of the image to be restored. The smaller the layer number, the worse the S / N ratio. The maximum values of resolution number, layer number, and component number in one JPEG2000 file are preset by the encoder and encoded according to the parameters, and the information is stored in the encoded data. Yes.

  Next, the relationship between resolution and subband will be described with reference to FIG. FIG. 4 is a diagram schematically showing the relationship between the resolution and subbands when decomposition level (division level) = 4.

In FIG. 4, 401 to 405 are subbands having N _L (number of division levels) of 0 to 4, respectively. For example, by decoding the subband of LL (N _L = 0) 401, image data with a resolution level of 0 can be reproduced. Furthermore, an image having a resolution level of 1 can be reproduced by decoding three subbands of HL (N _L = 1) 402a, LH (N _L = 1) 402b, and HH (N _L = 1) 402c. . Similarly, by decoding up to N _L = 2 to 4 subbands, it is possible to reproduce images with resolution levels of 2 to 4, respectively. In this manner, image data having a desired resolution level can be acquired based on the resolution level to be reproduced and data (packets) included in the resolution level lower than the resolution level.

  As shown in FIG. 4, in the JPEG2000 encoding method, every time the resolution level number is increased by 1, the image size of the reproduced image data is doubled in both width and height. In the case of Resolution Progression shown in FIG. 3, the code data of one resolution level is arranged so that the layer number is in ascending order, the component number is in ascending order, and the position number is in ascending order. The layer number here corresponds to the S / N ratio with respect to the original image of the image to be restored. The smaller the layer number, the worse the S / N ratio, that is, the lower resolution image data is reproduced.

(JPIP communication)
Next, an outline of communication when sending JPEG2000 encoded data stored in the server 101 (the HD device 104 connected to the server 101) to the client 102 will be described with reference to FIG. FIG. 5 is a conceptual diagram showing a correspondence between a request (request) and a response (response) related to image data.

  In the configuration according to the present embodiment, communication of image data (code data) is performed using JPIP. As a result, the client 102 can acquire not only all of the compressed image data but only the necessary portion of data.

  As a unit of data received by the client 102, a JPEG2000 packet or a tile unit which is an encoding unit larger than the packet can be considered. Here, a case where the unit of data to be transmitted / received is a packet unit will be described as an example. FIG. 5 shows a request and response when the unit of data to be transmitted / received is a packet unit.

  The client 102 requests data from the server 101 by specifying information such as an image tile number, resolution level, layer, component, and position number. Upon receiving the request 501, the server 101 analyzes the code stream of the image 503 and extracts packet data corresponding to the specified tile number, resolution level and layer, component, and position number. Then, a response 502 including these pieces of information is sent back to the client 102.

  Next, the structure of response data when data is transmitted and received using JPIP as packet data transmission units will be described with reference to FIGS. 6 and 7. FIG.

  FIG. 6 is a schematic diagram of the structure of the precinct data-bin. In JPIP, as shown by 601 in FIG. 6, response data (Response Data) is created based on a block of JPEG2000 packet data called “precinct data-bin”. The precinct data-bin is a block of data in which the packets of all layers that make up the resolution level rn of the precinct number pn and the component number cn in the tile number tn are arranged in an ascending order. is there.

  FIG. 7 shows an example of JPIP Response Data created using Packet (tn, rn, cn, pn, 1) extracted from the precinct data-bin shown in FIG. FIG. 7 is a diagram illustrating an example of JPIP Response Data. Here, Packet (tn, rn, cn, pn, qn) indicates a packet with the resolution level of the tile tn, rn, the component number cn, the position number pn, and the layer number qn. The response data includes a message header 701 and a message body 703. The message header and message body are collectively called JPIP message. A JPIP message created from precinct data-bin is called a precinct data-bin message. A JPIP message created from the main header is called a main header data-bin message.

  The message body 703 of the precinct data-bin message stores JPEG2000 encoded data cut out from the precinct data-bin 601. For example, when JPIP Response Data is created by extracting Packet (tn, rn, cn, pn, 1) 603 in FIG. 6, Packet (tn, rn, cn, pn, 1) 603 is stored in the message body 703 .

  The message header 701 is composed of four parameters. That is, the first parameter stores an identifier indicating whether or not the data contained in the message body 703 is a precinct data-bin.

The second parameter stores a precinct data-bin ID (PrID). This is a parameter uniquely determined from the tile number tn, the resolution level number rn, the component number cn, and the precinct number pn by the following equation.
PrID (tn, rn, cn, pn) = tn + (cn + s x (number of components)) x number of tiles
s = pn + tn × (number of precincts per tile at resolution level rn)
+ (Total number of precincts of tile tn from resolution level 0 to (rn-1)).

  The third parameter is an offset value PrOffset 602 in the response data-precinct data-bin. In other words, the data contained in the message body 703 is a value indicating from which byte the data in the precinct data-bin 601 of PrID (tn, rn, cn, pn) is the value of 602 in FIG. equal.

  The fourth parameter of the message header 701 is the byte length of Response Data (response data), that is, the byte length of the message body 703. That is, the value of ResLen [byte] 704 is stored in ResLen 702.

(Examples of conditions)
Next, various conditions regarding image data encoding conditions and client 102 specifications assumed in the system according to the present embodiment will be described. The following conditions are taken as an example for convenience of description, and embodiments according to the present invention are not limited to these conditions.

  The compressed image data stored in the server 101 has a file name “a.jp2” and is encoded using the JPEG2000 encoding method under the following conditions.

[Encoding condition]
File name: a.jp2
Image size: 65536 × 65536 pixels Tile size: 512 × 512 pixels Number of tiles: (65536/512) × (65536/512) = 128 × 128 = 16384 Colors: 1
Number of layers: 1
Number of resolution levels: 9 (0 to 8)
Resolution level 8 image size: 65536 × 65536 pixels Resolution level 7 image size: 32768 × 32768 pixels Resolution level 6 image size: 16384 × 16384 pixels Resolution level 5 image size: 8192 × 8182 pixels Resolution level 4 image size : 4096 × 4096 pixels Resolution level 3 image size: 2048 × 2048 pixels Resolution level 2 image size: 1024 × 1024 pixels Resolution level 1 image size: 512 × 512 pixels Resolution level 0 image size: 256 × 256 pixels Data size of image at the time of compression: 65536 × 65536 = 4096 Mbytes File size: 512 Mbytes (when compressed to 1/8).

  Further, it is assumed that the free capacity of the storage device provided in the client 102 is smaller than the size of the image data. The data size of the file “a.jp2” is 512 Mbytes at the time of compression, but the free capacity of the storage device of the client 102 is, for example, 256 Mbytes. However, the free capacity of the storage device is, for example, the total free capacity of the RAM 205, the hard disk 206, and the like.

  The client 102 caches fragmented code data received by JPIP, and requests the server 101 for code data not in the cache when a new image display instruction is input from the user. The cache data needs information for managing the received code data, and should be managed in a format that allows easy processing such as addition and deletion of code data. For this reason, it is often managed in a format different from the format of JPEG2000 code data.

  Also in the configuration according to the present embodiment, the cache data on the client 102 is managed in a format different from the JPEG2000 code data. Therefore, in order to decode the code data by the JPEG2000 decoder, it is necessary to convert the code data managed in this cache format into a JPEG2000-compliant code data format.

  When such a cache mechanism is provided, the client 102 has both an area for managing cache data and an area for managing JPEG2000 code data on the storage device in consideration of a temporary file generated at the time of conversion. Need to be. This means that the storage capacity required by the client 102 is twice the number of bytes of the JPEG2000 file stored in the server 101. For example, when the file size on the server 101 is 512 Mbytes, the free capacity of the storage device necessary for the client 102 is, for example, about 1024 Mbytes. Therefore, when the free capacity of the storage device of the client 102 is 256 Mbytes, all cache files cannot be created, and JPEG2000 code data cannot be created from the cache.

  The configuration according to the present embodiment enables the client 102 to decode and display image data even in the above environment. Hereinafter, the operation of the server 101 when the server 101 transmits the file “a.jp2” to the client 102 using JPIP and the client 102 performs decoding / display, etc. will be described.

(Overall processing)
In this embodiment, when the server 101 receives a request for transmission of image data of a certain resolution from the client 102, the server 101 replaces all of the code data of a part not necessary for decoding the image of that resolution with a packet having a length of 0. To the client 102. A packet having a length of 0 is called “Zero Length Packet” and is hereinafter referred to as ZLP.

Hereinafter, a case where the client 102 sends a request to the server 101 to display a level 1 resolution, that is, an image of 512 × 512 pixels will be described as an example. At this time, the content of the request issued by the client 102 is, for example, the following JPIP command description.
http://www.image.com/JPIP.cgi?target=a.jp2&fsize=512,512&type=jpp-stream
Hereinafter, this command is referred to as JPIP command 1.

  Next, the flow of overall processing executed by the server 101 will be described with reference to FIG. FIG. 8 is a flowchart showing the overall flow of the server 101 process.

  First, in step S800, in response to reception of a communication request from the client 102, processing for opening a session with the client 102 is performed.

  Next, in step S801, the client 102 is inquired of the code file maximum capacity (hereinafter referred to as BS), for example, in units of bytes, and the value is acquired. This is done, for example, by sending a packet for inquiring about the BS to the client 102 and receiving and analyzing the response.

Corresponding to step S801, when the client 102 manages two types of file groups of cache data and code data as described above, the size that can secure half the value of the storage capacity on the client 102 side as code data Return as. In the case of this embodiment, since the capacity of the temporary file is 256 Mbytes, the capacity that can be used as the code data is a half of 128 Mbytes.
In step S 802, the JPIP command is received from the client 102.

  Next, in step S803, the JPIP command received in step S802 is analyzed. Specifically, information such as the requested image file and resolution level is acquired.

  Next, in step S804, based on the command analysis result in step S803, code data necessary for return is cut out from the requested file, and return code data generation processing for generating return code data is performed. Details of this processing will be described later.

  In step S805, the return data created in step S804 is transmitted to the client 102.

  Next, in step S806, it is determined whether or not to end the current session. This determination is made based on, for example, whether or not a predetermined time has elapsed since the last packet was received from the client 102, whether or not a session end packet has been received from the client 102, and the like.

  If it is determined not to end the session (NO in step S806), the process returns to step S802, and the processes in steps S802 to S805 are repeated. On the other hand, if it is determined to end the session (YES in step S806), the process proceeds to step S807.

  In step S806, processing for closing the session with the client 102 is performed. For example, processing such as releasing an object temporarily created for communication with the client 102 from the memory is performed. Then, the process in the server 101 is terminated.

(Return code data creation process)
Next, with reference to FIG. 9, the detailed flow of return code data creation executed in step S804 will be described. FIG. 9 is a flowchart showing the flow of return code data creation processing.

  First, in step S900, the number of bytes of the target file requested this time is acquired with reference to the analysis result in step S803. Then, the size of the code data maximum capacity BS on the client 102 side acquired in step S801 is compared with the requested number of bytes of the target file.

  As a result of this comparison, if the BS value is equal to or greater than the number of bytes of the target file (NO in step S904), the process proceeds to step S904, and based on the command analysis result in step S803, return data is created by normal processing. Perform the process. Thereafter, in step S905, a JPIP header for the return data created in step S904 is created. Since these processes are well-known, detailed description is omitted. After the process of step S905, the server 101 ends the return code data creation process, and proceeds to step S805 of FIG.

  On the other hand, if the value BS is smaller than the file size in step S900 (YES in step S904), the process proceeds to step S901.

  In step S901, the client 102 determines that all the target files of this time are not capable of caching, and performs processing for generating cacheless data so that the client 102 can perform processing without cache. Details of this processing will be described later in detail with reference to FIG.

  In step S902, a return JPIP header for cashless data created in step S901 is generated. Specifically, the server 101 creates a response header in which the type parameter is changed to “type = RAW” or “type = jp2”. For example, in the present embodiment, the client 102 requests “jpp-stream” as in the above-described JPIP command 1, but changes it to “type = RAW” or “type = jp2”. The client 102 that has received the JPIP response header can determine that the received data is directly processed by the JPEG2000 decoder without caching, by referring to the JPIP response header.

  After the processing in step S902, the server 101 ends the return code data creation processing, and proceeds to step S805 in FIG.

(Cashless data creation process)
Next, with reference to FIG. 10, the cacheless data creation process executed in step S901 of FIG. 9 will be described. FIG. 10 is a flowchart showing the flow of the cacheless data creation process executed in the return code data creation process.

  First, in step S1000, the main header of the JPEG2000 code data of the target file is read and analyzed, and information such as encoding conditions is acquired.

  In step S1001, it is determined which packet in the target file corresponds to the code data requested by the JPIP command analyzed in step S803, and the packet to be returned is specified. Since this specific processing is known as a known technique, a detailed description thereof is omitted. For example, in the case of the above-mentioned JPIP command, packets constituting all tiles up to resolution level 1 are specified as packets to be returned.

  In step S1002, the header of the target file is added to the reply data as it is.

  Next, in steps S1003-1 to S1007-5, a packet necessary for decoding an image with the requested resolution level is added to the return data, and other packets are replaced with ZLP.

  In order to perform such processing for all the packets forming the image data, first, in step S1003-1 to step S1003-5, processing for initializing a parameter variable for specifying a packet to be referred to is performed. That is, first, in step S1003-1, a variable T for specifying a tile is initialized to a value 0. In step S1003-2, a variable L for specifying a layer is initialized with a value 0. In step S1003-3, a variable R for specifying the resolution level is initialized to a value 0. In step S1003-4, a variable C for specifying a component (Component) is initialized with a value 0. Next, in step S1003-5, a variable P for specifying a position (Position) is initialized to a value 0.

  In step S1005, it is determined whether the packet identified by each of the variables (T, L, R, C, P) corresponds to the packet specified in step S1001 (that is, a return packet). .

  If the packet does not correspond to a return packet (NO in step S1005), the process proceeds to step S1008 to perform processing for replacing the packet identified by each variable (T, L, R, C, P) with ZLP. On the other hand, if it is determined in step S1005 that the packet is a return packet (YES in step S1005), the process proceeds to step S1006, and the packet identified by each variable (T, L, R, C, P) is included in the return data. to add. When the processes of steps S1008 and S1006 are completed, the process proceeds to step S1007-1.

  From step S1007-1 to step S1007-5, each variable is incremented, and it is determined whether or not the process has been completed.

  That is, in step S1007-1, the variable P is incremented, that is, incremented by one. At this time, it is determined whether or not step S1005 and subsequent processing have been performed for all positions in the component identified by the variable C. When the process is performed (YES in step S1007-1), the process proceeds to step S1007-2. When the process is not performed (NO in step S1007-1), the process returns to step S1005 and the process is repeated.

  In step S1007-2, the variable C is incremented, that is, incremented by one. At this time, it is determined whether or not step S1005 and subsequent processing have been performed for all components in the image data at the resolution level identified by the variable R. When the process is performed (YES in step S1007-2), the process proceeds to step S1007-3. If the process has not been performed (NO in step S1007-2), the process returns to step S1003-5 and the process is repeated.

  In step S1007-3, the variable R is incremented, that is, incremented by one. Then, at this time, it is determined whether or not step S1005 and subsequent processing have been performed for all the resolution level image data in the layer identified by the variable L. When the process is performed (YES in step S1007-3), the process proceeds to step S1007-4. If the process has not been performed (NO in step S1007-3), the process returns to step S1003-4 and the process is repeated.

  In step S1007-4, the variable L is incremented, that is, incremented by one. At this point, it is determined whether or not step S1005 and the subsequent processing have been performed for all layers in the tile identified by the variable T. When the process is performed (YES in step S1007-4), the process proceeds to step S1009. If the process has not been performed (NO in step S1007-4), the process returns to step S1003-3, and the process is repeated.

  In step S1009, the tile part header at the head of each tile is adjusted. That is, the tile part header includes a part describing the total packet length constituting the tile part, but the description of the packet length is corrected in accordance with the length of the tile part that has changed due to the replacement with the ZLP. Then, the process proceeds to step S1007-5.

  In step S1007-5, the variable T is incremented, that is, incremented by one. Then, it is determined whether or not step S1005 and subsequent processing have been performed for all tiles in the image data. If the process has been performed (YES in step S1007-5), the cacheless data creation process ends, and the process proceeds to step S902 in FIG. If the process has not been performed (NO in step S1007-5), the process returns to step S1003-2 and the process is repeated.

  With the above processing, it is possible to create JPEG2000 code data as return data in which packets constituting all tiles of the requested resolution level are included, and packets that are not requested are replaced with ZLP. For example, in the above example, return data in which all packets constituting resolution level 0 to resolution level 1 are added and other packets are replaced with ZLP can be created.

  In this case, the client 102 can display the image by decoding the code data received from the server 101 as it is without performing caching. In the case of the present embodiment, only unnecessary portions of the packet are replaced with ZLP, and re-encoding is not performed. Therefore, there is no image quality degradation at the requested portion. Furthermore, the processing of the server 101 basically only replaces unnecessary portions of the packet with the ZLP, so that the processing load required for the server 101 is relatively small.

<< Second Embodiment >>
In the first embodiment, a configuration has been described in which a packet in an unnecessary portion is replaced with a ZLP without changing the main header. In the present embodiment, a description will be given of a configuration in which return data that includes only requested code data, that is, even ZLP is not included in the return data. In the configuration of the present embodiment, processing for appropriately changing the main header is performed so that the return data is composed only of the requested code data.

  The configuration according to the present embodiment is the same as the configuration according to the first embodiment unless otherwise specified, and only differences in configuration and processing will be described. The overall processing and return code data creation processing executed by the configuration according to this embodiment are the same as those in the first embodiment, and the processing shown in the flowcharts of FIGS.

  The cacheless data creation process executed by the configuration according to the present embodiment will be described with reference to FIG. FIG. 11 is a flowchart showing the flow of the cacheless data creation process executed by the configuration according to the present embodiment.

  In FIG. 11, the same number is attached | subjected about the part which performs the same operation | movement as the flow demonstrated in FIG. 10, and description is abbreviate | omitted. The difference from the first embodiment is that when it is determined in step S1005 that the packet is not a return packet (NO in step S1005), step S1100 is executed instead of step S1002.

  If it is determined in step S1005 that the packet is not a return packet (NO in step S1005), in the case of this embodiment, only the requested packet is returned. Therefore, if only the operation proceeds to step S1006 without any processing. Good.

  In step S1100, processing for changing the main header of the code data from the results of steps S803 and S1001 is executed. The change of the main header will be described with reference to FIGS. FIG. 12 is a diagram schematically showing the configuration of the marker segment of the main header 301.

  As shown in FIG. 12, the main header 301 includes an SOC marker, SIZ marker segment 1201, COD 1202, QCD, and POC as essential marker segments. Other markers in FIG. 12 are optional and may be inserted based on the encoding option.

  In step S1100, the corresponding fields in the SIZ marker segment 1201 and the COD marker segment 1202 in the main header shown in FIG. 12 are changed.

  The SIZ marker segment 1201 describes information such as the image size of the image data, the vertical and horizontal length of the reference grid, the vertical and horizontal length of the tile, and the number of components. FIG. 13 is a diagram schematically showing a detailed configuration of the SIZ marker segment. In FIG. 13, “Xsiz” 1301 and “Ysiz” 1302 are fields for entering the image size of the image data. In step S1100, these two fields are changed. No other fields need to be changed.

  The COD marker segment 1202 describes the number of division levels, encoding style, layering information, and the like. FIG. 14 is a diagram schematically showing the detailed configuration of the COD marker segment.

  In this figure, “Number of decomposition levels” 1401 is a field in which the number of layers in the resolution direction is entered. In step S1100, this value is changed as appropriate. The other fields of the COD marker segment need not be changed.

  For example, in the case of the image data exemplified above, the values set in each field are as follows. That is, “512” is set in the Xsiz field 1301 and “512” is set in the Ysiz field 1302 in the SIZ marker segment. Then, “1” is set in the “Number of decomposition levels” field 1401 in the COD marker segment. In step S1100, after setting the value in this way, it is output as a new main header.

  The client 102 that has received the code data analyzes the main header and identifies it as code data having an image size of 512 × 512 and a layer number of 1. Then, the image data is decoded based on the identification result. Since the data following the main header is arranged in accordance with the identification result, the client 102 can decode and display the image data.

  Even in this embodiment, since the code data is not re-encoded, there is no deterioration in image quality. Further, since the return data generated by the configuration according to the present embodiment is configured only from the packet requested by the client 102 and does not include the ZLP, the size of the return data is further reduced as compared with the configuration of the first embodiment. can do.

  Further, the processing of the server 101 basically adds only a necessary part of the packet to the return data and changes only the fixed field in the main header, and the processing load required for the server 101 is relatively small.

<< Third Embodiment >>
In the return data generated in the configurations according to the first and second embodiments, the hierarchy in the resolution direction remains. This is because the packet data of a necessary part for decoding the requested image data is basically composed of return data with the structure stored in the server 101.

  The configuration according to the present embodiment re-encodes the portion of the image data requested from the client 102 and returns it in the structure of only the lowest resolution data, that is, the format of only the LL subband. In other words, the packet included in the designated resolution level and the resolution level lower than the designated resolution level is synthesized, and processing for generating image data of the designated resolution level is executed to generate return data.

  Also in the configuration according to the present embodiment, the main header and the like are changed so that the return data is only the code data requested from the client 102, as in the second embodiment. Further, the JPIP command from the client 102 is the same as the one shown in the first embodiment (JPIP command 1) as in the second embodiment.

  The configuration according to the present embodiment is the same as the configuration according to the first embodiment unless otherwise specified, and only differences in configuration and processing will be described. The overall processing and return code data creation processing executed by the configuration according to this embodiment are the same as those in the second embodiment, and the processing shown in the flowcharts of FIGS.

  FIG. 15 is a flowchart showing the flow of the cacheless data creation process executed by the configuration according to the present embodiment. In FIG. 15, the same numbers are assigned to portions that perform the same operation as the flow described in FIG. 11.

  First, in step S1000, as in the first and second embodiments, the main header of the JPEG2000 code data of the target file is read and analyzed, and information such as the encoding condition is acquired.

  Next, in step S1500, based on the main header of the target file analyzed in step S1000 and the analysis result in step S803, the portion of the target file that needs to be decoded to acquire the requested image data is specified. More specifically, information such as a hierarchy in the resolution direction that needs to be decoded and tiles including the requested image data area is acquired. In the example of the JPIP command taken up in the first embodiment, the tiles to be decoded are all tiles, and the number of layers in the resolution direction to be decoded is one.

  Next, in steps S1501 and S1502, a process of generating image data of a designated resolution level by combining packets included in the designated resolution level and a resolution level lower than the designated resolution level is executed.

  In step S1501, the target file is decoded based on the parameters specified in step S1500, and image data is acquired.

  In step S1502, the image data obtained in step S1501 is encoded in the LL subband only format. That is, encoding is performed under the encoding conditions of “no tile division”, “the image size is the size of the tile boundary including the requested area”, and “there is no number of layers in the resolution direction”. And it is set as the code data (return data) which returns the data acquired by encoding.

  At the time of encoding, encoding is performed by setting the encoding parameters so that the parameters in the main header are appropriately modified according to the characteristics of the return data. For example, in the above-described example, “512” is set in the Xsiz field 1301 in the SIZ marker segment 1201, “512” is set in the Ysiz field 1302, “512” is set in the XTsiz field, and “512” is set in the YTsiz field. Set. Thereby, the image data requested from the client 102 can be created as code data re-encoded with the LL subband.

  In the case of this embodiment, the decoding processing target on the client 102 side is code data that includes only the LL subband and does not have tile division. For this reason, the client 102 can execute the decoding process at high speed. Also, since the encoding process executed by the server 101 is only for the LL subband, it can be executed at high speed.

  As described above, in the configuration of the embodiment according to the present invention, the return of the “RAW” or “JP2” mode depends on the performance of the computer on the client 102 side, particularly the capacity of the storage device that can be created as a temporary file. Create data. Specifically, if the storage capacity of the client 102 cannot secure the file size of the target file or more (specifically, the number of bytes more than twice), the “RAW” is always used regardless of the return image type specified in the JPIP command. "Or return in" JP2 "mode. As a result, the client 102 does not need to cache data, and can directly decode and display the code data received from the server 101. As a result, processing on the client 102 side can be reduced.

  On the other hand, the load related to the processing on the server 101 side is also small as described above. For this reason, even if the processing on the server 101 side slightly increases, the embodiment according to the present invention is more preferable than the conventional configuration in which the client 102 side decodes and displays the JPEG2000 code data after reconstructing it from the cache data. The throughput of this configuration is better. That is, it is possible to shorten the time from when the client 102 issues a request to the server 101 to when the client 102 communicates and displays the result.

  Further, according to the configuration of the embodiment of the present invention, it is possible to reduce the load related to the decoding of the client 102, so that the client 102 having a low computing capability such as CPU performance also decodes and displays the image data at high speed. be able to.

  In particular, when converting to code data of only the LL subband on the server 101 side, the decoding time on the client 102 side can be significantly shortened compared to the case of hierarchical decoding. For example, in an application that performs thumbnail display, it is necessary to display the entire image at high speed. In such an application, it is particularly effective to provide code data of only LL subbands that are not divided into tiles.

<< Other Embodiments >>
The exemplary embodiments of the present invention have been described in detail above. However, the present invention can take embodiments as, for example, a system, apparatus, method, program, or storage medium. Specifically, the present invention may be applied to a system composed of a plurality of devices, or may be applied to an apparatus composed of a single device.

  The present invention can also be achieved by supplying a program that realizes the functions of the above-described embodiment directly or remotely to a system or apparatus, and the computer of the system or apparatus reads and executes the supplied program code. Including the case where it is achieved.

  Therefore, since the functions of the present invention are implemented by a computer, the program code installed in the computer is also included in the technical scope of the present invention. That is, the present invention includes a computer program itself for realizing the functional processing of the present invention.

  In that case, as long as it has the function of a program, it may be in the form of object code, a program executed by an interpreter, script data supplied to the OS, or the like.

  Examples of the recording medium for supplying the program include the following. Namely, floppy (registered trademark) disk, hard disk, optical disk, magneto-optical disk, MO, CD-ROM, CD-R, CD-RW, magnetic tape, nonvolatile memory card, ROM, DVD (DVD-ROM, DVD-) R) and the like are included.

  In addition, the following types of programs may be considered. That is, it is also possible to connect to a homepage on the Internet using a browser of a client device and download a computer program according to the present invention or a compressed file including an automatic installation function from the homepage to a recording medium such as an HD. It can also be realized by dividing the program code constituting the program of the present invention into a plurality of files and downloading each file from a different homepage. That is, a WWW server that allows a plurality of users to download a program file for realizing the functional processing of the present invention on a computer is also included in the present invention.

  The following supply forms are also conceivable. That is, first, the program according to the present invention is encrypted, stored in a storage medium such as a CD-ROM, and distributed to users. Further, the present invention allows a user who has cleared a predetermined condition to download key information to be decrypted from a homepage via the Internet, execute a program encrypted by using the key information, and install the program on a computer. The structure which concerns on is implement | achieved. Such a supply form is also possible.

  In addition, the following realization modes in which the functions of the above-described embodiments are realized by the computer executing the read program are also assumed. In other words, based on the instructions of the program, the OS running on the computer performs part or all of the actual processing, and the functions of the above-described embodiments can be realized by the processing.

  Furthermore, after the program read from the recording medium is written in the memory provided in the function expansion board inserted into the computer or the function expansion unit connected to the computer, the program of the above-described embodiment is also based on the instructions of the program. Function is realized. That is, the CPU of the function expansion board or function expansion unit performs part or all of the actual processing, and the functions of the above-described embodiments are realized by the processing.

It is the figure which showed a mode that the some computer was connected on the network. It is the block diagram which showed the hardware constitutions of the server. It is the schematic of the encoding data of JPEG2000. It is the figure which showed typically the relationship between resolution and a subband. It is the conceptual diagram which showed the response | compatibility with the request which concerns on image data, and a response. It is the schematic of the structure of precinct data-bin. It is the figure which showed an example of JPIP Response Data. It is the flowchart which showed the flow of the whole server process. It is the flowchart which showed the flow of return code data creation processing. It is the flowchart which showed the flow of the cashless data creation process in 1st Embodiment. It is the flowchart which showed the flow of the cashless data creation process in 2nd Embodiment. It is the figure which showed typically the structure of the marker segment of a main header. It is the figure which showed typically the detailed structure of the SIZ marker segment. It is the figure which showed typically the detailed structure of the COD marker segment. It is the flowchart which showed the flow of the cashless data creation process in 3rd Embodiment.

Claims (9)

Storage means for storing image data composed of one or more packets for each resolution level;
Receiving means for receiving, from an external device, a transmission request including at least the designation of the resolution level of the image data, and capacity information relating to the storable capacity of the external device;
Determining means for determining whether to execute a predetermined process on the image data based on a comparison between the size of the image data and the capacity information;
When the determination means determines to execute the process, the packet included in the specified resolution level and the resolution level lower than the specified resolution level is added to the return data, and is not included in the resolution level. Generation means for executing processing for generating return data by replacing the packet with a packet indicating that the length is 0 and adding the packet to the return data;
Sending means for sending the generated return data to the external device. Storage means for storing image data composed of one or more packets for each resolution level;
Receiving means for receiving, from an external device, a transmission request including at least the designation of the resolution level of the image data, and capacity information relating to the storable capacity of the external device;
Determining means for determining whether to execute a predetermined process on the image data based on a comparison between the size of the image data and the capacity information;
When the determination means determines to execute the process, return data is generated by adding the packet included in the specified resolution level and the resolution level lower than the specified resolution level to the return data. Generating means for executing processing;
Sending means for sending the generated return data to the external device. Storage means for storing image data composed of one or more packets for each resolution level;
Receiving means for receiving, from an external device, a transmission request including at least the designation of the resolution level of the image data, and capacity information relating to the storable capacity of the external device;
Determining means for determining whether to execute a predetermined process on the image data based on a comparison between the size of the image data and the capacity information;
When the determination means determines to execute the process, the packets included in the specified resolution level and the resolution level lower than the specified resolution level are combined to generate image data of the specified resolution level. Generating means for executing processing for generating
Sending means for sending the generated return data to the external device.   The server apparatus according to claim 1, wherein the image data composed of the plurality of layers is encoded data based on a JPEG2000 system.   5. The server device according to claim 1, wherein the receiving unit and the sending unit communicate with the external device based on JPIP.   6. The server apparatus according to claim 5, wherein a data format of the return data sent by the sending means is a JPIP RAW or jp2 format. A control method for a server device comprising storage means for storing image data composed of one or more packets for each resolution level,
A receiving step of receiving from the external device a transmission request including at least the specification of the resolution level of the image data, and capacity information relating to the storable capacity of the external device;
A determination step for determining whether or not to execute a predetermined process on the image data based on a comparison between the size of the image data and the capacity information;
If it is determined to execute the process in the determining step, the packet included in the designated resolution level and the resolution level lower than the designated resolution level is added to the return data, and is not included in the resolution level. A generation step of executing processing for generating return data by replacing the packet with a packet indicating that the length is 0 and adding the packet to the return data;
And a sending step for sending the generated return data to the external device.   A computer program for causing a computer to function as the server device according to claim 1.   A computer-readable storage medium storing the computer program according to claim 8.

Images