JP4776489B2 - Image encoding device, image decoding device, image encoding program, image decoding program, image encoding method, and image decoding method - Google Patents

Description

  The present invention relates to a technique for processing image data. In particular, the present invention relates to a technique capable of encoding and decoding with high efficiency with a small storage capacity and calculation amount.

  In small electronic devices such as mobile phones and electronic dictionaries, characters can generally be displayed on a liquid crystal screen. When displaying characters on the liquid crystal screen, an optimum character font corresponding to the screen characteristics is prepared in advance, thereby realizing a clearer and more readable character display.

  Here, when all the various characters are stored accurately, for example, bitmap image data needs to be compressed by lossless encoding in order to minimize the storage capacity in a small device. Further, in order to cope with the processing speed of screen display, it is necessary to decode the encoded data at high speed.

  A technique for compressing the capacity of image data by encoding image data expressed as electronic data has been studied for a long time.

  As lossless encoding, for example, Non-Patent Document 1 shows encoding by the Huffman method. In Huffman coding, variable length coding is performed according to a Huffman dictionary such that the greater the frequency, the shorter the code length, based on the appearance frequency of the encoded data.

As a technique for decoding encoded data at high speed, for example, Patent Document 1 discloses a technique related to image decoding. According to this technique, the original image data is divided into blocks, and information for managing the storage address of the head data of each block is stored in the storage device. As a result, it is possible to reduce processing time and transfer data amount in remote search.
Japanese Patent Laid-Open No. 3-164980 “Introduction to Document Data Compression Algorithm”, Tomohiko Uematsu, CQ Publishing Co. (1994), pages 46-64

  However, since the Huffman code described in Non-Patent Document 1 is a variable-length code, when decoding an arbitrary position or an arbitrary area of the original data, it is necessary to decode sequentially from the data at the head address of the encoded data. is there. For this reason, the decoding process tends to take time.

  Further, according to the technique described in Patent Document 1, an apparatus that manages the storage address of the head data for each block has an advantage that the processing time at the time of arbitrary access is short, but it retains a table for address management. Requires storage capacity.

  Further, when variable-length encoded data is randomly accessed by a device having a small processing capacity and storage capacity such as a mobile device, it is necessary to achieve both reduction in processing amount and reduction in storage capacity.

  The present invention has been made to solve the above-described problems, and an object of the present invention is to provide an apparatus capable of encoding and decoding image data with low storage capacity and calculation amount with high efficiency. That is.

According to one aspect of the present invention, the image encoding device is an image encoding device that generates code data from a character image in which a plurality of characters are continuous, and performs processing for each sub-block data having a predetermined read size. It reads a character image of interest, and encoding means for variable-length coding to be encoded data for each sub-block data, and manages the processing status of the sub block data composed of a predetermined number of block data A block data management means for managing processing on block data corresponding to a character image for one character, and a unit for managing processing on block data and managing processing on unit data composed of a predetermined number of block data a to update the data management unit, the access pointer for accessing a position corresponding to the unit data in the encoded data Seth pointer updating means includes an access pointer outputting means for outputting the access pointer, and a code length calculation means for calculating a code length of the variable length coded data for each sub-block data, the access pointer updating unit code The access pointer is updated by adding the code length of the variable-length encoded data for each sub-block data corresponding to the unit data, calculated by the length calculation means, and the access pointer output means for each block data And an access pointer is output in response to detecting completion of encoding for each unit data.

  Preferably, the access pointer update unit updates the access pointer by setting the data size obtained by calculating the data size of the entire encoded data already encoded by the encoding processing unit as a new access pointer.

  Preferably, storage means for storing the access pointer and the code data in association with each other is further provided.

Preferably, the coding processed by the coding processing means is Huffman coding.
Preferably, when the access pointer output means detects the completion of encoding for each block data and for each unit data, the sub-block data processed by the encoding processing means corresponds to one predetermined position within the block size. And detecting that the block data corresponds to one predetermined position in the unit size.

  Preferably, one position where the sub-block data should fall within the block size is the head position within the block size.

  Preferably, one position where the block data should fall within the unit size is a head position within the unit size.

  Preferably, the position where the sub block data should fall within the block size is the head position within the block size, and the position where the block data should fall within the unit size is within the unit size. Is the start position.

  Preferably, the image encoding device includes variable length code dictionary storage means for storing a variable length code dictionary that is referred to when performing variable length encoding processing.

  Preferably, the variable length code dictionary is a Huffman dictionary generated according to the appearance frequency of the sub-block data.

  Preferably, the image encoding device calculates a data capacity of the entire encoded code data, a code data size calculating means, an access pointer data size calculating means for calculating a data capacity of the entire output access pointer, Unit size setting means is further provided for setting a predetermined unit size using the calculated code data size and the calculated access pointer data size.

  Preferably, the unit size setting means sets a predetermined processing start unit size at the start of processing of the image encoding device, and the access pointer data size calculation means calculates all the sub-block data to be encoded. Each time the access pointer generation process is completed, the access pointer data size is calculated, and the unit size setting means calculates the calculated access pointer data size, the encoded data size, and all the sub-block data to be encoded. If the original data size, which is the data capacity, satisfies a predetermined condition, the image encoding process is terminated, and if the predetermined condition is not satisfied, the unit size is updated according to a predetermined rule.

  Preferably, the predetermined unit size for starting processing set by the unit size setting unit at the start of processing is “1”, and the unit size setting unit follows when the unit size is updated. The predetermined condition to be followed when the unit size setting means decides whether to end the image encoding process or to update the unit size is to add “1”. The original data size is OSSize, and the code data size is When CSize, the access pointer data size is TSize, and the overhead coefficient is Wgt, the condition is that (CSize + TSSize) / OSSize ≦ (CSize / OSSize) × Wgt is satisfied.

  Preferably, the overhead coefficient Wgt is a value larger than “1.0” and smaller than “2.0”.

  Preferably, the image encoding device includes a frequency calculation unit that calculates an appearance frequency for each block data in all of the sub-block data to be encoded, and an encoding target according to the appearance frequency calculated by the frequency calculation unit. And a block data rearranging unit that rearranges the order of all the sub-block data in units of blocks.

  Preferably, the block data rearranging means rearranges the data having the higher appearance frequency calculated by the frequency calculating means so that the lower appearance frequency is located rearward.

  Preferably, the unit data management means manages the processing status of the block data and updates the predetermined unit size according to a predetermined rule every time processing of unit data defined by the predetermined unit size is completed.

  Preferably, the rule for updating the predetermined unit size is to add “1” to the current unit size.

According to another aspect of the present invention, the image decoding apparatus is an image decoding apparatus that decodes code data obtained by encoding a character image composed of a plurality of characters, and is block data corresponding to a character image for one character. Block data information acquisition means for acquiring information for designating, and block data is composed of a predetermined number of sub-block data, which is the read size in the image encoding device, and unit data is composed of a predetermined number of block data An access pointer storage means for storing an access pointer obtained by adding a code length for each variable length encoded sub-block data as an access pointer for accessing a position corresponding to predetermined unit data of the code data When, a to the unit data including the block data corresponding to the acquisition block data information A unit data access pointer calculating means for calculating an access pointer with reference to an access pointer stored in the access pointer storing means, and information on a position in the unit data where the block data corresponding to the acquired block data information is included. Block data position information calculating means for calculating, decoding means for sequentially decoding the encoded data in block data units from the start position according to the calculated unit data access pointer, and decoded data output means for outputting the decoded data The decoded data output means responds to detecting that the processing status of the decoded block data composed of the set of decoded sub-block data decoded by the decoding means corresponds to the designated block data. Outputs decoded data To.

  Preferably, the decoding processed by the image decoding apparatus is decoding of code data subjected to variable length encoding.

  Preferably, the decoding processed by the image decoding device is Huffman decoding for Huffman-coded code data.

  Preferably, the unit data access pointer calculation means uses the unit data access pointer as UnIdx, information specifying one block data as GlNum, predetermined unit size as USIZE, Int (A / B), integer A as integer B When the quotient at the time of division is used, the unit data access pointer is calculated according to the formula UnIdx = Int (GlNum / USIZE).

  Preferably, the unit data block data position information calculating means is BIdx for block data position information in unit data, GlNum for specifying one block data, USIZE for a predetermined unit size, and Rem (A / B). When the integer A is divided by the integer B as the remainder, the block data position information in the unit data is calculated according to the formula of BlIdx = Rem (GlNum / USIZE).

  Preferably, when detecting that the decoded data corresponds to the designated block data, the block position information in the unit of the decoded block data sequentially decoded from the start position according to the unit data access pointer is calculated as the block position information in the unit data. It is to detect that it corresponds to the block position information in the unit data calculated by the means.

  Preferably, the image decoding apparatus ends the decoding process when the predetermined condition is not satisfied after outputting the decoded data while the predetermined condition is satisfied.

  Preferably, the image decoding apparatus further includes variable length code dictionary storage means for storing a variable length code dictionary which is referred to when decoding variable length code data.

  Preferably, the variable length code dictionary is a Huffman dictionary generated according to the appearance frequency of the sub-block data.

  Preferably, the unit data access pointer calculating means has a unit data access pointer of UnIdx, information specifying one block data is GlNum, and SQRT (A) is a positive square root of an integer A. The unit data access pointer is calculated by calculating an integer that satisfies 3 + SQRT (8 × GlNum + 9)) / 2 and UnIdx ≦ (−1 + SQRT (8 × GlNum + 1)) / 2.

  Preferably, the unit data block data position information calculating means is configured such that BIdx = GlNum− when the block data position information in unit data is BIdx, the information specifying one block data is GlNum, and the unit data access pointer is UnIdx. The block data position information in the unit data is calculated according to the formula of UnIdx × (UnIdx + 1) / 2.

According to yet another aspect of the present invention, an image encoding program is a program for executing the image encoding processing for generating the code data from the character image a plurality characters on a computer having an arithmetic unit is continuous, the program for calculating unit, for each sub-block data is a predetermined reading size read a character image to be processed, the steps of variable length coding to be encoded data for each sub-block data, the sub block data manages the processing status, which is composed of a predetermined number of sub-block data, manages the steps of managing the processing for block data corresponding to one character character image, the processing status of the block data, a predetermined number a step of managing the processing of for unit data composed of block data, variable length marks for each sub-block data Calculating the code length of the encoded data, and adding the code length of the calculated variable-length encoded data for each sub-block data corresponding to the unit data, The step of updating the access pointer for accessing the position corresponding to the step and the step of outputting the access pointer is executed, and the step of outputting the access pointer detects completion of encoding for each block data and for each unit data. In response to this, an access pointer is output.

According to still another aspect of the present invention, the image decoding program is a program for causing a computer having a calculation unit to execute an image decoding process for decoding code data obtained by encoding a character image including a plurality of characters . The program obtains information specifying block data corresponding to a character image for one character from the arithmetic unit, and the arithmetic unit uses a code for each code data as an access pointer for accessing the code data. The step of storing the access pointer obtained by adding the length, and the block data are constituted by a predetermined number of sub-block data that is the read size in the image encoding device, and the unit data is composed of a predetermined number of block data. configured, access for accessing the position corresponding to the predetermined unit data of the code data As inter, variable-length coding sub-blocks and storing access pointer obtained by adding the code length of each data, access pointer to the unit data including the block data corresponding to the obtained block data information and a step of calculating by referring to the stored access pointer, in the units data, calculating information about the position that contains the corresponding block data to the obtained block data information, the sign-data, calculates a step of sequentially decoded in block data units from the starting position according to the unit data access pointer, to execute the steps of outputting the decoded data decrypt, step of outputting the decoded data is decoded in the decoded block data Decoding block consisting of sets Processing status over others, in response to detecting that correspond to the block data decoded data is designated, and outputs the decoded data.

According to still another aspect of the present invention, the image encoding method is an image encoding method for generating code data from a character image in which a plurality of characters are continuous, and for each sub-block data having a predetermined read size, reads a character image to be processed, the steps of variable length coding to be encoded data for each sub-block data, and manages the processing status of the sub block data composed of a predetermined number of sub-block data, 1 A step of managing processing for block data corresponding to character images of characters, a step of managing processing status of block data and managing processing of unit data composed of a predetermined number of block data, and sub-block data Calculating the code length of the variable-length encoded data for each, and sub-blocks corresponding to unit data By addition of each over data, the code length of the variable length coded data is calculated, and updating the access pointer for accessing a position corresponding to the unit data in the encoded data, the access pointer output And the step of outputting the access pointer is characterized by outputting the access pointer in response to detecting completion of encoding for each block data and for each unit data.

According to still another aspect of the present invention, the image decoding method is an image decoding method for decoding code data obtained by encoding a character image composed of a plurality of characters, and is a block corresponding to a character image for one character. The step of acquiring information specifying data, and the block data are constituted by a predetermined number of sub-block data, which is the read size in the image encoding device, and unit data is constituted by a predetermined number of block data. as access pointer for accessing a position corresponding to the predetermined unit data, and storing the access pointer obtained by adding the code length of each variable length coded subblock data, acquisition block The access pointer to the unit data containing the block data corresponding to the data information is stored The step of calculating with reference to the access pointer, the step of calculating information on the position where the block data corresponding to the acquired block data information is included in the unit data, and the code data according to the calculated unit data access pointer A step of sequentially decoding in block data units from the start position and a step of outputting the decoded data, wherein the step of outputting the decoded data includes the step of decoding the decoded block data composed of a set of decoded decoded sub-block data The decoded data is output in response to detecting that the processing status corresponds to the designated block data.

  According to the present invention, image data can be encoded and decoded with high efficiency with a small storage capacity and calculation amount.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. In the following description, the same parts are denoted by the same reference numerals. Their names and functions are also the same. Therefore, detailed description thereof will not be repeated.

  The image encoding device and the image decoding device according to the present embodiment may be realized by a computer such as a personal computer as an information processing device, or mounted in a portable device as a text processing device. It may be. In the present embodiment, it is assumed that the image encoding apparatus is mounted on a personal computer (hereinafter abbreviated as a PC) as an information processing apparatus. Further, the image decoding device is assumed to be mounted on a mobile phone as an example of a mobile device as a text processing device. Other specific examples of the text processing device include PDAs (Personal Digital Assistants), portable game devices, and home appliances equipped with display devices.

[First Embodiment]
FIG. 66 is a diagram illustrating a specific example of the hardware configuration of the PC 3 as the information processing apparatus on which the image encoding device according to the present embodiment is mounted, and illustrates a specific example of the general hardware configuration of the PC. It is a block diagram.

  Referring to FIG. 66, the PC 3 is a CPU 101 for controlling the entire apparatus, a ROM 103, a RAM 105, a hard disk drive 107, a flexible disk drive (FDD), a CD-ROM (Compact Disk-Read Only Memory). ) A reading unit 109 that reads information from the recording medium 2 such as a drive, an input unit 111 configured by a keyboard, a mouse, and the like, a communication unit 113 for communicating with the outside, and a display unit 115 are configured.

  The image encoding apparatus according to the present embodiment is configured by hardware of the PC 3 and software that is stored in a storage unit such as the ROM 103 and executed by the CPU 101. A function for performing an image encoding process to be described later is the CPU 101. Is mainly formed in the CPU 101 by reading and executing a program stored in a storage unit such as the ROM 103. Alternatively, at least a part of the above functions may be configured by the hardware of the PC 3 shown in FIG.

  FIG. 2 is a block diagram illustrating a specific example of a functional configuration for functioning as an image encoding device in the PC 3 according to the present embodiment and performing image encoding processing. The image encoding device according to the first embodiment encodes a sequence of character image data corresponding to different character codes using a difference between lines for each sequence of words.

  Referring to FIG. 2, the above-described functions of the image encoding device include a controller 1201, an image data memory 1202, a processed divided image data memory 1203, an entropy encoding unit 1204, an encoded data memory 1205, an access table data generation unit 1206, An access table data memory 1207, a character identification information / glyph number correspondence rule memory 1208, and an image processing unit 1209 are configured, and each component is connected to each other and the outside via a data bus 1210.

  FIG. 3 is a block diagram illustrating a specific example of the configuration of the image processing unit 1209. Referring to FIG. 3, image processing unit 1209 includes an image calculation unit 3801, a character image data memory 3802, a divided character image data memory 3803, and a processed divided character image data memory 3804. Each component is a data They are connected to each other and the outside via a bus 3805.

  Further, FIG. 4 is a block diagram showing a specific example of the configuration of the access table data generation unit 1206. Referring to FIG. 4, access table data generation unit 1206 includes a character identification information / glyph number conversion data generation unit 2201 and a glyph number / offset information conversion data generation unit 2202, and each component is a data bus. They are connected to each other and to the outside through 2203.

  The image data memory 1202 includes a predetermined area of a storage unit such as the ROM 103, and image data acquired by an acquisition unit (not shown) is input (loaded) to the image data memory 1202. The acquisition unit is not limited to a specific means in the present invention, and examples include a reading unit 109 that reads data from a recording medium such as a CD-ROM, and a communication unit 113 that receives data transmitted from another device.

  Here, a word is used as a unit for reading data into the memory. A word or a multiple of a word and the size of image data (hereinafter referred to as character image data) constituting one character may not match. Therefore, for example, when character image data for one character is read in two words, the boundary between words (word boundary) does not coincide with the center of the character in the data written in the memory. This will be specifically described with reference to FIG. In FIG. 5 and the following embodiments, it is assumed that words are arranged in the horizontal direction. The number of vertical and horizontal dots in the character image data is assumed to be constant. However, in the present invention, the size of the image data to be processed and the size of the character data are not limited to a specific size, and in the following example, the word size is 8 bits as one specific example. The size of the character image data constituting one character is 11 dots in both vertical and horizontal dots (hereinafter, sometimes referred to as 11 × 11 font). Then, as shown in FIG. 5, it is assumed that individual character data is stored as a binary image of 2 bytes wide and 11 dots long by offsetting 1 dot to the left. In the following, it is assumed that the image line starts from 0 when counting. Therefore, the first line is “0th line”. FIG. 5 shows a specific example of character image data 101 which is a binary image having a size of 11 dots × 11 dots. The character image data 101 for one character shown in FIG. 5 is composed of 16 bits × 11 lines corresponding to two words, and characters on the left side are always 11 bits × 11 dots at least 1 bit apart. Represented. Depending on the shape of the character, there may be little or no dot (hereinafter “black dot”) constituting the character in the character image data constituting one character. Here, the leftmost dot is assumed to be MSB (Most Significant Bit) as the byte value of the binary image. In the following description, black dots are set to 1 and other dots are set to 0. For example, in the case of data 102 in FIG. 12 described later, the value of the 0th line is 0X02 in hexadecimal.

  FIG. 6 is a diagram illustrating a specific example of image data that is a binary image stored in the image data memory 1202. It is assumed that the image data stored in the image data memory 1202 is image data formed by connecting a plurality of character image data constituting one character in the vertical direction as shown in FIG.

  The character identification information / glyph number correspondence rule memory 1208 includes a predetermined area of a storage unit such as the ROM 103, and stores character identification information / glyph number correspondence rules indicating correspondence between character identification information and glyph numbers, which will be described later.

  Character identification information indicates information for identifying a character, and specifically indicates a character code, a typeface, and the like. The glyph number indicates information specifying character image data stored in the image data memory 1202, and specifically indicates a number starting from 0 added to each character image data stored in the image data memory 1202. In the following description, the glyph number is also the order in which each character image data is encoded. Here, “glyph” is used to mean a character shape represented by a character image.

  The character identification information / glyph number correspondence rule specifies the correspondence between each character image data stored in the image data memory 1202 and the character identification information. Specifically, as shown in FIG. 10 is a table showing correspondences between character codes as identification information, typeface identification information as character identification information, and glyph numbers that specify character image data stored in the image data memory 1202. In the following specific examples, the character identification information is a 2-byte shift JIS code and 1-bit typeface designation information (Gothic type is represented by 0 and Mincho type is represented by 1). In this specific example, it is assumed that characters having different font sizes have different encoded data. Therefore, the font size is not included in the character identification information.

  As specified in the table shown in FIG. 7, even if the character code is the same, if the typeface is different, it may correspond to a different glyph. Alternatively, different character codes may correspond to the same glyph.

  The character image data memory 3802, the divided character image data memory 3803, and the processed divided character image data memory 3804 of the image processing unit 1209 are configured by predetermined areas of a storage unit such as the ROM 103.

  Character image data for one character is read from the image data stored in the image data memory 1202 by the image calculation unit 3801 and stored in the character image data memory 3802. The character image data stored in the character image data memory 3802 is divided in the vertical direction at the byte boundary in the horizontal direction by the image calculation unit 3801 and stored in the divided character image data memory 3803 as “divided character image data”. . Since images are generally arranged in raster order, when they are divided at byte boundaries, the addresses are discontinuous in character image data, and the addresses adjacent in the vertical direction are continuous on one divided character image data. Will come to do.

  In the present invention, the character image data dividing method is not limited to a specific method, and the above method is one specific example. The division method is preferably a method that considers the dot configuration of the character image data as in the above specific example. By dividing the character image data by such a dividing method, the distribution can be concentrated on a specific value in encoding as will be described later.

  Further, since the division method in the present embodiment is divided in units of bytes (8 bits), the CPU can easily perform processing in units of normal bytes. Of course, a specific example of this division method is based on the premise that the byte arrangement on the image is arranged with the bits constituting the byte in the horizontal direction. Therefore, if this premise is different, the dividing method is preferably a dividing method that can be easily processed by the CPU, instead of the dividing method of this specific example.

  For the divided character image data stored in the divided character image data memory 3803, an exclusive OR is calculated in the image calculation unit 3801, and the calculation result is stored in the processed divided character image data memory 3804 as “processed divided character image data”. Is done.

  Here, as is widely known, exclusive OR is an operation that sets 0 when two bits match and 1 when they do not match. Here, since each character is closed, the first line uses the 0th line extracted from the divided character image data as the input data without using the exclusive OR.

Therefore, if the exclusive OR of A and B is represented by the symbol “^”,
For n = 0,
(Nth line of processed divided character image data) = (nth line of divided character image data)
For n ≧ 1,
(Nth line of processed divided character image data) = ((n-1) th line of divided character image data) ^ (nth line of divided character image data)
It becomes.

  In this way, the 0th line of the divided character image data is copied to the processed divided image data as it is, and the exclusive OR is calculated for the remaining lines, so that it is necessary to decode other characters when decoding one character. Each character can be decoded independently.

  Here, an exclusive OR between adjacent lines is used as a method for obtaining a difference, but this method is, of course, a specific example, and the present invention is not limited to a specific method. The method of obtaining the difference may not be exclusive OR as long as the conversion increases the frequency of a specific value without losing the original information (without losing reversibility). Depending on the contents, an exclusive OR between distant lines may be used instead of adjacent lines. In particular, the latter can be used to increase the frequency of a specific value (for example, to increase the bias in the distribution of values) (for example, when it is known that a line with similar contents appears periodically). It is effective if possible.

  The processed divided image data memory 1203 includes a predetermined area of a storage unit such as the ROM 103. The processed divided character image data stored in the processed divided character image data memory 3804 is output to the processed divided image data memory 1203 by the image calculation unit 3801 and stored therein.

  The encoded data memory 1205 includes a predetermined area of a storage unit such as the ROM 103. The processed divided image stored in the processed divided image data memory 1203 is entropy encoded by the entropy encoding unit 1204 and stored in the encoded data memory 1205 as “encoded data”.

  Note that the encoding method in the entropy encoding unit 1204 is not limited to a specific method in the present invention, and any known technique may be employed. Specific examples of the encoding method include fixed Huffman encoding (hereinafter simply referred to as “Huffman encoding”), arithmetic encoding, and the like. The image encoding apparatus according to the present embodiment performs Huffman encoding. Shall be. The advantage of Huffman coding is that the amount of calculation for decoding is small. Further, it is preferable that the unit for performing entropy encoding is not the processed divided character image data but the processed divided image data larger than the character unit. In general, if the range encoded as a lump of data (in the case of Huffman encoding, the range of data encoded by sharing a Huffman table (Huffman dictionary)) is character image data, the overhead is relative to the total amount of data. This is because it tends to be large. Here, the overhead means a necessary data amount other than the code corresponding to the original data. For example, if Huffman coding is employed, the amount of data in the Huffman table corresponds to overhead. Needless to say, when an encoding method in which the overhead is sufficiently small with respect to the total amount of data is adopted, the range encoded as a lump of data may be processed divided character image data.

  The access table data memory 1207 is configured with a predetermined area of a storage unit such as the ROM 103. The access table data generation unit 1206 generates access table data for accessing the encoded data stored in the encoded data memory 1205 and stores it in the access table data memory 1207.

  The access table data defines the correspondence between the character identification information and information indicating where the character specified by the character identification information corresponds to the code from where to where on the encoded data (this information is referred to as offset information). And is stored together with the encoded data. The access table data is used in the decryption process described later. As a specific example, as shown in FIG. 8, the access table data includes character identification information in a glyph number indicating the number of glyphs in the encoded data (hereinafter referred to as the 0th glyph). The data includes character identification information / glyph number conversion data 1401 for conversion and glyph number / offset information conversion data 1402 for converting the glyph number into offset information.

  In general, in encoding for reducing the data capacity, the encoded data length differs even for image data having the same data length. Therefore, the data position on the encoded data corresponding to the data corresponding to each character cannot be obtained from the glyph number by simple calculation, and offset information is required.

  More specifically, the character identification information / glyph number conversion data generation unit 2201 of the access table data generation unit 1206 acquires an internal character code based on the character identification information (note that “acquisition” here is calculated) The same applies hereinafter). The internal character code refers to a value indicating which character code in the image encoding device is the character specified by the character identification information in order to improve data access efficiency. Here, even if the character code is the same, the internal character code is different if the typeface designation information is different.

  The glyph number / offset information conversion data generation unit 2202 of the access table data generation unit 1206 generates glyph number / offset information conversion data and writes it into the access table data memory 1207. The glyph number / offset information conversion data refers to a value representing the correspondence between the glyph number and the offset information on the encoded data for finding the code data corresponding to each glyph from the glyph number.

  FIG. 9 is a flowchart showing an encoding process in the image encoding apparatus according to the present embodiment. The processing shown in the flowchart of FIG. 9 is realized by the control unit 120 reading and executing a program stored in the storage unit such as the ROM 103, and the controller 1201 controlling each unit shown in FIG.

  Referring to FIG. 9, first, image data is input (loaded) to image data memory 1202 by controller 1201 (step S1301). Here, the following description will be made assuming that the image data (11 × 11 font) shown in FIG. 6 is loaded as a specific example. Further, the controller 1201 inputs (loads) the aforementioned character identification information / glyph number correspondence rule to the character identification information / glyph number correspondence rule memory 1208 (step S1302). Here, the following description will be given on the assumption that the character identification information / glyph number correspondence rule shown in FIG. 7 is loaded as a specific example.

  The image calculation unit 3801 of the controller 1201 obtains divided character image data by dividing the character image data extracted from the image data stored in the image data memory 1203 in step S1301 in the vertical direction by the horizontal byte boundary (step S1301). S1303). From the divided character image data obtained in step S1303, an exclusive OR is calculated in the image processing unit 1209, and the calculation result is stored in the processed divided image data memory 1203 as processed divided character image data (step S1304). The processed divided image data and the processed divided image data memory 1203 already store processed divided character image data corresponding to the character image data that has already been processed. In step S1303, the processed divided character image data is added to the end of the already stored processed divided character image data and stored in the processed divided image data memory 1203. “Processed divided image data” refers to the processed divided character image data stored in this manner, and there are as many character image data as the number of characters image data divided in step S1303. Therefore, when the image data shown in FIG. 6 is loaded, two processed divided image data exist. FIG. 67 and FIG. 68 show specific examples before and after the addition of one character of processed divided character image data in step S1304, where two characters of processed divided character image data have already been stored. FIG. As described above, there are two pieces of processed divided image data corresponding to the division of character image data into two in step S1303. However, one piece of processed divided image data is processed for the other processed divided image data. FIGS. 69 and 70 show specific examples before and after the character image data is added.

  If all the characters included in the image data loaded in step S1301 have been processed (YES in step S1305), the process proceeds to step S1306. If not processed (NO in step S1305), the process returns to step S1302. .

  In step S <b> 1306, the entropy encoding unit 1204 performs entropy encoding processing on the processed divided image data stored in the processed divided image data memory 1203 and stores the encoded data in the encoded data memory 1205.

  If processing has been completed for all the processed divided image data obtained from the image data loaded in step S1301 (YES in step S1307), the process proceeds to step S1308; otherwise (in step S1307). NO), the process returns to step S1306.

  In step S 1308, the access table data generation unit 1206 generates access table data for accessing the encoded data stored in the encoded data memory 1205, and stores it in the access table data memory 1207.

  The encoded data stored in the encoded data memory 1205 is output from the image encoding apparatus by the controller 1201 as the encoding result of the image data (step S1309). Further, the access table data stored in the access table data memory 1207 is also output from the image encoding apparatus together with the encoded data (step S1310), and the process ends.

  FIG. 10 is a flowchart showing the image data dividing process in step S1303.

  Referring to FIG. 10, first, image calculation unit 3801 reads character image data for one character from the image data loaded in image data memory 1202 in step S1301, and stores it in character image data memory 3802 (see FIG. 10). Step S3901).

  When the image data loaded in the image data memory 1202 is the image data shown in FIG. 6, in step S3901, the character image data shown in FIGS. 3802.

  Next, the image calculation unit 3801 divides the character image data stored in the character image data memory 3802 in the vertical direction, stores the divided character image data in the divided character image data memory 3803 (step S3902), and performs processing. The process proceeds to step S1304.

  Specifically, the character image data obtained in step S3901 is the character image data obtained by dividing the loaded image data shown in FIG. 11A, that is, the diagram described above. In the case of the data 101 shown in FIG. 5, the divided character image data becomes the data 102 shown in FIG. 12 and the data 103 shown in FIG. 13 by being divided by the image calculation unit 3801 in step S3902. In the case of the character image data having the configuration shown in FIG. 5, no value is entered in the leftmost bit. Therefore, as shown in FIGS. 12 and 13, the divided character image data is divided in such a direction. The left-side data 102 and the right-side data 103 differ greatly in the distribution of the values of the individual bytes comprising the dots included in the horizontal line constituting the image.

  As for the byte value of the data 103 in FIG. 13, since the characters are arranged as described above, the lower 4 bits always have a value of 0. That is, there are only 16 types of byte values of the data 103 at the maximum. Therefore, dividing the character image data in the vertical direction in the image calculation unit 3801 contributes to the improvement of the encoding efficiency.

  FIG. 14 shows an example of character image data having a size of 23 dots × 23 dots. Here, the left byte 201 has an MSB of 0 at all times, and therefore there are only 128 types of byte values. Absent. That is, since the left byte 201 has a different value distribution from the central byte 202 and the right byte 203, dividing the character image data in the vertical direction in the image calculation unit 3801 contributes to improving the coding efficiency.

  It is particularly preferable to divide the character image data in the vertical direction, particularly when the characters are arranged on the character image data according to the word (byte) boundary (boundary) as in the above specific example. is there. A specific example of image data that is not so is shown in FIG. On the image data shown in FIG. 15, character image data is arranged across the word boundaries 701 and 702. However, even in such a case, it is possible to convert the character so that it does not cross the word boundary by an appropriate bit operation (shift or the like).

  FIG. 16 is a flowchart showing the exclusive OR calculation process in step S1304.

  Referring to FIG. 16, first, image operation unit 3801 calculates an exclusive OR for the divided character image data stored in divided character image data memory 3803 in step S3901, and processes the processed divided character image data. The divided character image data memory 3804 is stored (step S4001). Specifically, when the exclusive OR of the divided character image data 102 shown in FIG. 12 is calculated, the processed divided character image data 601 shown in FIG. 17 is obtained. Then, the image calculation unit 3801 outputs the processed divided character image data stored in the processed divided character image data memory 3804 to the processed divided image data memory 1203 (step S4002).

  If the process of calculating the exclusive OR for all the divided character image data obtained from the image data loaded in step S1301 has been completed (YES in step S4003), the process is terminated and the process proceeds to step S1305. . Otherwise (NO in step S4003), the process returns to step S4001.

  The access table generation processing in step S1308 will be described with reference to the flowchart of FIG.

  The simplest configuration of the character identification information / glyph number conversion data 1401 included in the access table is a configuration that defines a correspondence between a character code and a glyph number. However, when the character identification information / glyph number conversion data 1401 has such a configuration, the data size of the character identification information / glyph number conversion data 1401 is (number of characters) × (bit length necessary to store the character code). Since efficient encoding cannot be achieved, the following configuration is preferable.

Now assume the following:
(Assumption 1) Character identification information and glyphs are not necessarily associated one-to-one, and one glyph may be associated with a plurality of codes.
(Assumption 2) There may be character identification information not associated with glyphs.
(Assumption 3) The majority of glyphs are associated with the character identification information on a one-to-one basis.
(Assumption 4) The character codes are locally continuous.
(Assumption 5) The glyph data is arranged in ascending order (from smallest to largest) of the corresponding internal character codes (described later). However, when there are a plurality of corresponding internal character codes, the smallest one is taken.

  The above (Assumption 1) is the case where font data is displayed on the target display device even though it can be distinguished by the character identification information (character code) such as the Greek letter “L” and the Latin alphabet “P”. This is an assumption in consideration of the possibility that the encoded data can be reduced by using the common glyph data when it cannot be distinguished as glyphs.

  The above (Assumption 2) assumes the case where there is no glyph depending on the size (for example, complex characters that exist only at a specific size, that is, complex characters that cannot be displayed without a certain size) Applicable to shape characters).

  The above (Assumption 3) is an assumption that most character identification information is associated with glyph data on a one-to-one basis even under the assumptions of (Assumption 1) and (Assumption 2).

  The above (Assumption 4) is an assumption that the character codes are not all discontinuous, as is typically seen in the shift JIS code, but the characters are associated with continuous codes. This assumption indicates that a character code and typeface identification information can be easily converted into an internal character code with a relatively small number of conditional expressions, as will be described later.

  The above (Assumption 5) is a condition that is satisfied if configured in such a manner, and is intended to make it easy to create access table data that can be accessed at high speed by encoding, which will be described later. The example of the character identification information / glyph number correspondence rule shown in FIG. 7 also satisfies this assumption.

  Based on the above assumptions, in this embodiment, it is assumed that the character identification information / glyph number conversion data 1401 has the configuration shown in FIG. That is, referring to FIG. 19, the character identification information / glyph number conversion data 1401 includes a status table 1501, a first auxiliary table 1502, and a second auxiliary table 1503.

  Referring to FIG. 18, when generating access table data, first, the character identification information / glyph number conversion data generation unit 2201 acquires an internal character code for the target character based on the character identification information ( Step S2301). Here, the specific correspondence between the character code as the character identification information and the internal character code is the correspondence shown in FIG. In FIG. 20, for convenience of explanation, there are only six character codes of 0x8250 to 0x8251 and 0x8260 to 0x8262. In FIG. 20, it can be read that the above (Assumption 4) is established.

  As one specific example of the technique for converting a character code and typeface identification information into an internal character code by using some conditional statements, FIG. 21 shows a variable code indicating a character code and a variable type indicating typeface identification information. To C-language source code to be converted into a variable internal_code indicating the internal character code. The technique used in step S2301 is not limited to a specific technique. For example, an internal character code is obtained using a technique as shown in FIG.

  Next, the character identification information / glyph number conversion data generation unit 2201 generates a status table from the character identification information / glyph number correspondence rule stored in the character identification information / glyph number correspondence rule memory 1208 and the internal character code. The data is written in the access table data memory 1207 (step S2302).

When the character identification information / glyph number correspondence rule is as shown in FIG. 7, and the correspondence between the character code as the character identification information and the internal character code is as shown in FIG. 20, in step S2302, The status table shown in FIG. 22 is generated. The status table is a table indicating glyph allocation states corresponding to the internal character codes arranged in ascending order. Specifically, referring to FIG. 22, the status table 1501 includes the following three types. One of the values is specified for each internal character code:
0 ... No glyph is assigned to the internal character code,
1 ... There is only one character code corresponding to the glyph assigned to the internal character code, or there are two or more character codes, but the glyph appears in the status table 1501 for the first time.
2... There are two or more internal character codes corresponding to the glyphs assigned to the internal character code.

    In the status table shown in FIG. 22, 1 is given as a value to the internal character codes 3, 9, 4, 10, 5, and 11, and therefore, referring to FIG. A ”, Mincho“ A ”, Gothic“ B ”, Mincho“ B ”, Gothic“ C ”, and Mincho“ C ”have independent glyphs (in the internal character code). It can be seen that there is only one corresponding glyph). Further, since 2 is assigned to the internal character codes 6 and 8, it is indicated that a glyph common to other internal character codes is used. It cannot be determined from this table alone whether the glyph common to the internal character code is used. However, referring to FIGS. 7 and 20 together, the glyph common to the internal character codes 0 and 2 is used. You can see that Therefore, the value of the table corresponding to the internal character codes 0 and 2 is 1 because the above-mentioned “there are two or more character codes corresponding to the glyphs assigned to the internal character code but the status table This is the first time the glyph comes out at 1501 ". Further, since “0” is given to the internal character code 7, it is indicated that there is no Gothic “2” glyph.

  Next, the character identification information / glyph number conversion data generation unit 2201 generates a first auxiliary table and writes it in the access table data memory 1207 (step S2303). Here, the first auxiliary table is a table describing glyph numbers corresponding to some of the internal character codes. A specific example of the first auxiliary table 1502 in FIG. 19 is a table describing the correspondence between some of the internal character codes and glyph numbers shown in FIG. The first auxiliary table 1502 is a table used when decoding the encoded data, and how it is used will be described later.

  The configuration of the first auxiliary table 1502 will be described. When 1 is assigned to the value of the status table 1501, the number of such data has been checked so far, and the obtained result is the corresponding glyph number (because there is the above (Assumption 5)). .) The first auxiliary table stores the result of calculating the corresponding glyph number as described above for some of the internal character codes.

  In the first auxiliary table 1502 shown in FIG. 23, in order to make the access to the first auxiliary table more efficient, the correspondence between glyph numbers is described for internal character codes at equal intervals (as a specific example, in increments of 5). Needless to say, the intervals may be uneven. Even if the interval is shorter than the specific example, if the data size of the first auxiliary table is sufficiently small, there is a merit in improving access efficiency. Further, the countermeasure when “0” or “2” is defined in the status table 1501 for the internal character code to be described in the first auxiliary table is not limited to a specific countermeasure. What is necessary is just to use the internal character code | cord | chord which is an internal character code before the code | symbol and in which the effective value was prescribed | regulated.

  Also, instead of the status table 1501 shown in FIG. 22, the status table is configured in advance so that the glyph number is described as shown in FIG. 24, so that the first auxiliary table is generated in step S2303. It can be unnecessary. However, if the status table is configured as shown in FIG. 24, the amount of data is (the number of bits representing the glyph number) × (the number of characters in which “1” is defined in the status table). A status table is not preferable because it is added to the encoded data.

  Next, the character identification information / glyph number conversion data generation unit 2201 generates the second auxiliary table 1503 and writes it in the access table data memory 1207 (step S2304). Here, the second auxiliary table refers to an internal character code in which “2” is defined in the status table 1501, that is, an internal character code corresponding to an assigned glyph, with respect to the corresponding glyph. This is a table describing numbers. A specific example of the second auxiliary table 1503 in the case of the status table 1501 of FIG. 22 is the table shown in FIG. The second auxiliary table is a table used when decoding the encoded data, and specifically how to use will be described later. According to the above assumption (3), it is assumed that there are few internal character codes in which “2” is defined in the status table 1501, so that the corresponding glyph numbers for all the internal character codes in which “2” is defined are described. Even if the table is generated, it is considered that the coding efficiency is maintained.

  In the above specific example, the correspondence between the internal character code and the glyph number is described in the second auxiliary table 1503. However, as the access key, the character identification information is used instead of the internal character code. And the glyph number may be described. The same applies to the first auxiliary table 1502.

  The character identification information / glyph number conversion data generated by the character identification information / glyph number conversion data generation unit 2201 is one specific example, and the conversion data generated here is the character identification as described above. It is not limited to information / glyph number conversion data. The point here is whether the correspondence between the character identification information (or the internal character code uniquely determined therefrom) and the glyph number or glyph is one-to-one or not (or how many glyph numbers or glyphs are The number of glyph numbers or glyphs corresponding to the character identification information) is generated. Another important point is that the image decoding apparatus, which will be described later, refers to a different table according to the determination result for the generated data, thereby reducing the data capacity required for itself. Character identification information / glyph number conversion data is configured so that character identification information (or internal character code) can be converted to glyph numbers at high speed (glyph data is specified) while keeping small. Specifically, in the present embodiment, the first auxiliary table 1502 is referred to when the character identification information (internal character code) has a one-to-one correspondence with the glyph, and the second auxiliary table otherwise. The character identification information / glyph number conversion data generation unit 2201 generates character identification information / glyph number conversion data configured to be able to refer to 1503. Further, the first auxiliary table 1502 is a subset of a correspondence table between character identification information (or internal character codes) and glyph numbers.

  Next, the glyph number / offset information conversion data generation unit 2202 generates glyph number / offset information conversion data for each processed divided image data and writes it in the access table data memory 1207 (step S2305). The character identification information / offset information conversion data is not related to the division, but the glyph number / offset information conversion data indicating the offset in the encoded data accesses data corresponding to the number of encoded glyphs × the number of divisions. I have information.

  In the specific example of the above configuration, the glyph number / offset information conversion data is obtained by converting the position on the encoded data of the data corresponding to the encoded divided processed character data from the glyph number, thereby converting the character image data. The position on the encoded data is specified. More generally, it can be said that the glyph information / offset information conversion data is information for obtaining the position of the encoded character image data on the encoded data from the glyph number. In fact, if the encoded data is arranged for each part corresponding to each (encoded) character image data instead of each (encoded) processed divided image data, the glyph number / offset information conversion data Is information for directly obtaining the position on the encoded data of the character image character image data encoded from the glyph number. Here, although the creation method of the glyph number / offset information conversion data is not described in detail, for example, the encoded data corresponding to each division is searched from the beginning, and the position that becomes the boundary of the processed divided character image is offset. Since the information may be recorded, it is not limited to a specific method. Of course, it is also conceivable to devise a glyph number / offset information conversion data so that processing at the time of decoding can be performed at high speed.

  If the process has been completed for all the divided image data obtained from the image data loaded in step S1301 (YES in step S2306), the process proceeds to step S1309; otherwise (step S2306). In step S2307, the process moves to the next divided image data, and the process returns to step S2305.

  By performing the above-described processing in the image coding apparatus according to the present embodiment, a small amount of calculation is performed using the feature that data of similar size, which is found in character image data, is arranged at a fixed period. Highly efficient encoding can be performed in a quantity. That is, by dividing the character image data in the direction corresponding to the dot configuration of the character image data to be encoded, the distribution probability of the byte value is more reflected, and the encoding efficiency can be improved.

  Further, by adding the correspondence between the encoded data, the internal character code, and the character identification information to the encoded data as a small-size table, the image decoding apparatus described below can perform decoding with a small amount of calculation. .

  In the above description, each character image data is divided and encoded perpendicular to the line direction. However, the above method is one specific example of the present invention, and another specific example is as follows. There is also a method of creating “divided image data” by performing division perpendicular to the line direction, and then creating “processed divided image data” by taking the difference between the lines for each portion corresponding to each character image data. It is done. An embodiment employing such a method is also one of variations of the present invention.

  In this embodiment, the image data is font data composed of character image data. However, the image data to be processed by the information processing apparatus according to the present invention is not limited to character image data. Any image data may be used as long as the unit image data has a constant size and is continuous. In particular, in that case, the “character image data” in the above embodiment is “unit image data”, the “divided character image data” is “divided unit image data”, and the “processed divided character image data” is “processing divided unit”. By appropriately replacing “image data” or the like, it is possible to explain the operation / configuration when image data other than character image data is processed. The same applies to other embodiments.

[Second Embodiment]
As further features seen in the binary image of the character image data, there are character image data mainly composed of vertical lines as shown in FIG. 26 and character image data mainly composed of horizontal lines as shown in FIG. These features are particularly noticeable when the characters are Chinese characters.

  When the input data is the character image data shown in FIG. 26, the output data shown in FIG. 28 is obtained by calculating the exclusive OR for each word arranged horizontally. As shown in FIG. 28, in the case of the character image data as shown in FIG. 26, when the exclusive OR is calculated, there are many words that become 0 words (words in which all bits are 0). Therefore, the frequency of 0 words can be increased without losing information by exclusive OR, and the encoding efficiency can be increased.

  On the other hand, when the input data is the character image data shown in FIG. 27, even if the exclusive OR for each word arranged horizontally is calculated, the output data is as described above as shown in FIG. There is no effect of increasing the frequency of the value of a specific word.

  An image encoding apparatus according to a second embodiment of the present invention is an apparatus that encodes a series of character font data corresponding to different character codes using a difference between lines for each series of words. Encoding is performed using the above characteristics of character image data. For this reason, the image coding apparatus according to the second embodiment of the present invention is characterized in that the character image data is rotated so that the data amount of the coded data becomes smaller at the time of coding. This is a difference from the image coding apparatus according to the first embodiment. Therefore, the difference will be mainly described below.

  FIG. 30 is a block diagram showing a specific example of a functional configuration for functioning as an image encoding device in the PC 3 according to the present embodiment and performing image encoding processing.

  Referring to FIG. 30, the functions of the image coding apparatus according to the present embodiment are added to the functions included in the functions of the image coding apparatus according to the first embodiment shown in FIG. The flag data memory 2410 is included.

  Further, FIG. 31 is a block diagram showing a specific example of the configuration of the image processing unit 1209 according to the present embodiment. Referring to FIG. 31, an image processing unit 1209 according to the present embodiment includes an image calculation unit 2701, a first character image data memory 2702, a second character image data memory 2703, a first divided character image data memory 2704, The divided character image data memory 2705, the first processed divided character image data memory 2706, the second processed divided character image data memory 2707, and the capacity predicting unit 2708 are configured, and each component is mutually connected via the data bus 2709. Also connected to the outside.

  In the present embodiment, character image data for one character is read out from the image data stored in the image data memory 1202 by the image calculation unit 2701, and the first character image data memory is stored as “first character image data”. 2702 is stored. The first character image data stored in the first character image data memory 2702 is divided in the vertical direction at the byte boundary in the horizontal direction by the image calculation unit 2701, and the first divided character image data is obtained as “first divided character image data”. It is stored in the image data memory 2704.

  The first divided character image data stored in the first divided character image data memory 2704 is further rotated in a predetermined direction by the image calculation unit 2701 to obtain “second character image data” as the second character image data memory. 2703 is stored. The second character image data stored in the second character image data memory 2703 is divided in the vertical direction at the byte boundary in the horizontal direction by the image calculation unit 2701, and the second divided character image data is obtained as “second divided character image data”. It is stored in the image data memory 2705. Here, the “predetermined direction” is 90 degrees clockwise.

  The image of one character stored in the image data memory 2409 is XORed with the divided image stored in the first divided character image data memory 2704 (hereinafter sometimes referred to as “processed divided character image”). The first processed divided character image data memory 2706 is stored.

  With respect to the first divided character image data stored in the first divided character image data memory 2704, an exclusive OR is calculated in the image calculation unit 2701, and the calculation result is “first processed divided character image data” as the first processed character. The divided character image data memory 2706 is stored.

  Similarly, with respect to the second divided character image data stored in the second divided character image data memory 2705, an exclusive OR is calculated by the image calculation unit 2701, and the calculation result is “second processed divided character image data”. The second processed divided character image data memory 2707 is stored.

  The capacity prediction unit 2708 encodes the capacity of the first character image data stored in the first character image data memory 2702 and the second processed divided character image data stored in the second processed divided character image data memory 2707. Are predicted, and the predicted results are compared. According to the comparison result in the capacity prediction unit 2708, the first processed divided character image data stored in the first processed divided character image data memory 2706 or the second processed divided character stored in the second processed divided character image data memory 2707 Character image data is output. In addition, a flag indicating the comparison result in the capacity prediction unit 2708 is stored in the flag data memory 2410 by the image calculation unit 2701.

  FIG. 32 is a flowchart illustrating an encoding process in the image encoding device according to the second embodiment. The processing shown in the flowchart of FIG. 32 is also realized by the CPU 101 reading out and executing a program stored in the storage unit such as the ROM 103, and the controller 1201 controlling each unit shown in FIG. Note that the encoding process in the second embodiment shown in FIG. 32 is substantially the same as the encoding process in the second embodiment shown in the flowchart of FIG. 9, and the following points are different. . That is, instead of the processing in step S1303 and the processing in step S1304 in the first embodiment, the processing in step S2503 and the processing in step S2504 are executed in the encoding processing in the second embodiment. . In addition to the above processing, the processing in step S2511 is executed.

  FIG. 33 is a flowchart showing image data division processing in step S2503.

  Referring to FIG. 33, first, image calculation unit 2701 reads character image data for one character from the image data loaded into image data memory 1202 in step S1301, and converts the first character image data to the first character image data. The image data is stored in the image data memory 2702 (step S3701).

  Next, the image calculation unit 2701 generates the first divided character image data by dividing the first character image data stored in the first character image data memory 2702 in the vertical direction by the horizontal byte boundary. The divided character image data memory 2704 is stored (step S3702). The division method here may be the same method as described in the first embodiment.

  Next, the image calculation unit 2701 rotates the first character image data stored in the first character image data memory 2702 by 90 degrees clockwise to generate second character image data, and the second character image data memory 2703. (Step S3703).

  Next, the image calculation unit 2701 generates the second divided character image data by dividing the second character image data stored in the second character image data memory 2703 in the vertical direction by the horizontal byte boundary. The divided character image data memory 2705 is stored (step S3704). The dividing method here may be the same method as described in the first embodiment.

Then, the process ends, and the process proceeds to step S2504.
FIG. 34 is a flowchart showing the exclusive OR calculation process in step S2504.

  Referring to FIG. 34, first, image calculation unit 2701 calculates an exclusive OR for the first divided character image data stored in first divided character image data memory 2704 in step S3702, and performs first processing. The divided character image data is stored in the first processed divided character image data memory 2706 (step S2801). The exclusive OR calculation method may be the same as the method described in the first embodiment.

  If the process of calculating the exclusive OR for all the first divided character image data obtained from the image data loaded in step S1301 has been completed (YES in step S2802), the process proceeds to step S2803. If not (NO in step S2802), the process returns to step S2801.

  In step S2803, the capacity prediction unit 2708 predicts the encoded capacity of the first character image data stored in the first character image data memory 2702 (step S2803). The prediction method in step S2803 only needs to be consistent with the encoding method in step S1306, and is not limited to a specific method in the present invention. As a specific example, the entropy of the first processed divided character image data obtained from the first character image data stored in the first character image data memory 2702 by adopting the entropy encoding method in step S1306 above. The method of summing up is mentioned. The target value to be predicted is the amount of increase in the code data amount (herein referred to as “limit code amount”) by encoding the individual first processed divided character image data as the prediction method in step S2803. However, in this specific example, the range encoded as a lump of data is not processed divided character image data, and it is not easy to directly calculate this, so instead, the entropy prediction value of the first processed divided character image data is set to It is used. In any case, what is important is that the predicted value used here is consistent with the encoding method in step S1306 (there is a reason that the predicted value is sufficiently close to the target value). In this specific example, since Huffman coding is used as the coding method, it can be said that there is a reason that a value sufficiently close to the limit code amount can be obtained by using entropy as the prediction value of the limit code amount. . Of course, as long as the encoding method is such that the target value to be predicted (limit code amount) can be easily obtained, the limit code amount may be used, and this is a variation of the present invention.

  Next, the image computing unit 2701 calculates an exclusive OR of the second divided character image data stored in the second divided character image data memory 2705, and the obtained second processed divided character image data is stored in the second. The processed divided character image data memory 2707 is stored (step S2804).

  If the process of calculating the exclusive OR for all the second divided character image data obtained from the image data loaded in step S1301 has been completed (YES in step S2805), the process proceeds to step S2806, where If not, the process returns to step S2804.

  In step S2806, the capacity predicting unit 2708 predicts the encoded capacity of the second processed divided character image data 2707 stored in the second processed divided character image data memory 2707. The prediction method here is the same as the prediction method in step S2803, and may be any method that is consistent with the encoding method in step S1306. What has already been described with respect to the limit code amount and its prediction is also applicable.

  Next, the capacity predicting unit 2708 predicts the capacity after encoding of the first character image data obtained in step S2803 and the capacity after encoding of the second processed divided character image data obtained in step S2806. If the latter is larger (YES in step S2807), the second processed divided character image data stored in the second processed divided character image data memory 2707, that is, image data after rotation is output. (Step S2808), otherwise (NO in Step S2807), the first processed divided character image data stored in the first processed divided character image data memory 2705, that is, the image data before rotation is output (Step S2809). ).

  Next, the image calculation unit 2701 stores the determination result in step S2807, that is, a flag indicating which processing in step S2808 or step S2809 has been executed in the flag data memory 2410 (step S2810). The value of the flag can be, for example, “1” indicating that the predicted capacity value of the first character image data obtained in step S2803 is large, and “0” indicating otherwise. . In step S2810, a flag value is determined for each character. In the flag data memory 2708, a flag for each character is stored in association with the access table data stored in the access table data memory 2407 and the encoded data stored in the encoding table data memory 2405. . Specifically, the flag, the access table data, and the encoded data are also associated with each other in the order of processing.

  When the above-described processing is executed by the image encoding device according to the present embodiment, the character encoding data is mainly composed of vertical lines or mainly composed of horizontal lines. By using this feature, highly efficient encoding can be performed with a small amount of calculation. That is, even if the character image data to be encoded is directly calculated as the character image data shown in FIG. 27, the frequency of the value of a specific word is obtained as shown in FIG. In the case of character image data that does not have the effect of increasing, the exclusive OR is calculated by rotating 90 degrees as shown in FIG. As a result, the output data is as shown in FIG. 36, and the frequency of bytes having a value of zero can be increased. For this reason, when entropy encoding is performed, encoding can be performed after concentrating the value distribution on a specific value without losing the information of the original image data (without losing reversibility), and encoding efficiency. It contributes to the improvement.

[Third Embodiment]
FIG. 1 is a diagram illustrating a specific example of the hardware configuration of a mobile phone 1 as a text processing device equipped with the image decoding device according to the present embodiment, and a specific example of the hardware configuration of a general mobile phone. FIG.

  Referring to FIG. 1, a mobile phone 1 includes an input / output unit 140 that is an interface with a user, a CPU (Central Processing Unit), and the like, a control unit 120 that controls the entire device, and other devices. A communication unit 110 for communicating with a non-volatile memory such as a ROM (Read Only Memory), a RAM (Random Access Memory), a flash memory, and the like. And a storage unit 130 for storing intermediate data and data received from other computers.

  The communication unit 110 performs communication via a base station (not shown) and transmits / receives data to / from other devices such as a mobile phone.

  Further, the input / output unit 140 described above displays a key code input device (key) 142 including numeric buttons such as “1” and “2” and direction buttons such as “R” and “L”, and information to the user. A display 144 such as an LCD (Liquid Crystal Display), a microphone 146 that inputs sound, a speaker 148 that outputs sound, and a camera 149 that captures and inputs an image. The normal operation of the cellular phone 1 shown in FIG. 1 as a cellular phone is well known.

  The image decoding apparatus according to the present embodiment is configured by hardware of the mobile phone 1 and software stored in the storage unit 130 and executed by the control unit 120, and a function for performing an image decoding process to be described later is controlled. The unit 120 is mainly formed in the control unit 120 by reading and executing the program stored in the storage unit 130. Alternatively, at least a part of the above functions may be configured by the hardware of the mobile phone 1. The normal operation of the mobile phone 1 shown in FIG. 1 as a mobile phone is well known.

  FIG. 37 is a schematic diagram of a hardware configuration of a text processing apparatus in which the image decoding apparatus according to the present embodiment is mounted. The cellular phone 1 in which the image decoding apparatus according to the present embodiment shown in FIG. 2 is a block diagram schematically illustrating a hardware configuration. FIG.

  Referring to FIG. 37, the text processing apparatus includes an instruction device 4600 corresponding to the input / output unit 140, a controller 4601 corresponding to the control unit 120 and the like, a text data memory 4602 corresponding to a predetermined area of the storage unit 130, and an image decoding device. 4603, a display device 4604 corresponding to the display 144, and a storage device 4606 corresponding to the storage unit 130, and each element is connected by a data bus 4605.

  Text data is stored in the text data memory 4602 as character identification information of each character. Here, it is assumed that the character identification information includes a character code and typeface identification information, as in the first embodiment. Normally, the typeface is not changed frequently, so when using the same typeface as the previous character in the text data, the typeface identification information is omitted and the typeface is changed from the previous character. Only typeface identification information may be added.

  The storage device 4605 stores a program executed by the controller 4601 and other data. The text data memory 4602 may be configured on the storage device 4605.

  When the controller 4601 receives an instruction from the instruction device 4600, the controller 4601 reads out and executes the program stored in the storage device 4605, and controls the image decoding device 4603 to execute the decoding process. The image decoding device 4603 executes a process of decoding the corresponding glyph each time character identification information is given from the controller 4601 in response to an instruction signal from the instruction device 4600. That is, the image decoding apparatus according to the present embodiment is configured by hardware of a text processing apparatus and software stored in the storage device 4606 and executed by the controller 4601. Further, a function for performing an image decoding process to be described later is formed by the controller 4601 reading and executing a program stored in the storage device 4606. Or at least one part of the said function may be comprised by the hardware of a text processing apparatus.

  FIG. 38 is a flowchart showing image decoding processing in the text processing apparatus according to this embodiment. The processing shown in the flowchart of FIG. 38 is realized by the controller 4601 reading out and executing a program stored in the storage device 4606 and controlling each unit shown in FIG.

  Referring to FIG. 38, first, controller 4601 reads character identification information for one character from text data memory 4602 in accordance with an instruction signal from instruction device 4600 (step S4701). The image decoding device 4603 decodes the glyph corresponding to the character identification information read in step S4701 (step S4702). If the decoding is successful (YES in step S4703), the process proceeds to step S4704, and if not (NO in step S4703), the process proceeds to step S4705.

  In step S4704, the controller 4601 outputs the glyph decoded in step S4702 to the display device 4604 and generates a display signal for display (step S4704).

  If all characters in text data memory 4602 have been processed (YES in step S4705), the process ends; otherwise, the process returns to step S4701.

  FIG. 39 is a block diagram illustrating a specific example of a functional configuration that functions as the image decoding device 4603 in the mobile phone 1 that is the text processing device according to the present embodiment and performs the image decoding processing in step S4702. The image decoding apparatus according to the present embodiment accesses character font data that is encoded data encoded by the image encoding apparatus according to the first embodiment, and decodes necessary font data.

  Referring to FIG. 39, the above-described functions of the image decoding apparatus include a controller 3301, an encoded data memory 3302, an entropy decoding unit 3303, a processed divided character image data memory 3304, an access table data conversion unit 3305, an access table data memory 3306, The image processing unit 3307 and a character image data memory 3308 are included, and each component is connected to each other and the outside via a data bus 3309.

  FIG. 40 is a block diagram illustrating a specific example of the configuration of the image processing unit 3307. Referring to FIG. 40, image processing unit 3307 includes an image calculation unit 4801, a character image data memory 4802, and a divided character image data memory 4803. Each component is connected to each other via a data bus 4804, or Connected externally.

  FIG. 41 is a block diagram showing a specific example of the configuration of the access table data conversion unit 3305. Referring to FIG. 41, access table data conversion unit 3305 includes character identification information / glyph number conversion unit 5101 and glyph number / offset information conversion unit 5102, and each component is connected via data bus 5103. Connected to each other and to the outside.

  The encoded data memory 3302 and the access table data memory 3306 are configured by a predetermined area of the storage device 4604, and are respectively encoded data generated by the image encoding device according to the first embodiment and the access table. Store the data.

  The character identification information / glyph number conversion unit 5101 of the access table data conversion unit 3305 acquires an internal character code based on the character identification information received from the controller 3301. As the acquisition method here, the same method as the acquisition method in the first embodiment may be used. The character identification information / glyph number conversion unit 5101 refers to the access table data stored in the access table data memory 3306, identifies the glyph number corresponding to the internal character code, and converts the character identification information into the glyph number. To do. The converted glyph number is further converted into offset information by the glyph number / offset information converting unit 5102 of the access table data converting unit 3305 and input to the entropy code decoding unit 3303.

  The entropy code decoding unit 3303 uses offset information, which is input from the access table data conversion unit 3305 and is information for specifying a position on the encoded data, on the encoded data stored in the encoded data memory 3302. The part corresponding to the divided character image data corresponding to the character identification information to be decoded is accessed. Then, the encoded data of that portion (that is, data at the position specified by the offset information) is decoded and stored in the processed divided character image data memory 3304 as “processed divided character image data”. The processed divided character image data memory 3304 is also configured by a predetermined area of the storage device 4604 and stores the decoded data.

  The image calculation unit 4801 of the image processing unit 3307 calculates an exclusive OR of one piece of the processed divided character image data stored in the processed divided character image data memory 3304, and obtains “divided character image data”. The divided character image data memory 4803 is stored. The divided character image data memory 4803 is also configured by a predetermined area of the storage device 4604 and stores the divided character image data.

  Here, similarly to the calculation of the difference in the first embodiment, the 0th line extracted from the processed divided character image data that is the input data is used as it is as the 0th line of the divided character image data that is the output data. For the first and subsequent lines, the exclusive OR of the nth line of the processed divided character image data, which is the input data, and the (n-1) th line of the already restored divided character image data is output data. Is the value of the nth line of the divided character image data. By sequentially performing this process, the image processing unit 3307 restores the divided character image data from the processed divided character image data.

The reason why the divided character image data can be restored by this processing is that the operation of taking the exclusive OR is the inverse transformation of itself. That is,
C = A ^ B
If B = A ^ C
This is because

Therefore, for n ≧ 1, shown in the first embodiment,
(Nth line of processed divided character image data) = ((n-1) th line of divided character image data) ^ (nth line of divided character image data)
From the relationship
(Nth line of divided character image data) = ((n-1) th line of divided character image data) ^ (nth line of processed divided character image data)
Holds. That is, the value of the nth line of the divided character image data can be calculated using the value of the (n−1) th line of the divided character image data and the value of the nth line of the processed divided character image data.

As for n = 0, as also shown in the first embodiment,
(Nth line of processed divided character image data) = (nth line of divided character image data)
Therefore, it can be restored by copying the 0th line of the processed divided character image data directly to the divided character image data.

  Of course, if the processing on the encoding side is not exclusive OR between adjacent lines, if the transformation does not lose the information of the original image data (does not lose reversibility), decoding corresponding to this is possible. The divided character image data can be obtained from the processed divided character image data by performing the above process.

  The divided character image data stored in the divided character image data memory 4802 is integrated in the image calculation unit 4801 of the image processing unit 3307 to generate original character image data. The generated character image data is stored in the character image data memory 4802. The character image data stored in the character image data memory 4802 is stored in the character image data memory 3308 by the image calculation unit 4801. The character image data memories 4802 and 3308 are also configured by a predetermined area of the storage device 4604, and store character image data obtained as a result of the decoding process.

  FIG. 42 is a flowchart showing the decoding process executed by the image decoding apparatus in step S4702. Note that a device that uses the image decoding device, such as a text processing device equipped with the image decoding device, is referred to as a “main body module” in the following description.

  Referring to FIG. 42, first, controller 3301 of the image decoding apparatus receives character identification information from controller 4601 of the text processing apparatus (step S3401). The character identification information acquired in step S3401 is converted into a glyph number by the access table data conversion unit 3305 (step S3402).

  If the character identification information is successfully converted in step S3402 (YES in step S3403), the process proceeds to step S3405. If not (NO in step S3403), the process proceeds to step S3404. In step S3404, the controller 3301 returns an error value notifying the main body module that the decoding has not been successful (step 3404). If an error value is returned, the main module may perform appropriate processing such as displaying a space instead of the requested glyph and displaying an alternative character.

  In step S3405, the glyph number converted in step S3402 is converted into offset information by the access table conversion unit 3305 (step S3405).

  Next, the entropy code decoding unit 3303 corresponds to the character identification information acquired in step S3401 on the encoded data stored in the encoded data memory 3302 using the offset information converted in step S3405. The part corresponding to the processed divided character image data is accessed, and the encoded data of that part is decoded (step S3406). Then, the processed divided character image data obtained by decoding is stored in the processed divided character image data memory 3304.

  When the processing for all the processed divided character image data corresponding to the character identification information acquired in step S3401 is completed (YES in step S3407), the process proceeds to step S3408; otherwise (NO in step S3407), The process returns to step S3405.

  In step S3408, the image processing unit 3307 calculates an exclusive OR of the processed divided character image data decoded in step S3406 to obtain divided character image data. Next, the image processing unit 3308 integrates the divided character image data obtained in step S3408 to create original character image data (step S3409). The created character image data is stored in the character image data memory 3308, and the process ends.

  FIG. 43 is a flowchart showing the conversion process to the glyph number in step S3402. As in the first embodiment, the access table data stored in the access data memory 3306 includes character identification information / glyph number conversion data 1401, glyph number / offset, as shown in FIG. Further, the character identification information / glyph number conversion data 1401 includes a status table 1501, a first auxiliary table 1502, and a second auxiliary table 1503, as shown in FIG. In the following description, it is assumed that the access table data shown in FIGS. 8 and 19 is stored in the access data memory 3306 of the image decoding apparatus.

  Referring to FIG. 43, first, the character identification information / glyph number conversion unit 5101 acquires an internal character code for the target character based on the character identification information acquired in step S3401 (step S5201). This acquisition method is the same as the acquisition method (step S2301) in the first embodiment.

  Next, the character identification information / glyph number conversion unit 5101 accesses the status table 1501 stored in the access data memory 3306 (step S5202), and the internal character code acquired in step S5201 is defined in the status table 1501. Read the value. If the value specified in status table 1501 is “0” (YES in step S5203), the process proceeds to step S5205. If the value specified in status table 1501 is “2” (NO in step S5203, and If YES in step S5204, the process advances to step S5207; otherwise, if the specified value is “1” (NO in step S5203 and NO in step S5204), the process advances to step S5206.

  In step S5205, that is, if the value defined in the status table 1501 corresponding to the internal character code acquired in step S5201 is “0”, it is defined that there is no glyph corresponding to the internal character code. Therefore, the character identification information / glyph number conversion unit 5101 returns an error, and the process proceeds to step S3403.

  For an internal character code in which “1” or “2” is defined in the status table, it is necessary to obtain the corresponding glyph number.

  For the internal character code for which “1” is defined in the status table, the number of internal character codes for which “1” is defined in the past decoding processes is checked, and the obtained result is used as the glyph number. To do. As shown in FIG. 23, since the glyph numbers corresponding to some of the internal character codes are described in the first auxiliary table 1502, such access can be speeded up.

  In step S5206, that is, if the value defined in the status table 1501 corresponding to the internal character code acquired in step S5201 is “1”, the character identification information / glyph number conversion unit 5101 performs the first auxiliary table. The glyph number corresponding to the internal character code acquired in step S5201 is specified from 1502 and the status table 1501, and the process proceeds to step S3403. As a specific method for specifying the glyph number, the character identification information / glyph number conversion unit 5101 extracts the nearest internal character code that is not larger than the internal character code from the first auxiliary table 1502 and extracts it. Specifies the glyph number corresponding to the internal character code. Then, the number of internal character codes defined as “1” in the status table 1501 is counted from the extracted internal character code to the internal character code acquired in step S5201, and the internal character code acquired in step S5201 is counted. Glyph number.

  Specifically, the internal character code acquired in step S5201 is “11” in which the glyph number corresponding to the internal character code “11” is described as “8” in the status table of FIG. To do. In step S5206, the character identification information / glyph number conversion unit 5101 first extracts “10” from the first auxiliary table 1502 of FIG. 23 as a value closest to “11” without exceeding “11”. The glyph number “7” corresponding to the internal character code “10” is specified. This gives you an estimate of the glyph number. Then, by referring to the status table of FIG. 22, by counting the number of internal character codes “8” defined as “1” in the status table 1501 from the 10th to the next internal character code, A glyph number “8” corresponding to the internal character code “11” is obtained. This matches the glyph number “8” obtained from the status table 1501 of FIG.

  In step S5207, that is, if the value defined in the status table 1501 corresponding to the internal character code acquired in step S5201 is "2", the character identification information / glyph number conversion unit 5101 Referring to auxiliary table 5303, the glyph number corresponding to the internal character code is specified, and the process proceeds to step S3403.

  The character identification information / glyph number conversion data used in the character identification information / glyph number conversion unit 5101 is one specific example, and the conversion data generated here is the character identification information / glyph as described above. It is not limited to number conversion data. The point here is whether the correspondence between the character identification information (or the internal character code uniquely determined therefrom) and the glyph number or glyph is one-to-one or not (or how many glyph numbers or glyphs are Data indicating the number of glyph numbers or the number of glyphs corresponding to the character identification information, or conversely, the character identification information (or internal character code) and the glyph number at a high speed. Alternatively, it is necessary for the character identification information / glyph number conversion data by determining whether or not the correspondence relationship with the glyph is one-to-one and referring to a different table according to the determination result. Character identification information (or internal character code) can be converted to glyph numbers at high speed (specifying glyph data) while keeping the data capacity small. It lies in the fact that you kill so. Specifically, in this embodiment, whether or not the character identification information has a one-to-one correspondence with the glyph is determined by accessing the status table 1501, and if the character identification information has a one-to-one correspondence, the first auxiliary table. 1502 is referred to, and if not, the second auxiliary table 1503 is referred to. Further, the first auxiliary table 1502 is a subset of a correspondence table of character identification information (or internal character code) and glyph numbers, and the image decoding apparatus accesses the first auxiliary table 1502 to access the glyph number. By using this approximate value, a true glyph number can be obtained by accessing the status table 1501 a smaller number of times compared to when the first auxiliary table 1502 is not used. It has become.

  FIG. 44 is a flowchart showing the exclusive OR calculation processing in step S3408.

  Referring to FIG. 44, first, image calculation unit 4801 calculates an exclusive OR for one piece of processed divided character image data stored in processed divided character image data memory 3304 in step S3406, and performs division. Character image data is stored in the divided character image data memory 4803 (step S4901). As described above, the process of calculating the exclusive OR of the encoded data corresponds to the reverse process of the process of calculating the exclusive OR at the time of data encoding. The divided character image data before encoding is restored.

  When the process of calculating the exclusive OR for all the processed divided character image data corresponding to the character identification information acquired in step S3401 is completed (YES in step S4902), the process proceeds to step S3409. Otherwise (NO in step S4902), the process returns to step S4901.

  FIG. 45 is a flowchart showing the integration processing of divided character image data in step S3409.

  Referring to FIG. 45, first, image calculation unit 4801 integrates the divided character image data stored in divided character image data memory 4802 as a result of the execution of the process of step S3408 to obtain character image data. The data is stored in the memory 4802 (step S5001). The image calculation unit 4801 reads the character image data stored in the character image data memory 4802, outputs it to the character image data memory 3308, and stores it in the character image data memory 3308 (step S5002). Thus, the process ends.

[Fourth Embodiment]
The image decoding apparatus according to the fourth embodiment is an apparatus that decodes the encoded data encoded by the image encoding apparatus according to the second embodiment.

  FIG. 46 is a block diagram showing a specific example of a functional configuration for functioning as an image decoding device and performing image decoding processing in the text processing device according to the present embodiment.

  Referring to FIG. 46, the function of the image decoding apparatus according to the present embodiment includes, in addition to the functions included in the function of the image decoding apparatus according to the third embodiment shown in FIG. A flag data memory 3610 is included.

  The flag data memory 3610 includes a predetermined area of the storage device 4604, and stores in advance flag data generated by the image encoding device according to the second embodiment.

  The decoding process in the image decoding apparatus according to the third embodiment is the same as the decoding process shown in FIG. 42 in the second embodiment.

  FIG. 47 is a flowchart showing the division character image data integration processing in step S3409 according to the present embodiment.

  Referring to FIG. 47, the image calculation unit 4801 of the image processing unit 3307 according to the present embodiment integrates the divided character image data stored in the divided character image data memory 4803 and stores the divided character image data in the character image data memory 4802. Store (step S5401).

  The image calculation unit 4801 refers to the flag value corresponding to the character image data to be processed in step S5401 among the flag data stored in the flag data memory 3610 (step S5402). If the flag value is “0”, that is, if the rotated image data has been encoded (NO in step S5402), the process proceeds to step S5403, and if the flag value is “1”. That is, if the image data before rotation has been encoded (YES in step S5402), step S5403 is skipped, and the process proceeds to step S5404.

  In step S5403, the image calculation unit 4801 rotates the character image data stored in the character image data memory 3502 by 90 degrees, and then stores it again in the character image data memory 3502 (step S5403). In step S5403, image calculation unit 4801 rotates the character image data in the opposite direction to the rotation (step S3703) performed by image calculation unit 2701 on the first character image data in the second embodiment. Shall. Accordingly, in correspondence with the fact that the character image data is rotated 90 degrees clockwise in the image encoding apparatus according to the second embodiment, here, it is rotated 90 degrees in the opposite direction, that is, counterclockwise (“clock” It may also be expressed as “-90 degrees around”). In other words, when generalized, the process executed here is a process of performing an inverse transformation so as to cancel the influence of the transformation (here, the rotation process) performed on the character image data at the time of encoding.

  The image calculation unit 4801 reads the character image data stored in the character image data memory 4802 in step S5401 or step S5403, outputs the character image data to the character image data memory 3308, and stores it in the character image data memory 3308 (step S5404). . Thus, the process ends.

[Fifth Embodiment]
In the fifth embodiment, an example of the glyph number / offset information conversion data generation unit incorporated in the access table data generation unit of the image encoding device according to the first embodiment is presented. In the following description, character data is taken as an example, but the data to be encoded by the image encoding apparatus according to the present invention is not limited to character data. Further, although Huffman coding will be described as an encoding method in the image encoding device according to the present invention, other variable length encoding such as arithmetic encoding may be used.

  The image encoding apparatus according to the fifth embodiment records an access pointer to the head position of each unit configured by a predetermined number of blocks when the encoded data of a predetermined size unit is one block. Create the access table. As a result, the storage capacity required to hold the access table can be reduced as compared with the case where the access pointer to the head position of each block is recorded.

(Configuration of glyph number / offset information conversion data generation unit according to the fifth embodiment)
FIG. 48 is a block diagram showing a detailed configuration of the glyph number / offset information conversion data generation unit according to the fifth embodiment.

  The image coding apparatus according to the fifth embodiment is the same as the image coding apparatus shown in the first embodiment except that the glyph number / offset information conversion data generation unit 2202 is replaced with a glyph number / offset information conversion. A data generation unit 5000 is included. Other configurations are the same as described above and will not be repeated.

  Referring to FIG. 48, glyph number / offset information conversion data generation unit 5000 includes Huffman code length calculation unit 220201, access pointer update unit 220202, access pointer output unit 220203, data block management unit 220204, data block A size storage unit 2202041, a data unit management unit 220205, and a data unit size storage unit 2202051 are included.

  Furthermore, the encoded data memory 1205 includes an encoded data storage unit 120501 that stores encoded data, and a Huffman dictionary storage unit 120502 that stores a Huffman table (Huffman dictionary).

  These components can be configured mainly by a dedicated LSI (Large-Scale Integration) that realizes the function of the image encoding device and a memory. However, it may be configured by other hardware. Such a dedicated LSI functions as a controller 1201, an access table data generation unit 1206, an entropy encoding unit 1204, and an image processing unit 1209.

  The Huffman code length calculation unit 220201 receives processed divided character image data (for example, data shown in FIG. 17) and a Huffman dictionary from the Huffman dictionary storage unit 120502. The Huffman code length calculation unit 220201 sets the processed divided character image data in a predetermined size unit (for example, 1 byte (1 word)), but the bit of the encoded data registered in the Huffman dictionary stored in the Huffman dictionary storage unit 120502 The length of the corresponding Huffman code, that is, the Huffman code length is calculated. The Huffman code length calculation unit 220201 outputs the calculated Huffman code length to the access pointer update unit 220202.

  Here, in the following description, data of a predetermined size unit (for example, corresponding to the Huffman dictionary) read for encoding by the Huffman code length calculation unit 220201 is referred to as a “subblock”. Data composed of a predetermined number of sub-blocks is called “block”, and data composed of a predetermined number of blocks is called “unit”. For example, assume that 1-byte data is one sub-block. Further, for example, 11 sub-blocks are defined as 1 block, and 2 blocks are defined as 1 unit. When character data is handled, it can be considered that one glyph corresponds to one block of data.

  Note that the Huffman code length calculation unit 220201 calculates the Huffman code length for each sub-block of the processed divided character image data, and the access pointer update unit 220202 updates the access pointer. It is assumed that the encoding processing performed by the entropy encoding unit 1204 for each block is performed in synchronization.

  Further, subblocks, blocks, and units for which the code length is calculated by the Huffman code length calculation unit 220201 are referred to as “processed subblock”, “processed block”, and “processed unit”, respectively.

  In accordance with an instruction from the controller 1201, the access pointer update unit 220202 initializes the access pointer and substitutes 0 at the start of processing. Here, the “access pointer” refers to information for accessing data stored in the code data storage unit 120501 (for example, information for specifying an address in the memory). Then, the access pointer update unit 220202 updates the access pointer using the Huffman code length input from the Huffman code length calculation unit 220201 after the start of processing. Further, the access pointer updating unit 220202 outputs the updated access pointer to the access pointer output unit 220203.

  The access pointer output unit 220203 receives the access pointer from the access pointer update unit 220202. Further, the access pointer update unit 220202 receives the current number of processed sub-blocks from the data block management unit 220204 and the current number of processed blocks from the data unit management unit 220205, respectively. When the current number of processed sub-blocks and the current number of processed blocks are both 0, the current access pointer is output as glyph number / offset information conversion data.

  In accordance with an instruction from the controller 1201, the data block management unit 220204 initializes the number of processed subblocks and substitutes 0 at the start of processing. After the start of processing, the data block management unit 220204 receives the current number of processed subblocks from the access pointer output unit 220203 and updates the current number of processed subblocks by adding 1.

  Further, the data block management unit 220204 determines whether or not the current number of processed subblocks is equal to the data block size (for example, 11) stored in the data block size storage unit 2202041.

  If it is determined that they are not equal, an instruction is transmitted to the Huffman code length calculation unit 220201 via the controller 1201 so as to execute the next Huffman code length calculation. On the other hand, if it is determined that they are equal, an instruction is transmitted to the data unit management unit 220205 via the controller 1201 so as to execute the processing.

  The data block size storage unit 2202041 stores a data block size (for example, 11) used when the data block management unit 220204 executes the determination process. Then, the data block size (for example, 11) is referenced from the data block management unit 220204 as necessary. The data block size storage unit 2202041 is configured with a predetermined area of the storage device of the image encoding device.

  In accordance with an instruction from the controller 1201, the data unit management unit 220205 initializes the number of processed blocks and substitutes 0 at the start of processing. After the start of processing, the data unit management unit 220205 receives the necessity of execution from the data block management unit 220204, for example, via the controller 1201. In response to an execution instruction from the data block management unit 220204 via the controller 1201, the data unit management unit 220205 adds 1 to the current number of processed blocks and updates it.

  Further, the data unit management unit 220205 determines whether or not the current number of processed blocks is equal to the data unit size (for example, 2) stored in the data unit size storage unit 2202051.

  If it is determined that the data unit management unit 220205 is not equal, the data block management unit 220204 is initialized to the number of processed sub-blocks, and the data unit management unit 220205 is next to the Huffman code length calculation unit 220201. For example, an instruction is transmitted via the controller 1201 so as to execute the Huffman code length calculation.

  On the other hand, if it is determined that the data unit management unit 220205 is equal, it is determined whether all inputs to the glyph number / offset information conversion data generation unit 5000 have been completed. If the input has not ended, the number of processed blocks is initialized and 0 is substituted. Then, the data unit management unit 220205 causes the data block management unit 220204 to initialize the number of processed subblocks, and causes the Huffman code length calculation unit 220201 to execute the next Huffman code length calculation. An instruction is transmitted via 1201. When the input of the processed divided character image data is completed, the data unit management unit 220205 instructs the controller 1201 to end the processing in the glyph number / offset information conversion data generation unit 5000.

  The data unit size storage unit 2202051 stores the data unit size (for example, 2) used when the data unit management unit 220205 executes the determination process. The data unit size (for example, 2) is referred to from the data unit management unit 220205 as necessary. Note that the data unit size storage unit 2202051 is configured by a predetermined area of the storage device of the image encoding device.

Next, the encoded data memory 1205 will be described.
The code data storage unit 120501 stores the encoded processed divided character image data.

  The Huffman dictionary storage unit 120502 stores a Huffman dictionary used when generating encoded processed divided character image data stored in the code data storage unit 120501. Then, the Huffman code length calculation unit 220201 refers to the Huffman dictionary as necessary. The Huffman dictionary and Huffman encoding will be described later.

(Glyph number / offset information conversion data generation processing according to the fifth embodiment)
Next, specific processing contents of the glyph number / offset information conversion data generation unit in the image encoding device according to the fifth embodiment will be described.

  FIG. 49 is a flowchart showing a glyph number / offset information conversion data generation process executed by the glyph number / offset information conversion data generation unit according to the fifth embodiment.

  The processing shown in the flowchart of FIG. 49 is realized by a processor functioning as the controller 1201 reading and executing a program stored in the storage device, and controlling each unit shown in FIG. 48 and the like. Note that the processing shown in the flowchart of FIG. 49 is merely a specific example of the glyph number / offset information conversion data generation processing, and may be executed by changing the order of the steps, for example.

  Referring to FIG. 49, in accordance with the processing start instruction from controller 1201, access pointer update unit 220202 initializes (assigns 0 to) access pointer AcPtr (step S130801). The data unit management unit 220205 initializes the number of processed blocks B1Num (substitutes 0) (step S130802). Subsequently, the data block management unit 220204 initializes (substitutes 0) the number of processed sub-blocks DtNum (step S130803).

  Next, the Huffman code length calculation unit 220201 synchronizes the processed divided image data with a predetermined size (for example, 1 byte) in synchronization with the encoding process performed by the entropy encoding unit 1204 for sub-blocks on the processed divided character image data. ) And the code length H [bit] of the corresponding code is calculated by referring to the Huffman dictionary stored in the Huffman dictionary storage unit 120502 (step S130804).

  Then, the access pointer updating unit 220202 adds the code length H calculated in step S130804 to the access pointer AcPtr for updating (step S130805).

  Subsequently, the access pointer output unit 220203 determines whether or not the current processed block count B1Num and the current processed subblock count DtNum are “both 0” (step S130806). If it is determined that “both are 0” (YES in step S130806), the current access pointer is output as glyph number / offset information conversion data (step S130807). On the other hand, if it is determined that “at least one of BlNum and DtNum is not 0” (NO in step S130806), the process proceeds to step S130808.

  Next, the data block management unit 220204 adds 1 to the number of processed subblocks DtNum and updates it (step S130808).

  Further, the data block management unit 220204 determines whether or not the number of processed sub blocks DtNum is equal to the data block size BSIZE (for example, 11) stored in the data block size storage unit 2202041 (step S130809). If it is determined that they are equal (YES in step S130809), the process advances to step S130810. On the other hand, if it is determined that they are not equal (NO in step S130809), the process proceeds to step S130804, and the Huffman code length of the next sub-block is calculated.

  Next, the data unit management unit 220205 adds 1 to the number of processed blocks B1Num and updates it (step S130810).

  Further, the data unit management unit 220205 determines whether or not the number of processed blocks B1Num is equal to “data unit size USIZE” (for example, 2) stored in the data unit size storage unit 2202051 (step S130811). If it is determined that they are equal (YES in step S1308011), the process proceeds to step S130812. If it is determined that they are not equal (NO in step S1308011), the process advances to step S130803 to initialize the number of processed sub-blocks and then calculate the next Huffman code length.

  Subsequently, the data unit management unit 220205 determines whether or not input of all the processed divided image data has been completed (step S130812). If it is determined that the input has not ended (NO in step S13080212), the process advances to step S130802 to initialize the number of processed blocks and the number of processed subblocks, and then calculate the next Huffman code length. . On the other hand, if it is determined that the input has been completed (YES in step S1308012), the glyph number / offset information conversion data generation process ends.

As described above, the glyph number / offset information conversion data generation processing is performed.
(An example of a Huffman dictionary)
Next, the Huffman dictionary and Huffman coding will be described using specific examples. Note that the Huffman dictionary and Huffman encoding are shown in Non-Patent Document 1 and are well known and will not be described in detail.

FIG. 50 is a diagram illustrating an example of a Huffman dictionary.
The Huffman dictionary will be described with reference to FIG. In the relationship table 10, a column 101 is original data (encoded data) 1011 to 1019 to be encoded, and a column 102 is codes 1021 to 1029 when each original data is encoded.

  For example, the original data 1011 represents original data in which all bits are 0, that is, “0” when expressed in decimal notation as 1-byte (= 8 bits) data. The corresponding code 1021 is represented by “110”. The bit length (that is, the code length) of the code 1021 is 3, which is relatively shorter than the other codes 1022, 1023 and the like. This means that the original data 1011, that is, the original data corresponding to decimal notation 0 appears frequently in the data to be encoded.

(Example of Huffman coding)
FIG. 51 is a diagram illustrating an example of Huffman coding.

  Huffman coding will be described with reference to FIG. As shown in FIG. 51, column 3 is processed divided image data to be encoded, and is processed divided image data including the example of the processed divided image data shown in FIG. Column 2 is encoded data when the processed divided image data of column 3 is encoded according to the Huffman dictionary shown in FIG. The data in the column 3 is a series of processed divided character image data corresponding to a large number of glyphs as one large data. Here, in the present embodiment, it is assumed that Huffman dictionaries are created independently for each of the processed divided image data corresponding to FIGS. 68 and 70, and Huffman coding is performed independently of each other.

  The processed divided image data in column 3 is composed of blocks 11, 12, and 13 corresponding to one glyph. The block 11 includes sub blocks 1101 to 1111, the block 12 includes sub blocks 1201 to 1211, and the block 13 includes sub blocks 1301 to 1311.

  The encoded data of column 2 is composed of block encoded data 21, 22, and 23 corresponding to the encoded blocks 11, 12, and 13, respectively. The block encoded data 21 includes sub block encoded data 2101 to 2111, the block encoded data 22 includes sub block encoded data 2201 to 2211, and the block encoded data 23 includes sub block encoded data 2301 to 2311.

  The sub-block encoded data is obtained by encoding the sub-block according to the Huffman dictionary. For example, the sub block 1101 has a correspondence relationship with the sub block encoded data 2101. Further, for example, the block 12 has a correspondence relationship with the block encoded data 22.

  Assume that the Huffman code length calculation unit 220201 reads and encodes in units of 1 byte (= 8 bits) (word units), for example, as indicated by the sub-block 1101 and the like.

  Here, for example, the processed divided image data corresponding to one glyph like the block 12 has a fixed data size (11 bytes). Therefore, it is possible to easily access data (for example, block 12) corresponding to a desired glyph without including the glyph boundary information in the processed divided image data indicated by the column 3.

  For example, when glyph numbers are assigned in order from 0, the processed divided image data 10 is read by 11 bytes starting from the position advanced by “glyph number × 11 (bytes)” from the start position of the processed divided image data. Can be accessed.

  On the other hand, the encoded data shown in column 2 is different from the processed divided image data, and encoded data corresponding to one glyph (for example, block encoded data 22) has different data sizes. Therefore, in order to obtain encoded data (for example, block encoded data 22) corresponding to an arbitrary glyph, for example, the head of the encoded data indicated by column 2 is accessed, and decoding processing is sequentially performed from there. Encoded data (for example, block encoded data 22) needs to be acquired.

  However, when the decoding process is sequentially performed from the top, the processing time increases when accessing the data located behind in the encoded data. Therefore, it is necessary to obtain an access position in the encoded data by some method for each block encoded data (for example, block encoded data 22) corresponding to one glyph. For example, according to the method disclosed in Patent Document 1, offset information (offset from the beginning of the encoded data) corresponding to the glyph number is created in advance as a table. A method of accessing a part corresponding to an arbitrary glyph in the encoded data according to the offset information with reference to this table can be considered.

  However, when offset information corresponding to all glyphs is created as a table, it is necessary to hold table data in addition to encoded data, and the table data capacity may not be negligible compared to the encoded data capacity.

  Therefore, the image coding apparatus according to the fifth embodiment records the access pointer to the head position of each unit composed of a predetermined number of blocks according to the flowchart shown in FIG. Generate offset information conversion data. Thus, when decoding, it is not necessary to sequentially perform decoding processing for all data from the beginning of a series of encoded data. Furthermore, it is possible to generate glyph number / offset information conversion data that makes it possible to suppress an increase in data capacity.

(Relationship between glyph number and unit index)
Next, the relationship between the glyph number and the unit index will be described using a specific example.

FIG. 52 is a diagram showing an example of the relationship between glyph numbers and unit indexes.
The glyph number / unit index relation table 20 shown in FIG. 52 is illustrated for explaining the concept, and does not specifically create the relation table 20.

  In the relationship table 20, a column 201 is glyph numbers 2100 to 2016 assigned to the glyphs included in the image data stored in the image data memory 1202 in ascending order from the top 0. A column 202 is unit indexes 2021 to 2026 that are uniquely calculated when the glyph number indicated by the column 201 is specified. Specifically, for example, when the original data size (processed divided image data size) constituting one glyph is 11 bytes, “11” is stored in the data block size storage unit 2202041 as the data block size BSIZE. . Further, the data unit size USIZE stored in the data unit size storage unit 2202051 may be determined by the system designer, but here it is “2” as an example. A method for determining the data unit size USIZE will be described in detail in the seventh embodiment.

  At this time, when the glyph number / offset information conversion data is generated according to the flowchart shown in FIG. 49, a unit composed of encoded data corresponding to the glyph number 2011 (“0”) and the glyph number 2012 (“1”). The index of “0” is “0”, and is represented by the unit index 2021 and the unit index 2022 in the relation table 20. Similarly, the index of the unit composed of the encoded data corresponding to the glyph number 2013 (“2”) and the glyph number 2014 (“3”) is “1”. In the relationship table 20, the unit index 2023, the unit index It is represented by 2024. However, although the description will be repeated, the relationship table 20 is not specifically generated in the present embodiment. The relationship between the glyph number and the unit index taking the relationship table 20 as an example will be described again in the description of the sixth embodiment described later.

(Relationship between unit index and offset)
Next, the relationship between the unit index and the offset will be described using a specific example.

FIG. 53 is a diagram illustrating an example of a relationship between a unit index and an offset.
As shown in FIG. 53, in the relationship table 30, a column 301 indicates unit indexes 3011 to 3013, and a column 302 indicates offsets 3021 to 3023. The unit index is exemplified for explaining the concept. Specifically, the address to the head of the offset (the address of the memory location where the offset 3021 (“0”) is stored) and the offset 3021 are illustrated. ˜3023 (fixed order) may be stored in the access table data memory 1207.

  The unit indexes shown in the column 301 correspond to the unit indexes 2021 to 2026 obtained uniquely from the glyph numbers 2011 to 2016 described in the relation table 20 in FIG. That is, once the glyph number is determined, the offset is uniquely determined.

  The offset 3021 (“0”) in the column 302 is the block encoding data 21 of FIG. 51 corresponding to the glyph number 2011 (“0”) or the block encoding corresponding to the glyph number 2012 (“1”). This represents that when the data 22 is accessed, the offset should be “0”. Similarly, the offset 3022 (“83”) is used when accessing the block encoded data 23 corresponding to the glyph number 2013 (“2”) or the encoded data corresponding to the glyph number 2014 (“3”). , The offset should be accessed as “83”. Here, the unit of the offset value is a bit. That is, the offset “83” is the first bit position of the block encoded data 23 corresponding to the glyph number “2” (the first bit position of the sub-block encoded data 2301) in the encoded data indicated by the column 2 in FIG. ) Is an offset for accessing. In other words, it is the total number of bits of encoded data corresponding to the block encoded data 21 and the block encoded data 22.

  The relationship between the unit index and the offset taking the relationship table 30 as an example will be described again in the description of the sixth embodiment described later.

  In the above description, the function of the access pointer updating unit 220202, the access pointer initialization processing step S130801, and the access pointer update processing step S130805 are initialized by substituting 0, and then updated by adding the Huffman code length. Although the case has been exemplified, the present invention is not limited to the above method, and the access pointer may be updated by another method as long as information for accessing the encoded data can be obtained. For example, it is possible to update the access pointer by sequentially storing the encoded data every time the code length is calculated and calculating the data capacity (size) of the entire stored code data at the time of access pointer update.

  As described above, the image coding apparatus according to the fifth embodiment is configured so that when a predetermined size unit of data is one block, each unit configured with a predetermined number of blocks Create an access table that records the access pointer. As a result, the storage capacity required to hold the access table can be reduced as compared with the case where the access pointer to the head position of each block is recorded.

[Sixth Embodiment]
In the sixth embodiment, an image decoding device for decoding data encoded by the image encoding device according to the fifth embodiment will be described.

FIG. 54 is a block diagram showing a configuration of an image decoding apparatus according to the sixth embodiment.
With reference to FIG. 54, an image decoding apparatus according to the sixth embodiment will be described. The image decoding apparatus according to the sixth embodiment includes an encoded data memory 3302, an entropy code decoding unit 3303, an access table data memory 3306, a glyph number in the image decoding apparatus shown in FIG. 39 and the like in the third embodiment. In place of the offset information conversion unit 5102, an encoded data memory 3405, an entropy code decoding unit 3404, an access table data memory 3407, and a glyph number / offset information conversion unit 5300 are included. Other configurations are the same as described above and will not be repeated. The components described below can be mainly configured by a dedicated LSI and memory that realizes the function of the image decoding apparatus. However, it may be configured by other hardware. Such a dedicated LSI functions as a controller 3301, an entropy code decoding unit 3404, an access table data conversion unit 3305, and an image processing unit 3307.

  First, the glyph number / offset information conversion unit 5300 will be described. The glyph number / offset information conversion unit 5300 includes a unit index calculation unit 530001 and an offset acquisition unit 530002.

  The unit index calculation unit 530001 receives a glyph number. The unit index calculation unit 530001 calculates a unit index based on the input glyph number. A specific example of the unit index calculation method will be described later. The unit index calculation unit 530001 outputs the calculated unit index to the offset acquisition unit 530002.

  The offset acquisition unit 530002 receives the unit index from the unit index calculation unit 530001. Based on the input unit index, the offset acquisition unit 530002 refers to data stored in the glyph number / offset information conversion data storage unit 330701 to acquire offset information. The offset acquisition unit 530002 outputs the acquired offset information to the code data acquisition unit 330403.

Next, the entropy code decoding unit 3404 will be described.
The entropy code decoding unit 3404 includes an intra-unit block position calculation unit 330401, an intra-unit block position management unit 330402, a code data acquisition unit 330403, a Huffman decoding unit 330404, and a decoded data output unit 330405.

  The in-unit block position calculation unit 330401 receives a glyph number. The intra-unit block position calculation unit 330401 calculates the intra-unit block position based on the input glyph number. A specific example of the method for calculating the intra-unit block position will be described later. The intra-unit block position calculation unit 330401 outputs the calculated intra-unit block position to the intra-unit block position management unit 330402.

  The intra-unit block position management unit 330402 receives the intra-unit block position from the intra-unit block position calculation unit 330401. Further, in accordance with an instruction from the controller 3301, the unit block position management unit 330402 initializes the number of processed blocks and substitutes 0 at the start of processing, initializes the number of processed subblocks, and substitutes 0. In addition, after the processing is started, the intra-unit block position management unit 330402 updates the current number of processed blocks by adding 1 in accordance with an instruction from the controller 3301. Further, the intra-unit block position management unit 330402 updates the current number of processed sub-blocks by adding 1 in accordance with an instruction from the controller 3301. Further, the intra-unit block position management unit 330402 determines whether or not the current number of processed blocks is equal to the intra-unit block position input from the intra-unit block position calculation unit 330401. An instruction is transmitted to the unit 330405 via the controller 3301 so as to execute the process.

  The code data acquisition unit 330403 receives an offset from the offset acquisition unit 530002. Also, the code data acquisition unit 330403 refers to the encoded data stored in the code data storage unit 330501 in accordance with an instruction from the controller 3301. At the start of processing, the encoded data is sequentially acquired bit by bit from the bit position indicated by the input offset, and the acquired encoded data is sequentially output to the Huffman decoding unit 330404.

  The Huffman decoding unit 330404 receives encoded data sequentially bit by bit from the encoded data acquisition unit 330403. The Huffman decoding unit 330404 refers to the Huffman dictionary stored in the Huffman dictionary storage unit 330502 based on the input encoded data, and decodes the Huffman code. The Huffman decoding unit 330404 outputs the decoded data to the decoded data output unit 330405.

  The decoded data output unit 330405 receives the decoded data from the Huffman decoding unit 330404. Further, when receiving an execution instruction from the controller 3301, the decoded data output unit 330405 outputs the input decoded data as decoded processed divided image data.

Next, the encoded data memory 3405 will be described.
The encoded data memory 3405 includes an encoded data storage unit 330501 and a Huffman dictionary storage unit 330502.

  The encoded data storage unit 330501 stores encoded processed divided image data, and the encoded data is referred to by the encoded data acquisition unit 330403 as necessary.

  The Huffman dictionary storage unit 330502 stores the Huffman dictionary used when generating the coded processed divided image data stored in the code data storage unit 330501, and the Huffman dictionary 330404 refers to the Huffman dictionary as necessary. The

Further, the access table data memory 3407 will be described.
The access table data memory 3407 includes a glyph number / offset information conversion data storage unit 330701.

  The glyph number / offset information conversion data storage unit 330701 stores glyph number / offset information conversion data generated according to the fifth embodiment. The glyph number / offset information conversion data stored in the glyph number / offset information conversion data storage unit 330701 is referred to by the offset acquisition unit 530002 as necessary.

(Glyph number / offset information conversion processing according to the sixth embodiment)
Next, specific processing contents in the image decoding apparatus according to the sixth embodiment will be described.

  FIG. 55 is a flowchart of glyph number / offset information conversion processing executed by the image decoding apparatus according to the sixth embodiment.

  The processing shown in the flowchart of FIG. 55 is realized by a processor functioning as the controller 3301 reading and executing a program stored in the storage device and controlling each unit shown in FIG. 54 and the like. The process shown in the flowchart of FIG. 55 is merely a specific example of the glyph number / offset information conversion process.

  Referring to FIG. 55, unit index calculation unit 530001 calculates unit index UnIdx based on input glyph number GlNum (step S340301). The unit index UnIdx is calculated according to the following equation (1), for example.

UnIdx = Int (GlNum / USIZE) Formula (1)
Here, Int (A / B) represents a quotient when the integer A is divided by the integer B. USIZE is the data unit size stored in the data unit size storage unit 2202051 when the glyph number / offset information conversion data is generated.

  Here, as a specific example, referring to FIG. 52, when the unit index corresponding to the glyph number “3” is calculated when USIZE is “2”, “Int (3/2)” is calculated. The unit index “1” is obtained.

  Returning to FIG. 55, next, the offset acquisition unit 530002 refers to the glyph number / offset information conversion data stored in the glyph number / offset information conversion data storage unit 330701, and corresponds to the UnIdx-th calculated in step S340301. Offset information is acquired (step S340302).

  Here, as a specific example, referring to FIG. 53, when an offset corresponding to the unit index “1” is acquired, an offset “83” is obtained.

  Returning to FIG. 55, the offset acquisition unit 530002 next outputs the offset information acquired in step S340302 to the code data acquisition unit 330403 (step S340303).

The glyph number / offset information conversion process is performed as described above.
(Decoding process in the image decoding apparatus according to the sixth embodiment)
Next, an entropy code decoding process executed by the image decoding apparatus according to the sixth embodiment will be described.

  FIG. 56 is a flowchart of entropy code decoding processing executed by the image decoding apparatus according to the sixth embodiment.

  The processing shown in the flowchart of FIG. 56 is realized by a processor functioning as the controller 3301 reading out and executing a program stored in the storage device and controlling each unit shown in FIG. 54 and the like. Note that the process shown in the flowchart of FIG. 56 is merely a specific example of the decoding process, and may be executed by changing the order of the steps, for example.

  Referring to FIG. 56, intra-unit block position calculation section 330401 calculates intra-unit block position B1Idx based on the input glyph number GlNum (step S340501). The intra-unit block position BIdx is calculated according to the following equation (2), for example.

BlIdx = Rem (GlNum / USIZE) (2)
Here, Rem (A / B) represents a remainder when the integer A is divided by the integer B. USIZE is the data unit size stored in the data unit size storage unit 2202051 when the glyph number / offset information conversion data is generated.

Here, the relationship between the glyph number and the intra-unit block position will be described using a specific example.
FIG. 57 is a diagram showing an example of the relationship between the glyph number and the block position in the unit.

  The relationship table 40 between glyph numbers and in-unit block positions shown in FIG. 57 is an example for explaining the concept, and the relationship table 40 is not specifically created.

  In the relationship table 40, a column 401 is glyph numbers 4011 to 4016 assigned to the glyphs included in the image data stored in the image data memory 1202 in ascending order from the top 0. A column 402 is the intra-unit block positions 4021 to 4026 that are uniquely calculated when the glyph number shown in the column 401 is specified. Specifically, for example, when USIZE is “2”, the block position in the unit of the block composed of the encoded data corresponding to the glyph number 4011 (“0”) is “0”. It is represented by an inner block position 4021. Similarly, the in-unit block position of the block constituted by the encoded data corresponding to the glyph number 4012 (“1”) is “1”, and is represented by the in-unit block position 4022 in the relation table 40. However, although the description will be repeated, the relationship table 40 is not specifically generated in the present embodiment.

  Returning to FIG. 56, next, in accordance with the processing start instruction from the controller 3301, the in-unit block position management unit 330402 initializes the number of processed blocks B1Num (substitutes 0) (step S340502), and processes the processed sub-blocks. The number DtNum is initialized (0 is substituted) (step S340503).

  Next, the code data acquisition unit 330403 refers to the encoded data stored in the code data storage unit 330501. At the start of processing, the encoded data is sequentially acquired bit by bit from the bit position indicated by the offset information input from the offset acquisition unit 530002, and the acquired encoded data is sequentially transmitted to the Huffman decoding processing step S340505. Deliver (step S340504).

  Next, the Huffman decoding unit 330404 refers to the Huffman dictionary stored in the Huffman dictionary storage unit 330502 based on the encoded data acquired in Step S340504, and decodes the Huffman code (Step S340505).

  Next, the intra-unit block position management unit 330402 determines whether or not the current processed block count B1Num is equal to the intra-unit block position B1Idx calculated in step S340501 (step S340506). If it is determined that they are equal (YES in step S340506), the decoded data output unit 330405 outputs the decoded data decoded in step S340505 (step S340507). On the other hand, if it is determined that they are not equal (NO in step S340506), the process proceeds to step S340508.

  Next, the intra-unit block position management unit 330402 adds 1 to the processed subblock number DtNum and updates it (step S340508), and whether the processed subblock number DtNum is equal to the data block size BSIZE (for example, 11). It is determined whether or not (step S340509). If it is determined that they are equal (YES in step S340509), the process advances to step S340510. On the other hand, if it is determined that they are not equal (NO in step S340509), the process proceeds to step S340504, and the next encoded data is acquired. Here, the data block size BSIZE is the data block size stored in the data block size storage unit 2202041 when generating the glyph number / offset information conversion data.

  Next, the intra-unit block position management unit 330402 updates the processed block number B1Num by adding 1 (step S340510), and determines whether or not the processed block number B1Num is equal to the data unit size USIZE (for example, 2). Is determined (step S340511). If it is determined that they are equal (YES in step S340511), the entropy code decoding process ends. On the other hand, if it is determined that they are not equal (NO in step S340511), the process proceeds to step S340503, the number of processed sub-blocks is initialized, and the next encoded data is acquired. Here, the data unit size USIZE is the data unit size stored in the data unit size storage unit 2202051 when the glyph number / offset information conversion data is generated.

  In the present embodiment, the processing amount in the decoding process can be made uniform by offsetting (jumping) the acquisition start position of the encoded data in accordance with the offset acquired in step S340302. In addition, it becomes unnecessary to sequentially decode all the encoded data from the beginning of the data in order to access the end portion of the encoded data.

  In the above description, since it is determined in step S340511 that the number of processed blocks B1Num is equal to the data unit size USIZE and the process is terminated, the decoded data to be output (the glyph to be output) Even after the corresponding decoded modified divided image data is output, the processing is continued until the number of processed blocks B1Num reaches the data unit size USIZE. For example, when the intra-unit block position BIdx is 0 and the unit size USIZE is 8, the encoded data is acquired from the acquisition start position according to the offset, and the decoded data is output sequentially until the decoding process for one block is completed. The decoding process for the subsequent seven blocks is redundant.

  In order to solve such a problem, the embodiment can be modified as shown below, for example. The output completion flag OutFlag is prepared in the in-unit block position management unit 330402, and when the processed block number B1Num is initialized in step S340502, the output completion flag OutFlag is also initialized and set to “0”. In step S340506, if the number of processed blocks B1Num is equal to the intra-unit block position BIdx, that is, if decoded data is recognized as an output target, the output flag is set to 1. If the processed block count B1Num is not equal to the data unit size USIZE in step S340511, it is determined whether or not the output flag OutFlag is “1” before proceeding to step S340503, and OutFlag is “1”. If so, the entropy code decoding process is terminated. If OutFlag is “0”, the process proceeds to step S340503. Thus, by modifying the entropy code decoding process, a redundant decoding process after outputting decoded data can be avoided.

  In order to obtain the same effect, the embodiment can be modified as follows. The output completion flag OutFlag is prepared in the in-unit block position management unit 330402, and when the processed block number B1Num is initialized in step S340502, the output completion flag OutFlag is also initialized and set to “0”. In step S340506, if the number of processed blocks B1Num is equal to the intra-unit block position BIdx, that is, if decoded data is recognized as an output target, the output flag is set to 1. In step S340511, instead of “determining whether or not the number of processed blocks B1Num and the data unit size USIZE are equal”, “determine whether or not the output flag OutFlag is 1”. . When the output flag OutFlag is 1, the entropy code decoding process is terminated. If the output completion flag OutFlag is not 1, the process proceeds to step S340503.

[Seventh Embodiment]
In the seventh embodiment, a modification of the glyph number / offset information conversion data generation unit according to the fifth embodiment is presented.

  The glyph number / offset information conversion data generation unit according to the seventh embodiment determines the data unit size USIZE based on the relationship between the table data capacity and the processing time.

(Data unit size determination method)
First, a method for determining the data unit size will be described using a conceptual diagram.

  FIG. 58 is a conceptual diagram showing an example of the relationship between the data unit size, table data capacity, and processing time.

  Referring to FIG. 58, the horizontal axis represents the data unit size, the value on the left side is small, and the value increases toward the right. The vertical axis on the left represents the table data capacity (capacity of glyph number / offset information conversion data), with the lower value being smaller and the larger the value being higher. The vertical axis on the right side represents the processing time required for the glyph number / offset information conversion process and the entropy code decoding process, with the lower value being smaller and increasing the higher.

  A graph 501 represented by a solid line represents the relationship between the data unit size and the table data capacity. As the data unit size increases, the table data capacity decreases. For example, if the table data capacity when the data unit size USIZE is “2” is 1000 bytes, the table data capacity when the data unit size USIZE is “8” is 250 bytes.

  On the other hand, a graph 502 represented by a dotted line represents the relationship between the data unit size and the processing time, and the processing time increases as the data unit size increases. For example, if the processing time when decoding all glyphs (blocks) once is averaged, the processing time when the data unit size USIZE is “2” is roughly 1.5 glyphs (blocks). It can be considered as the processing time required for decoding minutes (= (1 + 2) / 2). Similarly, the processing time when the data unit size USIZE is “8” can be considered as the processing time required for decoding 4.5 glyphs (blocks) (= (1 + 2 + 3 + 4 + 5 + 6 + 7 + 8) / 8). However, when considering an accurate decoding processing time, it is considered that the processing time per glyph (block) varies depending on the number of bits (variable length) of encoded data corresponding to one glyph (block). The above description is conceptual because it is necessary.

  As described above, in order to reduce the table data capacity, it is necessary to increase the data unit size USIZE, and in order to reduce the processing time, it is necessary to reduce the data unit size USIZE. In other words, it is necessary to solve the trade-off that occurs when pursuing the ideal of table data capacity and processing time. In the above-described embodiment, it is assumed that the system designer determines the data unit size USIZE in consideration of such a trade-off. In determining the data unit size USIZE, it is necessary to consider the data capacity overhead due to the table data capacity from the viewpoint of compression efficiency as well as the trade-off described above. That is, “data capacity of processed divided image data before encoding”, “encoded data capacity obtained by encoding, Huffman dictionary required for decoding, and data capacity of glyph number / offset information conversion data” Need to be considered. The glyph number / offset information conversion unit according to the present embodiment determines the data unit size USIZE in consideration of such a total data capacity.

(Configuration of glyph number / offset information conversion data generation unit according to the seventh embodiment)
FIG. 59 is a block diagram showing a detailed configuration of the glyph number / offset information conversion data generation unit according to the seventh embodiment.

  Referring to FIG. 59, the glyph number / offset information conversion data generation unit 5002 according to the seventh embodiment includes a code data size in addition to the configuration of the glyph number / offset information conversion data generation unit 5000 shown in FIG. A calculation unit 220226, a data unit size setting unit 220227, and a converted data size calculation unit 220228 are included.

  These components may be configured by a dedicated large-scale integration (LSI) that realizes the function of the image encoding device and a memory, or may be configured by other hardware.

  The code data size calculation unit 2202026 refers to the encoded data stored in the code data storage unit 120501 and calculates the encoded data size (data capacity). The code data size calculation unit 2202026 outputs the calculated encoded data size to the data unit size setting unit 220227.

  The conversion data size calculation unit 220228 calculates the data size (data capacity) of the glyph number / offset information conversion data created using a certain fixed data unit size. The conversion data size calculation unit 220228 outputs the calculated conversion data size to the data unit size setting unit 220227.

  The data unit size setting unit 220227 receives the encoded data size from the encoded data size calculation unit 220226 and the converted data size from the converted data size calculation unit 220228, respectively. The data unit size setting unit 220227 ends the glyph number / offset information conversion data generation process when a predetermined condition is satisfied using the input encoded data size and conversion data size. If the specified condition is not satisfied, the data unit size is updated, and the glyph number / offset information conversion data is reset (erased) once, and the glyph number / offset information conversion is performed again using the updated data unit size. Generate data. A specific example of the predetermined condition will be described later.

(Glyph number / offset information conversion data generation processing according to the seventh embodiment)
Next, specific processing contents of the glyph number / offset information conversion data generation unit in the image encoding device according to the seventh embodiment will be described.

  FIG. 60 is a flowchart showing a glyph number / offset information conversion data generation process executed by the glyph number / offset information conversion data generation unit according to the seventh embodiment.

  The processing shown in the flowchart of FIG. 60 is realized by a processor functioning as the controller 1201 reading and executing a program stored in the storage device and controlling each unit shown in FIG. 59 and the like. The process shown in the flowchart of FIG. 60 is merely a specific example of the glyph number / offset information conversion data generation process. For example, the order of the steps may be changed.

  Referring to FIG. 60, a data size calculation unit (not shown) calculates the data size (data capacity) OSSize of the processed divided image data (step S130821). The processed divided image data to be calculated here is processed divided image data before encoding, which is stored in the processed divided image data memory 1203. That is, the original data capacity before obtaining the compression effect by encoding is calculated.

  Next, the code data size calculation unit 220226 calculates the data size (data capacity) CSize of the encoded data stored in the code data storage unit 120501 (step S130822). That is, the compressed data capacity is calculated.

  Further, according to the processing start instruction from the control unit 120, the data unit size setting unit 220227 initializes (substitutes 1) the data unit size USIZE (step S130823).

  Next, the glyph number / offset information conversion data generation process (steps S130801 to S130812 in FIG. 49) described in the fifth embodiment is executed (step S130824). The data unit size setting unit 220227 calculates the data size (data capacity) TSize of the glyph number / offset information conversion data generated in step S130824 (step S130825).

  Next, the data unit size setting unit 220227 uses the processed divided image data size OSSize calculated in step S13021, the code data size CSize calculated in step S130822, and the converted data size TSSize calculated in step S130825, for example. The determination is made according to the following equation (3).

(CSize + TSSize) / OSSize ≦ (CSize / OSSize) × 1.2 Formula (3)
That is, the capacity ratio obtained by adding the conversion data size TSize to the code data size CSize with respect to the capacity ratio between the original (before encoding) processed divided image data size OSSize and the encoded code data size CSize. Then, it is determined whether or not it falls within a predetermined ratio (step S130826). If it is determined that it is within the predetermined ratio (YES in step S130826), the glyph number / offset information conversion data generation process is terminated. On the other hand, if it is determined that it does not fall within the predetermined ratio (NO in step S130826), the data unit size setting unit 220227 updates the data unit size USIZE by adding 1 (step S130830), and the already generated glyph The number / offset information conversion data is once reset (erased), the process proceeds to step S130824, and the glyph number / offset information conversion data generation process described in the fifth embodiment (steps S130801 to S130812 in FIG. 49). Execute.

As described above, the glyph number / offset information conversion data generation processing is performed.
By following the criterion of equation (3) used in step S130826, even if the data unit size USIZE is “1”, the conversion that occupies the entire compressed (encoded) data (including the converted data necessary for decoding) When the data size ratio is small (in the example of Expression (3), within 20%), the converted data is held as it is, without causing a large overhead and avoiding redundant decoding processing during decoding processing. can do. For example, when USIZE is “8”, when the ratio of the converted data size in the entire compressed (encoded) data is within a predetermined ratio (20% in the example of Expression (3)) for the first time, Although the average decoding processing time increases as compared to when USIZE is “1”, the ratio of the conversion data size in the entire compressed (encoded) data (including the conversion data necessary for decoding) is It can be prevented from becoming too large.

[Eighth Embodiment]
In the eighth embodiment, a modification of the image encoding device according to the fifth embodiment is presented.

  The image coding apparatus according to the fifth embodiment is that the image coding apparatus according to the eighth embodiment includes a glyph rearrangement unit that rearranges glyphs according to the input frequency (reference frequency) of glyph numbers. And different.

  FIG. 61 is a block diagram showing a configuration of the glyph rearrangement unit in the image encoding device according to the eighth embodiment.

  Referring to FIG. 61, glyph rearrangement unit 910 includes a text analysis unit 901, a frequency calculation unit 902, a table rearrangement unit 903, and an image data rearrangement unit 904. Note that these components may be configured by a dedicated LSI (Large-Scale Integration) that realizes the function of the image encoding device and a memory, or may be configured by other hardware.

  Text analysis unit 901 uses arbitrary text data, preferably text data (for example, e-mail) used for screen display in an apparatus (for example, a mobile phone) that implements an image decoding apparatus according to the sixth embodiment of the present invention. Etc.) is preferably input with a sufficient amount of text data sufficient to obtain statistical properties. The text analysis unit 901 analyzes the input text data, obtains character identification information, that is, character code and typeface identification information (see FIG. 20), and stores them in the character identification information / glyph number correspondence rule memory 1208. The glyph number used corresponding to the input text data is acquired with reference to the character identification information / glyph number correspondence rule. The text analysis unit 901 outputs the acquired glyph number to the frequency calculation unit 902.

  The frequency calculation unit 902 receives the glyph number from the text analysis unit 901. The frequency calculation unit 902 calculates the input frequency (reference frequency) of each glyph number for the input glyph number. That is, for the glyph numbers sequentially input corresponding to a large amount of text data, the frequency for each number is obtained. The frequency calculation unit 902 outputs the calculated frequency for each glyph number to the table rearrangement unit 903 and the image data rearrangement unit 904.

  The table rearrangement unit 903 receives the frequency for each glyph number from the frequency calculation unit 902. The table rearrangement unit 903 refers to the character identification information / glyph number correspondence rule stored in the character identification information / glyph number correspondence rule memory 1208, and according to the frequency for each input glyph number, in order of the glyph numbers in descending order of frequency. Rearrange the character identification information / glyph number correspondence rules (reconstruction). The table rearrangement unit 903 outputs the rearranged character identification information / glyph number correspondence rule, and the rearranged table of the character identification information / glyph number correspondence rule stored in the character identification information / glyph number correspondence rule memory 1208 Replace with

  The image data rearrangement unit 904 receives the frequency for each glyph number from the frequency calculation unit 902. The image data rearrangement unit 904 refers to the image data stored in the image data memory 1202 and rearranges the image data in the order of the most frequently used glyph numbers according to the frequency for each input glyph number (reconstruction). Here, it is assumed that the image data is a series of large-size image data composed of a plurality of continuous images (for example, 11 bytes) corresponding to glyphs (blocks), and images (for example, images corresponding to glyphs (blocks)) Sort by 11 bytes). The image data rearrangement unit 904 outputs the rearranged image data, and replaces the image data stored in the image data memory 1202 with the rearranged image data.

(Glyph sorting process)
Next, specific processing contents of the image encoding device according to the eighth embodiment will be described.

  FIG. 62 is a flowchart of the glyph rearrangement process executed by the glyph rearrangement unit in the image encoding device according to the eighth embodiment.

  The processing shown in the flowchart of FIG. 62 is realized by a processor functioning as the controller 1201 reading out and executing a program stored in the storage device and controlling each unit shown in FIG. 61 and the like. The process shown in the flowchart of FIG. 62 is merely a specific example of the glyph number / offset information conversion data generation process.

  Referring to FIG. 62, text analysis unit 901 displays arbitrary text data, preferably on a screen (for example, a mobile phone) in which an image decoding device according to the sixth embodiment of the present invention is mounted. A sample of text data to be used (such as e-mail) preferably analyzes a sufficient amount of text data to obtain statistical properties to obtain character identification information, ie, character code and typeface identification information. (See FIG. 20), referring to the character identification information / glyph number correspondence rule stored in the character identification information / glyph number correspondence rule memory 1208, the glyph number used corresponding to the input text data is acquired (see FIG. 20). Step S901).

  Next, the frequency calculation unit 902 calculates the input frequency (reference frequency) of each glyph number for the glyph number acquired in step S901 (step S902). That is, for the glyph numbers sequentially input corresponding to a large amount of text data, the frequency for each number is obtained.

  Next, the table rearrangement unit 903 refers to the character identification information / glyph number correspondence rule stored in the character identification information / glyph number correspondence rule memory 1208, and determines the frequency according to the frequency for each glyph number calculated in step S902. The character identification information / glyph number correspondence rules are rearranged in the order of many glyph numbers (reconstruction) (step S903).

  Next, the image data rearrangement unit 904 refers to the image data stored in the image data memory 1202, and rearranges the image data in the order of the most frequent glyph numbers according to the frequency for each glyph number calculated in step S902. (Reconstruction) (Step S904). Here, it is assumed that the image data is a series of large-size image data composed of a plurality of continuous images (for example, 11 bytes) corresponding to glyphs (blocks), and images (for example, images corresponding to glyphs (blocks)) Sort by 11 bytes).

(Overall Configuration of Image Encoding Device According to Eighth Embodiment)
The image coding apparatus according to the eighth embodiment of the present invention is a modification of the image coding apparatus according to the fifth embodiment, and therefore, with reference to FIG. The differences are described below.

  In the image coding apparatus according to the eighth embodiment, the configuration is substantially the same except that the glyph rearrangement unit 910 described above is added. First, the glyph rearrangement unit 910 executes glyph rearrangement processing, and the character identification information / glyph number after rearrangement is stored in the character identification information / glyph number correspondence rule memory 1208 and the image data memory 1202, respectively. The correspondence rule and the rearranged image data are stored, and the glyph number / offset information conversion data generation unit generates the glyph number / offset information conversion data. However, unlike the fifth embodiment, the operation of the data unit management unit 220205 is configured to change the data unit size in accordance with the glyph number. The operation of the data unit management unit 220205 will be described later as processing contents.

(Processing in Image Encoding Device According to Eighth Embodiment)
Since the image coding apparatus according to the eighth embodiment of the present invention is a modification of the image coding apparatus according to the fifth embodiment, the eighth embodiment will be described with reference to FIG. The processing of the image coding apparatus will be described. In the image encoding process executed by the image encoding apparatus according to the eighth embodiment, the flow of large processes is almost the same except that the above-described glyph rearrangement process is added.

  First, the glyph rearrangement unit 910 executes the glyph rearrangement process, and the character identification information / glyph after rearrangement is stored in the character identification information / glyph number correspondence rule memory 1208 and the image data memory 1202, respectively. The number correspondence rule and the rearranged image data are stored, and the glyph number / offset information conversion data generation unit generates the glyph number / offset information conversion data. However, at the start of processing (for example, before processing step S130801), “1” is stored as the data unit size USIZE in the data unit size storage unit 2202051. In addition, the data unit management unit 220205 determines whether or not the number of processed blocks B1Num and the data unit size USIZE are equal in processing step S130811. If it is determined that they are equal, a process of adding 1 to the data unit size USIZE and updating it (for example, immediately before step S130812) is added. That is, one glyph (block) is assigned to the first unit, but two glyphs (blocks) are assigned to the second unit. Similarly, the third unit has three glyphs (blocks). A glyph (block) is assigned. A specific example will be described later.

(Relationship between glyph number and unit index in the eighth embodiment)
Next, the relationship between the glyph number and the unit index in the eighth embodiment will be described using a specific example.

  FIG. 63 is a diagram illustrating an example of a relationship between a glyph number and a unit index according to the eighth embodiment.

  The relationship table 60 between glyph numbers and unit indexes is illustrated for explaining the concept, and does not specifically create the relationship table 60.

  In the relationship table 60, a column 601 is glyph numbers 6011 to 6026 assigned to the glyphs included in the image data (sorted) stored in the image data memory 1202 in ascending order from the top 0.

  A column 603 is unit indexes 6031 to 6046 that are uniquely calculated when the glyph number indicated by the column 601 is specified. Specifically, for example, when the original data size (processed divided image data size) constituting one glyph is 11 bytes, “11” is stored in the data block size storage unit 2202041 as the data block size BSIZE. . Further, as described above, the data unit size USIZE stored in the data unit size storage unit 2202051 is set to “1” at the start of processing, and thereafter, the data unit size USIZE is updated according to the data unit size updating process described above. At this time, when the glyph number / offset information conversion data is generated according to the fifth embodiment described above, the index of the unit composed of the encoded data corresponding to the glyph number 6011 (“0”) is “0”. In the relation table 60, it is represented by a unit index 6031. Also, the index of the unit composed of the encoded data corresponding to the glyph number 6012 (“1”) and the glyph number 6013 (“2”) is “1”, and in the relation table 60, the unit index 6032 and the unit index 6033 It is represented by Similarly, the index of the unit composed of the encoded data corresponding to the glyph number 6014 (“3”), the glyph number 6015 (“4”), and the glyph number 6016 (“5”) is “2”. 60 is represented by a unit index 6034, a unit index 6035, and a unit index 6036. However, although the description is repeated, the relationship table 60 is not specifically generated in the present embodiment. The relationship between the glyph number and the unit index taking the relationship table 60 as an example will be described again in the description of the ninth embodiment described later.

(Relationship between unit index and offset in the eighth embodiment)
Next, the relationship between the unit index and the offset in the case of following the eighth embodiment of the present invention will be described using a specific example.

  FIG. 64 is a diagram illustrating an example of a relationship between a unit index and an offset according to the eighth embodiment.

  In the relationship table 70, a column 701 indicates unit indexes 7011 to 7013, and a column 702 indicates offsets 7021 to 7023. In the unit index / offset relationship table 70, the unit index 701 is illustrated for explaining the concept. Specifically, an address to the head of the offset (offset 7021 (“0”)) is stored. And the offsets 7021 to 7023 (fixed order) may be stored in the access table data memory 1207.

  The unit indexes 7011 to 7013 correspond to the unit indexes 6031 to 6046 uniquely obtained from the glyph numbers 6011 to 6026 described in the relation table 60 in FIG. That is, once the glyph number is determined, the offset is uniquely determined.

  The offset 7021 (“0”) in the offset indicated by the column 702 is accessed with the offset set to “0” when accessing the block coded data 21 of FIG. 51 corresponding to the glyph number 6011 (“0”). Indicates what should be done. The offset 7022 (“43”) accesses the block encoded data 22 in FIG. 51 corresponding to the glyph number 6012 (“1”) and the block encoded data 23 corresponding to the glyph number 6013 (“2”). At this time, it is indicated that the offset should be accessed as “43”. Here, the unit of the offset value is a bit. That is, the offset “43” is the first bit position of the block encoded data 22 corresponding to the glyph number “1” (the first bit position of the sub-block encoded data 2201) in the encoded data indicated by the column 2 in FIG. ) Is an offset for accessing. In other words, it is the sum of the number of bits of the encoded data corresponding to the block encoded data 21.

  The relationship between the unit index and the offset taking the relationship table 70 as an example will be described again in the description of the ninth embodiment to be described later.

  As described above, the image coding apparatus according to the eighth embodiment performs the character stored in the character identification information / glyph number correspondence rule memory 1208 according to the glyph input frequency (reference frequency) in the image decoding apparatus. The identification information / glyph number correspondence rule is rearranged, and the image data stored in the image data memory 1202 is rearranged. Also, as the glyph number increases, the unit size is increased to create an access table. Thereby, in addition to the effect in the fifth embodiment and the effect in the sixth embodiment at the time of decoding, the access table can obtain the effect in the ninth embodiment to be described later at the time of decoding. Can be created.

[Ninth Embodiment]
In the ninth embodiment, an image decoding apparatus that performs decoding using the data encoded by the image encoding apparatus according to the eighth embodiment and the character identification information / glyph number correspondence rule will be described.

  Since the image decoding apparatus according to the ninth embodiment of the present invention is a modification of the sixth embodiment, the differences from the sixth embodiment will be described below with reference to FIG. .

  The image decoding device according to the ninth embodiment is substantially the same in configuration as the image decoding device according to the sixth embodiment. However, the operations of the unit index calculation unit 530001 and the in-unit block position calculation unit 330401 are different from those in the sixth embodiment, in accordance with different equations instead of the equations (1) and (2). The index and block position within the unit are calculated. The operations of the unit index calculation unit 530001 and the in-unit block position calculation unit 330401 will be described later as processing contents.

  Further, at the start of processing, the intra-unit block position management unit 330402 sets a value obtained by adding 1 to the unit index UnIdx calculated by the unit index calculation unit 530001 as the data unit size USIZE according to an instruction from the controller 3301.

(Processing content of the image decoding apparatus according to the ninth embodiment)
Next, specific processing contents of the image decoding device according to the ninth embodiment of the present invention will be described.

  In the image decoding process executed by the image decoding apparatus according to the ninth embodiment of the present invention, encoded data generated using the image encoding apparatus according to the above-described eighth embodiment, and character identification It is assumed that decoding is performed using information / glyph number correspondence rules.

  The image decoding process executed by the image decoding apparatus according to the ninth embodiment of the present invention is a modification of the image decoding process executed by the image decoding apparatus according to the above-described sixth embodiment. The difference from the sixth embodiment will be described below with reference to FIG.

  Referring to FIG. 55, the glyph number / offset information conversion process in the ninth embodiment is substantially the same as the glyph number / offset information conversion process in the sixth embodiment. is there. However, in the unit index calculation processing step S340301, when the unit index calculation unit 530001 calculates the unit index UnIdx based on the input glyph number GlNum, instead of the expression (1), for example, the following expression ( It is calculated by obtaining an integer that satisfies 4) and Equation (5).

UnIdx ≧ (−3 + SQRT (8 × GlNum + 9)) / 2 Formula (4)
UnIdx ≦ (−1 + SQRT (8 × GlNum + 1)) / 2 Equation (5)
Here, SQRT (A) represents the positive square root of the integer A. Further, only one integer that satisfies the equations (4) and (5) is uniquely obtained.

  Here, as a specific example, with reference to FIG. 63, when calculating the unit index UnIdx (2) corresponding to the glyph number “2”, GlNum = 2 is substituted into Expression (4) and Expression (5). When an integer satisfying the following expressions (6) and (7) is obtained, “1” (corresponding to the unit index 6033) is obtained as UnIdx (2).

UnIdx (2) ≧ (−3 + SQRT (8 × 2 + 9)) / 2 Equation (6)
UnIdx (2) ≦ (−1 + SQRT (8 × 2 + 1)) / 2 Equation (7)
Similarly, when the unit index UnIdx (8) corresponding to the glyph number “8” is calculated, the following formula (8) and formula (8) obtained by substituting GlNum = 8 into formula (4) and formula (5): When an integer satisfying Expression (9) is obtained, “3” (corresponding to the unit index 6039) is obtained as UnIdx (8).

UnIdx (8) ≧ (−3 + SQRT (8 × 8 + 9)) / 2 Equation (8)
UnIdx (8) ≦ (−1 + SQRT (8 × 8 + 1)) / 2 Formula (9)
Further, a specific example of the offset acquisition processing step S340302 will be described. Referring to FIG. 64, when an offset corresponding to the unit index “1” (corresponding to the unit index 7012) is acquired, the offset “43” (in the offset 7022) Equivalent)

  Next, referring to FIG. 56, the entropy code decoding process in the ninth embodiment is substantially the same as the entropy code decoding process in the sixth embodiment. However, at the start of processing, according to an instruction from the controller 3301, a value obtained by adding 1 to the unit index UnIdx calculated in the unit index calculation processing step S340301 is set as the data unit size USIZE.

  In addition, in the intra-unit block position calculation processing step S340501, when the intra-unit block position calculation unit 330401 calculates the intra-unit block position BIdx based on the input glyph number GlNum, the expression (2) is substituted. For example, it is calculated according to the following equation (10).

BlIdx = GlNum−UnIdx × (UnIdx + 1) / 2 Formula (10)
Here, UnIdx is the unit index calculated in unit index calculation processing step S340301.

Here, the relationship between the glyph number and the intra-unit block position will be described using a specific example.
FIG. 65 is a diagram showing an example of the relationship between the glyph number and the intra-unit block position in the ninth embodiment.

  The relationship table 80 between glyph numbers and intra-unit block positions is illustrated for explaining the concept, and does not specifically create the relationship table 80.

  Referring to FIG. 65, in relation table 80, column 801 corresponds to glyph numbers 8011 to 8026 that are assigned in ascending order from the top 0 to each glyph included in the image data stored in image data memory 1202.

  A column 803 is the intra-unit block positions 8031 to 8046 that are uniquely calculated when the glyph number indicated by the column 801 is specified. Specifically, for example, the intra-unit block position of a block composed of encoded data corresponding to the glyph number 8011 (“0”) is “0”, and in the relation table 80, the intra-unit block position 8031 is represented. The Similarly, the intra-unit block position of the block composed of the encoded data corresponding to the glyph number 8012 (“1”) is “0”, and is represented by the intra-unit block position 8032 in the relationship table 80. The relationship between the glyph numbers 8011 to 8026 indicated by the column 801 and the intra-unit block positions 8031 to 8046 indicated by the column 803 is uniquely derived by the above formula (9). Therefore, although the description is repeated, the relationship table 80 is not specifically generated in the present embodiment.

  In the present embodiment, similarly to the sixth embodiment, the processing amount in the decoding process is reduced by offsetting (jumping) the acquisition start position of the encoded data according to the offset acquired in step S340302. It becomes possible, and it becomes unnecessary to sequentially decode all the encoded data from the beginning of the data in order to access the end portion of the encoded data.

  In the above description, since it is determined in step S340511 that the number of processed blocks B1Num is equal to the data unit size USIZE and the process is terminated, the decoded data to be output (the glyph to be output) Even after the corresponding decoded modified divided image data is output, the processing is continued until the number of processed blocks B1Num reaches the data unit size USIZE. For example, when the intra-unit block position BIdx is 0 and the unit index UnIdx is 7 (unit size USIZE is 8), the encoded data is acquired from the acquisition start position according to the offset, and the decoding process for one block is completed. The decoded data may be output sequentially until the subsequent 7 blocks of decoding are redundant.

  In order to solve such a problem, the embodiment can be modified as shown below, for example, as in the modification described in the sixth embodiment. The output completion flag OutFlag is prepared in the in-unit block position management unit 330402, and when the processed block number B1Num is initialized in step S340502, the output completion flag OutFlag is also initialized and set to “0”. In step S340506, if the number of processed blocks B1Num is equal to the intra-unit block position BIdx, that is, if decoded data is recognized as an output target, the output flag is set to 1. If the processed block count B1Num is not equal to the data unit size USIZE in step S340511, it is determined whether or not the output flag OutFlag is “1” before proceeding to step S340503, and OutFlag is “1”. If so, the entropy code decoding process is terminated. If OutFlag is “0”, the process proceeds to step S340503. Thus, by modifying the entropy code decoding process, a redundant decoding process after outputting decoded data can be avoided.

  In order to obtain the same effect, the embodiment can be modified as follows. The output completion flag OutFlag is prepared in the in-unit block position management unit 330402, and when the processed block number B1Num is initialized in step S340502, the output completion flag OutFlag is also initialized and set to “0”. In step S340506, if the number of processed blocks B1Num is equal to the intra-unit block position BIdx, that is, if decoded data is recognized as an output target, the output flag is set to 1. In step S340511, instead of “determining whether or not the number of processed blocks B1Num and the data unit size USIZE are equal”, “determine whether or not the output flag OutFlag is 1”. . When the output flag OutFlag is 1, the entropy code decoding process is terminated. If the output completion flag OutFlag is not 1, the process proceeds to step S340503.

  Also, in the ninth embodiment, according to the eighth embodiment, encoded data (corresponding to glyphs) that is decoded more times is obtained by setting glyphs having a high reference frequency as young glyph numbers. Since the index UnIdx (calculated from the equations (5) and (6)) is a small value, the data unit size USIZE (= UnIdx + 1), that is, the maximum value of the block position BIdx in the unit is also a small value, which is processed from a statistical viewpoint. Time can be reduced.

  In the fifth, seventh, and eighth embodiments described above, the code length is calculated when the processed divided character image data is input in the Huffman code length calculation unit 220201 and the Huffman code length calculation processing step S130804. However, it is also possible to calculate the code length of the input encoded data with reference to the Huffman dictionary using the encoded data created in advance in the entropy encoding processing step S1308 as an input.

  In the seventh embodiment described above, an example in which 1.2 is fixedly multiplied on the right side of Expression (3) has been described. However, the value of “1.2” represents the overhead coefficient Wgt, The value of the overhead coefficient Wgt is not limited to “1.2”. That is, the overhead coefficient Wgt is a coefficient for limiting the extent to which the reduction of the compression ratio is allowed by adding overhead compared to the compression ratio when no overhead is present, and is a value of 1.0 or less Is currently impossible (assuming that the overhead is always larger than 0), and the system designer will determine a value larger than 1.0 according to the purpose. . Here, if a value larger than 2.0 is used, the overhead becomes equal to or larger than the size of the compressed data, so the value of the overhead coefficient Wgt is larger than 1.0 and smaller than 2.0. It is preferable.

  Furthermore, it is possible to provide a program that causes a computer to execute the above-described image encoding process and / or image decoding process. Such a program can be recorded on a computer-readable recording medium such as a flexible disk, a CD-ROM, a ROM, a RAM, and a memory card attached to the computer and provided as a program product. Alternatively, the program can be provided by being recorded on a recording medium such as a hard disk built in the computer. A program can also be provided by downloading via a network.

  The program according to the present invention is a program module that is provided as a part of a computer operating system (OS) and calls necessary modules in a predetermined arrangement at a predetermined timing to execute processing. Also good. In that case, the program itself does not include the module, and the process is executed in cooperation with the OS. A program that does not include such a module can also be included in the program according to the present invention.

  The program according to the present invention may be provided by being incorporated in a part of another program. Even in this case, the program itself does not include the module included in the other program, and the process is executed in cooperation with the other program. Such a program incorporated in another program can also be included in the program according to the present invention.

  The provided program product is installed in a program storage unit such as a hard disk and executed. The program product includes the program itself and a recording medium on which the program is recorded.

  The embodiment disclosed this time should be considered as illustrative in all points and not restrictive. The scope of the present invention is defined by the terms of the claims, rather than the description above, and is intended to include any modifications within the scope and meaning equivalent to the terms of the claims.

  The present invention can be applied to an apparatus having a text processing function such as a personal computer. Further, the present invention can be applied to, for example, a portable device having a text processing function such as a mobile phone, a PDA (Personal Digital Assistants), a portable game device, and a home appliance having a display device.

2 is a diagram illustrating a specific example of a hardware configuration of a mobile phone 1. FIG. It is a block diagram which shows the specific example of a function structure of the image coding apparatus concerning 1st Embodiment. FIG. 11 is a block diagram illustrating a specific example of a configuration of an image processing unit 1209. 5 is a block diagram showing a specific example of the configuration of an access table data generation unit 1206. FIG. It is a figure showing the specific example of character image data. 5 is a diagram illustrating a specific example of image data stored in an image data memory 1202. FIG. It is a figure showing the specific example of a character identification information and a glyph number correspondence rule. It is a figure showing the specific example of access table data. It is a flowchart which shows the encoding process concerning 1st Embodiment. It is a flowchart which shows the division process of the image data in step S1303. It is a figure showing the specific example of character image data. It is a figure showing the specific example of division | segmentation character image data. It is a figure showing the specific example of division | segmentation character image data. It is a figure showing the specific example of character image data. It is a figure explaining arrangement | positioning of character image data. It is a flowchart which shows the calculation process of exclusive OR in step S1304. It is a figure showing the specific example of process division | segmentation character image data. It is a flowchart which shows the production | generation process of the access table in step S1308. It is a figure showing the specific example of character identification information and glyph number conversion data. It is a figure showing the specific example of a response | compatibility with a character code and an internal character code. It is a figure explaining the technique converted into an internal character code from a character code and typeface identification information. It is a figure showing the specific example of a status table. It is a figure showing the specific example of a 1st auxiliary table. It is a figure showing the specific example of a status table. It is a figure showing the specific example of a 2nd auxiliary table. It is a figure explaining the characteristic of character image data. It is a figure explaining the characteristic of character image data. It is a figure explaining the calculation result of the exclusive OR of character image data. It is a figure explaining the calculation result of the exclusive OR of character image data. It is a block diagram which shows the specific example of a function structure of the image coding apparatus concerning 2nd Embodiment. FIG. 11 is a block diagram illustrating a specific example of a configuration of an image processing unit 1209. It is a flowchart which shows the encoding process concerning 2nd Embodiment. 16 is a flowchart illustrating image data division processing in step S2503. It is a flowchart which shows the calculation process of exclusive OR in step S2504. It is a figure explaining rotation operation. It is a figure explaining the calculation result of the exclusive OR of character image data. It is the schematic of the hardware constitutions of a text processing apparatus. It is a flowchart which shows the image decoding process in a text processing apparatus. It is a block diagram which shows the specific example of a function structure of the image decoding apparatus concerning 3rd Embodiment. FIG. 20 is a block diagram illustrating a specific example of a configuration of an image processing unit 3307. 5 is a block diagram illustrating a specific example of a configuration of an access table data conversion unit 3305. FIG. It is a flowchart which shows the decoding process performed with an image decoding apparatus in step S4702. It is a flowchart which shows the conversion process to a glyph number in step S3402. It is a flowchart which shows the calculation process of exclusive OR in step S3408. It is a flowchart which shows the integration process of the division | segmentation character image data in step S3409 in 3rd Embodiment. It is a block diagram which shows the specific example of a function structure of the image decoding apparatus concerning 4th Embodiment. It is a flowchart which shows the integration process of the division | segmentation character image data in step S3409 in 4th Embodiment. It is a block diagram which shows the detailed structure of the glyph number / offset information conversion data generation part which concerns on 5th Embodiment. It is a flowchart which shows the glyph number / offset information conversion data generation process performed by the glyph number / offset information conversion data generation unit according to the fifth embodiment. It is a figure which shows an example of a Huffman dictionary. It is a figure which shows an example of Huffman encoding. It is a figure which shows an example of the relationship between a glyph number and a unit index. It is a figure which shows an example of the relationship between a unit index and offset. It is a block diagram which shows the structure of the image decoding apparatus which concerns on 6th Embodiment. It is a flowchart of the glyph number and offset information conversion process performed with the image decoding apparatus which concerns on 6th Embodiment. It is a flowchart of the entropy code decoding process performed with the image decoding apparatus which concerns on 6th Embodiment. It is a figure which shows an example of the relationship between a glyph number and a block position in a unit. It is a conceptual diagram which shows an example of the relationship between a data unit size, table data capacity, and processing time. It is a block diagram which shows the detailed structure of the glyph number / offset information conversion data generation part which concerns on 7th Embodiment. It is a flowchart which shows the glyph number / offset information conversion data generation process performed by the glyph number / offset information conversion data generation unit according to the seventh embodiment. It is a block diagram which shows the structure of the glyph rearrangement part in the image coding apparatus which concerns on 8th Embodiment. It is a flowchart of the glyph rearrangement process performed in the glyph rearrangement part in the image coding apparatus which concerns on 8th Embodiment. It is a figure which shows an example of the relationship between the glyph number and unit index in 8th Embodiment. It is a figure which shows an example of the relationship between the unit index and offset in 8th Embodiment. It is a figure which shows an example of the relationship between the glyph number and block position in a unit in 9th Embodiment. It is a figure which shows the specific example of the hardware constitutions of PC3. It is a figure explaining addition of process division | segmentation character image data. It is a figure explaining addition of process division | segmentation character image data. It is a figure explaining addition of process division | segmentation character image data. It is a figure explaining addition of process division | segmentation character image data.

Explanation of symbols

  1 mobile phone, 2 recording medium, 3 PC, 101 CPU, 103 ROM, 105 RAM, 107 hard disk drive, 109 reading unit, 110 communication unit, 120 control unit, 130 storage unit, 140 input / output unit, 142 key code input device 144 display, 146 microphone, 148 speaker, 149 camera, 901 text analysis unit, 902 frequency calculation unit, 903 table rearrangement unit, 904 image data rearrangement unit, 910 glyph rearrangement unit, 1201 controller, 1202 image data memory, 1203 Processing division image data memory, 1204 Entropy encoding unit, 1205 Encoded data memory, 1206 Access table data generation unit, 1207 Access table data memory, 1208 Character recognition Information / glyph number correspondence rule memory, 1209 image processing unit, 1210 data bus, 2201 character identification information / glyph number conversion data generation unit, 2202 glyph number / offset information conversion data generation unit, 2203 data bus, 2410 flag data memory, 2701 Image computing unit, 2702 first character image data memory, 2703 second character image data memory, 2704 first divided character image data memory, 2705 second divided character image data memory, 2706 first processed divided character image data memory, 2707 first 2-processed divided character image data memory, 2708 capacity prediction unit, 2709 data bus, 3301 controller, 3302 encoded data memory, 3303 entropy code decoding unit, 3304 processed divided character image data memory, 3305 Access table data conversion unit, 3306 access table data memory, 3307 image processing unit, 3308 character image data memory, 3309 data bus, 3610 flag data memory, 3801 image operation unit, 3802 character image data memory, 3803 divided character image data memory, 3804 Processing division character image data memory, 3805 data bus, 4600 instruction device, 4601 controller, 4602 text data memory, 4603 image decoding device, 4604 display device, 4606 storage device, 4605 data bus, 4801 image operation unit, 4802 character image data Memory, 4803 divided character image data memory, 5000 glyph number / offset information conversion data generation unit, 5002 glyph number / offset information conversion data Generation unit, 5101 Character identification information / glyph number conversion unit, 5102 Glyph number / offset information conversion unit, 5103 Data bus, 5300 Glyph number / offset information conversion unit, 120501 Code data storage unit, 120502 Huffman dictionary storage unit, 220201, 20221 Huffman code length calculation unit, 220202, 220222 access pointer update unit, 220203 access pointer output unit, 220204 data block management unit, 220226 code data size calculation unit, 220227 data unit size setting unit, 220228 conversion information data size calculation unit, 220205 data Unit management unit, 330401 In-unit block position calculation unit, 330402 In-unit block position management unit, 330403 Code data acquisition unit , 330404 Huffman decoding unit, 330405 decoded data output unit, 330501 code data storage unit, 330502 Huffman dictionary storage unit, 330701 glyph number / offset information conversion data storage unit, 530001 unit index calculation unit, 530002 offset acquisition unit, 2202041 Data block size Storage unit, 2202051 Data unit size storage unit.

Claims (33)

An image encoding device that generates code data from a character image composed of a plurality of consecutive characters ,
Encoding processing means for reading the character image to be processed for each sub-block data having a predetermined reading size and variable-length encoding the encoded data for each sub-block data;
Block data management means for managing the processing status of the sub-block data and managing the processing for block data corresponding to a character image of one character composed of a predetermined number of sub-block data ;
Unit data management means for managing the processing status of the block data and managing processing for unit data composed of a predetermined number of block data ;
Access pointer updating means for updating an access pointer for accessing a position corresponding to the unit data of the code data;
Access pointer output means for outputting the access pointer ;
Code length calculating means for calculating the code length of the variable-length encoded data for each sub-block data ;
The access pointer updating means adds an access pointer by adding the code length of the variable length encoded data for each of the sub-block data corresponding to the unit data calculated by the code length calculating means. Updated,
The image encoding apparatus according to claim 1, wherein the access pointer output means outputs the access pointer in response to detecting completion of encoding for each block data and for each unit data.   The access pointer update unit updates the access pointer by setting a data size obtained by calculating the data size of the entire encoded data already encoded by the encoding processing unit as a new access pointer. Item 2. The image encoding device according to Item 1. Further comprising a storage means for storing in association with the access pointer and the code data, the image coding apparatus according to claim 1. The image coding apparatus according to claim 3 , wherein the coding processed by the coding processing means is Huffman coding. When the access pointer output means detects completion of encoding for each block data and for each unit data,
The sub-block data processed by the encoding processing means corresponds to a predetermined position in the block size, and
The image coding apparatus according to claim 1 or 3 , wherein the block data is to detect that the block data corresponds to one predetermined position in the unit size. The image encoding device according to claim 5 , wherein one position where the sub-block data should fall within the block size is a head position within the block size. The image encoding device according to claim 5 , wherein one position to which the block data should fall within the unit size is a head position within the unit size. One position where the sub-block data should fall within the block size is a head position within the block size, and
The image encoding device according to claim 5 , wherein one position to which the block data should fall within the unit size is a head position within the unit size. The image coding apparatus, wherein is referred to when performing the variable length coding process having a variable length code dictionary storage means for storing the variable-length code dictionary, the image coding apparatus according to claim 3. The image encoding device according to claim 9 , wherein the variable-length code dictionary is a Huffman dictionary generated according to the appearance frequency of the sub-block data. The image encoding device includes:
Code data size calculation means for calculating the data capacity of the entire encoded code data;
An access pointer data size calculating means for calculating a data capacity of the entire output access pointer;
And code data size the calculated, by using the access pointer data size the calculated, setting the predetermined unit size, further comprising a unit size setting means, according to claim 1 or claim 3 Image encoding device. The unit size setting means sets a predetermined processing start unit size at the start of processing of the image encoding device,
The access pointer data size calculation means calculates an access pointer data size for every sub-block data to be encoded every time the access pointer generation process is completed,
The unit size setting means satisfies the predetermined condition that the calculated access pointer data size, the code data size, and the original data size that is the data capacity of all the sub-block data to be encoded In such a case, the image encoding process according to claim 11 , wherein the image encoding process is terminated, and if the predetermined condition is not satisfied, the unit size is updated according to a predetermined rule. The unit size for setting at the start of processing by the unit size setting means is “1”.
The predetermined rule that the unit size setting means follows when updating the unit size is to add “1” to the current unit size,
The predetermined condition to be followed when the unit size setting means determines whether to end the image encoding process or to update the unit size is:
When the original data size is OSSize, the code data size is CSize, the access pointer data size is TSize, and the overhead coefficient is Wgt,
(CSize + TSSize) / OSSize ≦ (CSize / OSSize) × Wgt
The image encoding device according to claim 12 , wherein the image encoding device satisfies the condition: The image coding apparatus according to claim 13 , wherein the overhead coefficient Wgt is a value larger than "1.0" and smaller than "2.0". The image encoding device includes:
A frequency calculating means for calculating the appearance frequency for each block data in all the sub-block data to be encoded;
The block data rearranging unit that rearranges the order in units of blocks in all the sub-block data to be encoded according to the appearance frequency calculated by the frequency calculating unit. the image coding apparatus according to 3. The image code according to claim 15 , wherein the block data rearranging means rearranges so that the appearance frequency calculated by the frequency calculation means is higher, and the lower appearance frequency is rearward. Device. The unit data management means manages the processing status of the block data and updates the predetermined unit size according to a predetermined rule every time processing for unit data defined by the predetermined unit size is completed. The image encoding device according to claim 15 or 16 . The image encoding device according to claim 17 , wherein the rule for updating the predetermined unit size is to add “1” to the current unit size. An image decoding device that decodes code data in which a character image consisting of a plurality of characters is encoded ,
Block data information acquisition means for acquiring information specifying block data corresponding to a character image for one character ;
The block data is composed of a predetermined number of sub-block data that is the read size in the image encoding device, unit data is composed of a predetermined number of the block data, and corresponds to the predetermined unit data of the code data An access pointer storing means for storing an access pointer obtained by adding a code length for each variable length-encoded sub-block data as an access pointer for accessing a position ;
A unit data access pointer calculation means for calculating with reference to access pointer stored the access pointer to the unit data including the corresponding block data prior SL acquired block data information, said access pointer storing means,
Block data position information calculating means for calculating information related to a position in which the block data corresponding to the acquired block data information is included in the unit data;
Decoding means for sequentially decoding the code data in block data units from a start position according to the calculated unit data access pointer;
Decoded data output means for outputting the decoded decoded data,
The decoded data output means detects that the processing status of decoded block data composed of a set of decoded sub-block data decoded by the decoding means corresponds to the specified block data. An image decoding apparatus that outputs decoded data according to the above. 20. The image decoding device according to claim 19 , wherein the decoding processed by the image decoding device is decoding of code data subjected to variable length coding. 21. The image decoding apparatus according to claim 20 , wherein the decoding processed by the image decoding apparatus is Huffman decoding for Huffman-encoded code data. The unit data access pointer calculating means includes
When the unit data access pointer is UnIdx, the information specifying one block data is GlNum, the predetermined unit size is USIZE, Int (A / B), and the quotient obtained by dividing the integer A by the integer B In addition,
UnIdx = Int (GlNum / USIZE)
The image decoding device according to claim 19 or 20 , wherein the unit data access pointer is calculated according to the mathematical formula: The unit data block data position information calculating means includes:
The block data position information in the unit data is BIdx, the information specifying the one block data is GlNum, the predetermined unit size is USIZE, Rem (A / B), and the remainder when the integer A is divided by the integer B If
BlIdx = Rem (GlNum / USIZE)
The image decoding device according to claim 19 or 20 , wherein the block data position information in the unit data is calculated according to the mathematical formula: Detecting that the decoded data corresponds to the designated block data,
Detects that the intra-unit block position information of the decoded block data sequentially decoded from the start position according to the unit data access pointer corresponds to the intra-unit data block position information calculated by the unit data intra-block position information calculating means. The image decoding device according to claim 19 or 20 , wherein 25. The image decoding device according to claim 24 , wherein the image decoding device ends decoding processing at a time when the predetermined condition is not satisfied after outputting decoded data while the predetermined condition is satisfied. The image decoding device according to claim 19 , further comprising variable length code dictionary storage means for storing a variable length code dictionary that is referred to when decoding variable length code data. 27. The image decoding device according to claim 26 , wherein the variable length code dictionary is a Huffman dictionary generated according to the appearance frequency of the sub-block data. The unit data access pointer calculating means includes
When the unit data access pointer is UnIdx, the information specifying the one block data is GlNum, and SQRT (A) is the positive square root of the integer A,
UnIdx ≧ (−3 + SQRT (8 × GlNum + 9)) / 2 and UnIdx ≦ (−1 + SQRT (8 × GlNum + 1)) / 2
The image decoding device according to claim 19 or 20 , wherein the unit data access pointer is calculated by calculating an integer that satisfies the following formula. The unit data block data position information calculating means includes:
When the block data position information in the unit data is BlIdx, the information specifying the one block data is GlNum, and the unit data access pointer is UnIdx,
BlIdx = GlNum−UnIdx × (UnIdx + 1) / 2
The image decoding device according to claim 19 or 20 , wherein the block data position information in the unit data is calculated according to the mathematical formula: A program for causing a computer having a calculation unit to execute an image encoding process for generating code data from a character image in which a plurality of characters are continuous ,
The program is for the arithmetic unit.
Reading the character image to be processed for each sub-block data having a predetermined read size, and variable-length encoding the encoded data for each sub-block data;
Manages the processing status of the previous SL sub-block data, which is composed of a predetermined number of sub-block data, the step of managing the processing for block data corresponding to one character character image,
It manages the processing status of the previous SL block data, comprising the steps of: managing a processing for unit data composed of a predetermined number of block data,
Calculating a code length of the variable-length encoded data for each sub-block data;
The position corresponding to the unit data of the code data is accessed by adding the calculated code length of the variable-length encoded data for each of the sub-block data corresponding to the unit data. Updating an access pointer for:
To execute the steps of outputting the pre-Symbol access pointer,
The image encoding program characterized in that the step of outputting the access pointer outputs the access pointer in response to detecting completion of encoding for each block data and for each unit data. A program for causing a computer having a calculation unit to execute an image decoding process for decoding code data obtained by encoding a character image including a plurality of characters ,
The program is for the arithmetic unit.
Obtaining information specifying block data corresponding to a character image for one character ;
The block data is composed of a predetermined number of sub-block data that is the read size in the image encoding device, unit data is composed of a predetermined number of the block data, and corresponds to the predetermined unit data of the code data Storing an access pointer obtained by adding a code length for each variable length encoded sub-block data as an access pointer for accessing a position ;
Calculating an access pointer to the unit data including the block data corresponding to the previous SL acquired block data information, by referring to the stored access pointer,
Calculating before Symbol the unit data, information about the position that contains the corresponding block data in the acquired block data information,
A step of sequentially decoded in block data units from the starting position before Symbol code data, according the calculated unit data access pointer,
To execute the steps of outputting the decoded data from pre Symbol decoding,
The step of outputting the decoded data is to detect that the processing status of the decoded block data configured by the set of the decoded decoded sub-block data corresponds to the specified block data. In response, an image decoding program that outputs decoded data. An image encoding method for generating code data from a character image consisting of a plurality of consecutive characters ,
Reading the character image to be processed for each sub-block data having a predetermined read size, and variable-length encoding the encoded data for each sub-block data;
Managing the processing status of the sub-block data, and managing the processing for block data corresponding to a character image of one character composed of a predetermined number of sub-block data ;
Managing the processing status of the block data to manage the processing for unit data composed of a predetermined number of block data ;
Calculating a code length of the variable-length encoded data for each sub-block data;
The position corresponding to the unit data of the code data is accessed by adding the calculated code length of the variable-length encoded data for each of the sub-block data corresponding to the unit data. Updating an access pointer for:
Outputting the access pointer,
The step of outputting the access pointer outputs the access pointer in response to detecting the completion of encoding for each block data and for each unit data. An image decoding method for decoding code data in which a character image composed of a plurality of characters is encoded ,
Obtaining information specifying block data corresponding to a character image for one character ;
The block data is composed of a predetermined number of sub-block data that is the read size in the image encoding device, unit data is composed of a predetermined number of the block data, and corresponds to the predetermined unit data of the code data Storing an access pointer obtained by adding a code length for each variable length encoded sub-block data as an access pointer for accessing a position ;
Calculating an access pointer to the unit data including the block data corresponding to the previous SL acquired block data information, by referring to the stored access pointer,
Calculating information related to a position where block data corresponding to the acquired block data information is included in the unit data;
Sequentially decoding the code data in block data units from a start position according to the calculated unit data access pointer;
Outputting the decrypted decrypted data,
The step of outputting the decoded data is to detect that the processing status of the decoded block data configured by the set of the decoded decoded sub-block data corresponds to the specified block data. In response, an image decoding method characterized by outputting decoded data.

Images