KR20020069857A - Encoded image data service method for virtual machine - Google Patents

Abstract

PURPOSE: A compressed image data service method for a virtual machine is provided to utilize a small memory effectively, compose contents over the limit of the virtual machine, and transmit image data of equal information faster. CONSTITUTION: In a compressed image data service method for a virtual machine, a process for generating compressed image data for the virtual machine includes the steps of loading and analyzing images(S402,S404), carrying out the compression routine on the bases of the image information extracted in the previous step, wherein the number of continuously generated equal color information is displayed for the color information after header(S406-S409,S411), processing the color information if the number of the repeated color information is higher than a predetermined threshold value(S410), and repeating the second and third steps.

Description

Compressed image data service method for virtual machines {ENCODED IMAGE DATA SERVICE METHOD FOR VIRTUAL MACHINE}

The present invention relates to a method for generating and restoring compressed image data for a virtual machine (VM). More particularly, the present invention relates to a method for generating and restoring compressed image data for a virtual machine (VM). And an image data compression system for a VM in a wireless communication network that can be released.

A configuration of a game service system using image data for a general virtual machine (VM) through a wireless communication network will be described with reference to FIG. 1.

In recent years, content services using mobile communication have been actively carried out by domestic mobile communication companies, which serves to deliver content and services to mobile devices through wireless standard protocols such as WAP (Wireless Application Protocol). To this end, as shown in FIG. 1, a VM (Virtual Machine) server 500 as a content provider that provides content services from retail to investment information service sectors and a mobile switching network 300 of mobile communication providers should be included. do.

The wireless Internet contents service has been introduced into various fields such as news, stock information, TV programs, and weather data, starting with an e-mail service. In particular, in the case of games, image data transmission has become a big problem.

Wireless Internet services such as games can be broadly divided into download services and WAP / ME (Mobile Explorer) services. Among them, download service is applied to games such as JAVA game or GVM (General Virtual Machine), but keeps connection only when downloading, and WAP / ME service allows users to play WAP game or get information while connected to wireless internet. .

The network configuration of the WAP service will be described in more detail with reference to FIG. 1. The user terminal 100 is connected to a wireless base station network, and is connected to a mobile switching network 30 of a mobile communication provider through a wireless internet network 200. Bar, through the switch 310 of the mobile switching network via the IWF equipment, which is the network interlocking device 320, to separate the voice and WAP service, and then the VM server of the content provider to provide content through the general Internet network (400) ( Data from 500). At this time, there is a WAP gateway 330 in the mobile switching network, which is responsible for protocol conversion between heterogeneous protocols (eg, HTTP and WAP).

However, there is a limit to a service that applies a standard protocol such as WAP. In other words, the WAP method can use services such as wireless Internet games only when the connection between the user's mobile phone and the server is maintained, which is a significant obstacle in view of the slow speed and expensive usage rates of the current domestic wireless network. In order to provide dynamic contents that these standard protocols do not support, a platform for downloading and executing an application program to a mobile terminal is required. Such a platform includes a general virtual machine (GVM) or a kilo virtual machine (KVM). . The VM is a solution that can download games and embed them in a mobile phone after connecting to a network using a WAP method. These services allow users to play graphics games much faster, more lively, and better than WAP, just like mobile phone games. That is, in order to download and execute an application program from a terminal, a VM capable of interpreting and executing the application program must be implemented.

To this end, the VM terminal 100 includes a VM module 110 (e.g., a SWAP module) for downloading, which facilitates porting in the mobile communication and implements the purpose of standardizing the interface with the system. Memory 120 of the script. That is, the user terminal 100 may not only perform a normal wireless telephone function but also have a browser such as WML (Wireless Markup Language), HDML (Handheld Device Markup Language), or ME to display web contents. I also have

On the other hand, the VM server 500 provides a service such as a WML (Wireless Markup Language) page on a WAP or an HTML page of a ME, and selects a VM script. Download server 520 that supports downloading and leaves a record for future billing for each download, and game time enables real-time network and saves the ranking and score record of game server users. It includes a network game server 530 having information about. The network game server 530 may include a login server (not shown) for designating a group for each user in a log-in state of the user, a database server (not shown) that stores data about the user and time used, and the like. It may be configured as a connection server (not shown) that delivers each game data and provides a service for each game.

The VM SDK 600 collectively refers to a program tool for writing a VM script operating in a VM, and is composed of a compiler, an emulator, and an image and audio data writing program.

Now, the flow of a game service using a conventional VM image data as compared to the present invention will be described with reference to FIG.

As shown in FIG. 2, first, general image contents are produced by the VM SDK 600 (S210). That is, a content program is produced in a predetermined format using general image data desired by a wireless communication user. In the case of general image data, compression is performed after production, but in the case of VM contents, compression is not performed.

When the wireless communication user accesses the WAP server 510 of the VM server using his terminal 100 and selects a menu and requests the VM content program (S220), the wireless terminal transmits the request according to the request of step S220. The server 510 accesses the download server 520 to check whether there is a VM content program requested by the user (S230), generates program information, and transmits the information to the user's terminal (S240). At this time, the terminal grants access to the download server.

Now, the user terminal 100 requests the download of the VM program to the VM download server 520 (S250), and the download server transmits the VM program (S260).

The user terminal which has downloaded the VM program executes the program and displays the general image (S280). In this case, the user terminal decompresses the received compressed content program using a separate decompression program, and then displays the content on the display device.

However, in the image data compression technology, in order to convert the compressed data into the original image data, a separate decompression program made by hardware / software must be embedded in the mobile phone in the form of a chip, which increases the manufacturing cost of the terminal. . Moreover, this compression method was also the case of the existing general image data contents, and there was no compression in the VM method.

In addition, since the decompression program is not applied to all image data programs, software developers using image data have to use only compression programs suitable for their programs.

In addition, the conventional decompression program only performs the function of restoring the compressed data, but cannot perform the integrated management of various image data used in the VM. In other words, only one picture was compressed and decompressed. The conventional decompression program can be used in a WAP (Wireless Application Protocol) game using only one image, but there is a problem that cannot be used in a VM game provided with fast screen switching and various images.

The present invention has been made to solve the above problems, the object of the present invention is to avoid the need for a separate program for decompression to prevent an increase in the manufacturing cost of the terminal, and to compress the content of several pictures to produce the content, Whenever necessary, decompress and display. Furthermore, the content generation server makes it possible to efficiently use memory, for example, by compressing only actual information such as color information (i.e., parts such as headers may be damaged during compression and not compressed). The aim is to provide an image data compression system for a virtual machine with excellent compatibility by displaying the decompressed image using an image output function supported by the virtual machine. Furthermore, the size of the data can be freed or the format can be freely changed.

1 is a configuration diagram of a game service system using image data for a general virtual machine (VM).

2 is a flowchart of a game service using image data for a conventional VM.

3 is a flowchart of a game service using image data for a VM according to the present invention;

4 is a detailed flowchart of the production of compressed image content of FIG. 3.

5 is a detailed flowchart of execution of the compressed image content program for VM of FIG.

6 illustrates an image data compression method according to the present invention.

7 illustrates a naming scheme of an image block according to the present invention.

<Description of the symbols for the main parts of the drawings>

100: user terminal 110: VM module

120: memory 200: wireless Internet

300: mobile switching network 310: switchboard

320: network interlock device 330: WAP gateway

400: general internet network 500: VM server

510: WAP server 520: Download server

530: network game server 600: VM SDK

In accordance with an aspect of the present invention, a virtual machine compressed image data service method according to an aspect of the present invention, in response to a VM program request from the wireless communication user terminal 100, the VM server through the WAP server 510 And a compressed image data service method for a VM that generates and transmits the compressed image data for the VM requested by the user through the download server 520 through the transmission server 510. The process of generating the compressed image data for the VM includes: (a) loading and analyzing the image (S402, S404); (b) Performing compression routines (S406-S411) on the basis of the image information extracted in the above step, but compressing by displaying the number of times the same color information is continuously displayed in the case of the color information following the header. Performing a compression routine; (c) performing a process when the number of repetitions exceeds a predetermined threshold value N ₀ ; And (d) repeating steps (b) and (c) above until the operation is finished; Characterized in that it comprises a.

Advantageously, the method further comprises, after step (c), naming the block when compression for one image block is complete, wherein step (d) includes: The above steps (b) to (d) are repeated.

More preferably, the step (b) includes (b-1) analyzing the color information and writing the corresponding color information into the compressed data space (S406); (b-2) analyzing the next color information and performing counting when the same color information appears in succession (S409); And (b-3) determining whether or not the block is terminated, and if not, returns to the step (b-1) and repeats the steps (b-1) and (b-2), wherein the block Repeating this until it is finished; It includes.

On the other hand, the compressed image data service method for a virtual machine according to another aspect of the present invention for achieving the above object, as a method of executing a VM program in the user terminal 100, the download server 520 of the VM server 500 Receiving compressed image content from the target (S502); Loading image data and storing the image data in a memory (S504); Performing a decompression routine of a corresponding portion when recognizing a decompression request of a specific compressed image data block; And repeating the decompression routine performing until the corresponding image data block is finished and displaying the restored image when the block is performed. In addition, the decompression routine performing step, if there is the decompression request, perform image analysis (S510), perform color information analysis (S512), and sequentially read the data except the header to store the color information (S512) It is characterized by generating a color repeatedly by referring to the counter value corresponding to the number of repetitions immediately attached (S516).

Preferably, in the decompression routine performing step, if there is the decompression request, image analysis is performed (S510), and then naming analysis of the corresponding block is performed.

Hereinafter, a game service according to the present invention will be described with reference to FIGS. 1 and 3 of the accompanying drawings. 3 is a flowchart of a game service using image data for a VM according to the present invention.

Meanwhile, a virtual machine (VM) refers to a platform that creates a running environment for Java or C language-based programs.

First, the VM SDK 600 produces the compressed image content according to the present invention (S310). Subsequent steps S320 to S370 are the same as in the conventional case of steps S220 to S270 illustrated in FIG. 2, and thus detailed descriptions thereof will be omitted.

Finally, the user terminal receives the compressed image content, decompresses it, and displays it (S380).

Now, the production process of the compressed image content according to the present invention will be described in detail with reference to FIGS. 4, 6, and 7.

4 is a detailed flowchart illustrating the production of compressed image contents of FIG. 3, FIG. 6 illustrates an image data compression method according to the present invention, and FIG. 7 illustrates a naming method of an image block according to the present invention.

As shown in FIG. 4, when the process of producing compressed image contents is started, first, an image is loaded (S402) and analyzed (S404). In other words, it accepts the original image and extracts the maximum number and size of the picture to prepare for image compression. On the basis of the extracted image information, compression is performed by executing the compression routines of steps S406 to S414.

Here, when the image compression method according to the present invention is described, since the compression method in the present invention compresses only actual information except for a portion such as a header, it is possible to support various types of image data, This is done at the time of initial data generation and does not require any additional compression hardware or additional processing.

For example, when expressing image data of size M × N, the existing method is “header, color information 0, color 1, color 2, ... color information M × N”. In the present invention, in the case of the color information following the header, compression is performed in such a manner as to display the number of times the same color information appears continuously. For example, as shown in Fig. 6, if the original image data appears in the order of "red, red, red, blue, blue, blue, blue, black, black, yellow ...", the compressed data is " Red, 2, blue, 3, black, 1, yellow, 0 ... ". That is, certain color information appears, and the number of times that the same color information is continued is entered next. Of course, at this time, the size of the data unit may be arbitrary, and the format may be two or more color information adjacent to each other, such as "red, blue, 2, 3, black, yellow, 1, 0 ...". It is also possible to have a number of consecutive times.

As a result, it is possible to reduce the data requiring 10 storage spaces to 8, and the more the number of repeated colors is, the greater the compression efficiency becomes. At this time, since the number of repeated times also allocates one space, if the number of repeated times (N) is more than one storage space (eg 8 bits) (N ₀ : 255), the next color The information is unconditionally regarded as other new color information and counts again.

Returning to FIG. 4 and continuing the description, after image analysis (S404), color information is analyzed (S406) to perform compression as described above (S406), and the corresponding color information is written into the compressed data space. Then, the next color information is analyzed to determine whether the same color information appears in succession (S408). If the same color information is performed, a counter is performed, and an increment is performed (S409). Then, it is determined whether the number of repetitions exceeds the threshold value N ₀ (S411). If the number of repetitions is not exceeded, it is determined whether the corresponding block is terminated (S412). If not, the process returns to step S406 and appears next. Analyze color information.

If, as a result of the determination in step S408, if the next appearing color information is different from the previous one, the color information is immediately changed to the presently displayed color information without counting and the block is terminated (S408, S410, S412). Further, even if the color information shown next is the same as before, when the counting limit value N ₀ is reached, the color information is also changed and the return to the next color information analysis is examined (S411, S410, S412).

On the other hand, if the compression of one image block is ended as a result of the determination in step S412, the process now proceeds to step 414, where the naming of the block is performed. This will be described with reference to FIG. 7.

The purpose of naming is to manage data more conveniently. When naming, all compressed data can be integrated and managed as one array. In other words, if there is a picture and it is compressed and used, the user has a punch picture 0, a foot picture 1, a title screen 11, and so on. Be aware of this. This requires too much prior knowledge and inconvenient management for the user. According to the naming method according to the present invention, when generating initial picture data, each user can use the picture under a desired name. In other words, when the punch figure is 0, the user should remember and use this number. However, in this method, if the name "Punch" determined by the user is used in the program, enter the number 0. The same effect occurs when you do. In short, naming according to the present method is a method of attaching a name tag desired by a user to picture data produced by the user.

To this end, as shown in FIG. 7, the index is automatically assigned to each block to define the relationship with the actual compressed data. For example, 'Image 1' compresses the actual compressed data into "0x01, 0x0b, 0x03, ...", and indexes "0" to the block. Will be attached. Therefore, the user can use the compressed data freely and conveniently just by inserting this relationship definition into the program.

Now, returning to FIG. 4 again and continuing the description of the compressed image content creation process, after indexing the block and naming the block (S414), it is determined whether the entire work is finished (S416), and the entire block. If compression has been performed for, the operation is terminated, the compressed image contents are completed and stored in the database (S418), and the program is terminated.

Finally, a more detailed flow of execution of the compressed image content program for VM of FIG. 3 will be described with reference to FIG. 5. In the present invention, the decompression method analyzes the compressed image data transmitted using the VM function built in the terminal and restores the compressed image data to the original data in real time. I don't need any software.

Execution of the VM program in the user terminal 100 starts by receiving the compressed image content from the download server 520 of the VM server 500 (S502). After loading the image data (S504), this step is to load the compressed image and to store in the memory takes the same manner as the conventional image storage method in the existing VM.

On the other hand, the compressed image data is still in a compressed state even during the execution of the actual program (for example, a game progress program). If a compressed image data block corresponding to a specific moment in a user-written program routine (for example, For example, if a request is made to release the punch data block (S506), the decompression routine of the corresponding part is performed. For example, in a GVM program, once a user wants to print a fist picture and wants to print a picture called Punch,

Decoding (Punch, 0);

CopyImage (0,), Image [0]);

Will be programmed, and this will be the decompression request. In practice, however, they are treated as functions. Then, as described later, the 'Decoding' function decompresses and stores the image in the memory portion of 'Image [0]' and outputs it using the VM printout API. In other words, it can be applied without any hardware or software regardless of VM type.

When the decompression request is made (S506), a naming analysis is performed (S508). In this step, the user searches for the actual data to be decompressed by associating an index with a name of a desired picture (for example, 'punch'). do.

After that, the image analysis is performed (S510). In this step, the memory is calculated and the memory is prepared to prevent the actual size before compression. That is, the color information and the size information of the original image data are extracted from the header portion to create an empty space and to restore the original data there.

Now, a full-scale decompression routine is started to perform color information analysis (S512). That is, the data is read sequentially except the header to store the color information (S512), and the color is repeatedly generated by referring to the counter value corresponding to the number of repetitions immediately attached (S516). That is, the reverse operation of compression as shown in FIG. 6 is performed.

Then, it is determined whether the corresponding image data block is finished (S518). If it is not finished, the process returns to step S512 to continue the release routine, and when it is finished, the restored image is temporarily stored (S520). Now, it is determined whether or not the operation is finally finished (S522), and if it is not finished, returns to step S508 of performing naming analysis of the next block, and when finished, the restored image is supported by the VM The output function is output to the screen (S524). Thus, excellent compatibility is obtained.

The following is an example of the actual source code of the compression algorithm according to the present invention.

void Encoding (char * Sour, char * Dest)

{

int ch;

int key;

int IndexS = IndexD = 0;

int cnt = -1;

int Size;

Size = sizeof (Sour);

ch = * (Sour + IndexS);

key = ch;

while (ch! = NULL)

{

if ((ch == key) && (cnt <255))

cnt ++;

else

{

* (Dest + IndexD) = key;

IndexD ++;

* (Dest + IndexD) = cnt;

IndexD ++;

key = ch;

cnt = 0;

}

IndexS ++;

ch = * (Sour + IndexS);

}

}

* (Dest + IndexD) = key;

IndexD ++;

* (Dest + IndexD) = cnt;

return;

}

On the other hand, an example of an image data encoding program is described next.

void main (int argc, char * argv [])

{

int ch;

int key;

int cnt, gap;

int Step;

FILE * ReadFile, * WriteFile;

char Sour [15], Dest [15];

Step = 0;

if (argc <2)

printf ("\ nUsage: MAG filename \ n");

else

{

strcpy (Sour, argv [1]);

strcpy (Dest, argv [1]);

strcat (Sour, ".sbm");

strcat (Dest, ".MAG");

printf ("\ nSourceFile:% s \ n", Sour);

printf ("\ nCompressFile:% s \ n", Dest);

ReadFile = fopen (Sour, "r");

WriteFile = fopen (Dest, "w");

while ((ch = fgetc (ReadFile))! = '{')

{

fputc (ch, WriteFile);

}

fputc (ch, WriteFile);

fputc ('\ t', WriteFile);

for (cnt = 0; cnt <5; cnt ++)

{

fputc ('0', WriteFile);

fputc ('x', WriteFile);

ch = fgetc (ReadFile);

fputc (ch, WriteFile);

ch = fgetc (ReadFile);

fputc (ch, WriteFile);

fputc (',', WriteFile);

fputc ('', WriteFile);

}

fprintf (WriteFile, "\ n \ t \ t \ t");

ch = fgetc (ReadFile);

key = ch;

cnt = -1;

while ((ch! = EOF) && (key! = '}'))

{

if ((ch == key) && (cnt <15))

cnt ++;

else

{

fputc ('0', WriteFile);

fputc ('x', WriteFile);

fputc (key, WriteFile);

fprintf (WriteFile, "% 1x", cnt);

if (Step <15)

{

fputc (',', WriteFile);

fputc ('', WriteFile);

Step ++;

else

{

fprintf (WriteFile, "\ n \ t \ t \ t");

Step = 0;

}

key = ch;

cnt = 0;

}

ch = fgetc (ReadFile);

}

fseek (WriteFile, -2, SEEK_CUR);

fputc ('\ n', WriteFile);

fputc (key, WriteFile);

fputc (';', WriteFile);

fclose (WriteFile);

fclose (ReadFile);

printf ("\ nEnd Process ... \ n \ n");

}

}

Finally, an example of an image data decompression (decoding) program is described next.

void Decoing (int Kind, int No)

{

int size1, size2, i, j, key, cnt, loc, value;

loc = 0;

size1 = GetMediaSize (MNS [Kind]);

size2 = (GetChar (MNS [Kind], 1) * GetChar (MNS [Kind], 2)) / 2 + 6;

SetMediaSize (Image [No], size2);

for (i = 0; i <5; i ++)

PutChar (Image [No], i, GetChar (MNS [Kind], i));

for (i = 5; i <size2; i ++)

PutChar (Image [No], i, 0x00);

j = 4;

for (i = 5; i <size1; i ++)

{

key = GetChar (MNS [Kind], i);

key = key &0Xf0;

cnt = GetChar (MNS [Kind], i);

cnt = cnt &0x0f;

while (cnt> = 0)

{

if (loc)

value = key >> 4;

else

{

value = key;

j ++;

}

value = GetChar (Image [No], j) + value;

PutChar (Image [No], j, value);

loc ^ = 1;

cnt--;

}

}

}

The present invention has been described above with reference to one embodiment shown in the accompanying drawings, but the present invention is not limited thereto, and various modifications are possible within a range easily conceived by those skilled in the art. Therefore, the limitation of the present invention should be limited only by the following claims.

In general, the portion of the VM content occupies the most memory is image data. According to the image data generating method of the present invention, for example, in the case of a 4 gray image having a size of 128 * 96, a conventional method of 6144 bytes Compared to the use of memory, the method of the present invention makes it possible to store using only 480-2048 bytes of memory, making it possible to use less memory efficiently, and to produce content that exceeds the limitations of the VM. Since the user can use the compressed data under his or her own name, the compressed image can be used without any prior knowledge, and image data of the same information can be transmitted in a shorter time.

In addition, according to the decompression method according to the present invention, the VM content can be restored in real time without reducing the frame, and a separate program for restoring the compressed data is not needed, and multiple pictures are compressed whenever necessary. There are a number of advantages, including the ability to unlock and display.

Claims (5)

In response to a VM program request from the wireless communication user terminal 100, the VM server receives the request through the WAP server 510, and for the VM requested by the user through the download server 520 through the transmission server 510. A compressed image data service method for creating and transmitting compressed image data, The process of generating compressed image data for the VM, (a) loading and analyzing the image (S402, S404); (b) Performing compression routines (S406-S411) based on the image information extracted in the above step, but compressing by displaying the number of times that the same color information appears continuously in the case of the color information following the header. Performing a compression routine; (c) performing a process when the number of repetitions exceeds a predetermined threshold value N ₀ ; And (d) repeating steps (b) and (c) above until the operation is finished; Compressed image data service method for a VM comprising a. The method of claim 1, (e) after step (c), further comprises naming the block when compression of one image block is completed; In the step (d), the above steps (b) to (d) are repeated until the operation is completed. The method according to claim 1 or 2, In step (b), (b-1) analyzing the color information and writing the corresponding color information into the compressed data space (S406); (b-2) analyzing the next color information and performing counting when the same color information appears in succession (S409); And (b-3) If it is determined that the block has ended or not, the process returns to the step (b-1) and repeats the steps (b-1) and (b-2). Repeating this until it is finished; Compressed image data service method for a VM comprising a. A compressed image data service method for a VM including a method of executing a VM program in a user terminal 100, The execution method of the VM program, Receiving compressed image content from the download server 520 of the VM server 500 (S502); Loading image data and storing the image data in a memory (S504); Performing a decompression routine of a corresponding portion when recognizing a request to release a specific compressed image data block; And Repeating the decompression routine execution step until the corresponding image data block is finished; displaying the restored image when the block is performed; Including but not limited to: The decompression routine performing step, If the decompression request is made, image analysis is performed (S510), color information analysis is performed (S512), data other than the header is read sequentially, and color information is stored (S512) corresponding to the number of repetitions immediately following. Compressed image data service method for a VM, characterized in that for generating a color repeatedly by referring to the counter value (S516). The method of claim 4, wherein The decompression routine performing step, If the decompression request is received, further comprising performing a naming analysis on the corresponding block.