JPH02101585A - Managing system for picture storage area - Google Patents

Abstract

PURPOSE:To easily describe a program using other picture processing system by managing the processing of picture data in a picture storage area which other picture processing system manages by one of plural picture processing systems. CONSTITUTION:Picture processing application execution process 107 and picture processing basic module process 105 for managing process 103 and the picture processing basic module process 106 for the control process 104 perform various kinds of requests for a picture arrangement area respectively by using inter- process communication. Besides, the process 104, for instance, performs various kinds of the similar requests for the picture storage area for the process 103. Here, the kinds of the requests for the picture storage area are the requests of the registration, the release and the deletion of a picture and the network transmission request of picture data, and the process 103 or 104 processes these various kinds of the requests successively in the order of arrival. Thus, the program which is network-connected and uses other picture processing system can be described.

Description

DETAILED DESCRIPTION OF THE INVENTION (Field of Industrial Application) The present invention relates to an image storage area management method for allocating and managing image data in an image processing system connected to a computer network.

[Conventional technology]

In a conventional image processing system consisting of a computer such as a general-purpose minicomputer or an engineering workstation, and hardware dedicated to image processing consisting of an image processor and an image memory, the image processor transfers image data in the image memory to the internal CPU of the computer. is suitable for processing image data in main memory. In such a system, according to the method proposed by the applicant in Japanese Patent Application No. 63-59657 and Japanese Patent Application No. 63-59658, it is possible to provide an image storage area management process independent of the image data processing process. This makes it possible to dynamically allocate an appropriate storage area on the image memory or main memory according to the execution of image processing. It is now possible to write image processing programs without being aware of transfer.

[Problem to be solved by the invention]

However, the management process of such image storage area is
The storage area for image data was limited to only the image memory and main memory within the image processing system. Therefore, it is not possible for programmers to create programs that utilize other image processing systems connected to a computer network without being aware of the physical arrangement and transfer of image data.
In reality, in such a case, the user must explicitly call a transfer routine prepared by the user in the image processing program, or temporarily write it to a shared file to transfer the image. Something happened.

SUMMARY OF THE INVENTION An object of the present invention is to eliminate such complexity and easily write programs that utilize other image processing systems connected to a network.

- [Means for Solving the Problem] To this end, in the present invention, in a plurality of mutually connected image processing systems, each of the image processing systems has a storage means for storing information regarding image data and an image storage area. One of the plurality of image processing systems includes a means for managing processing of image data in an image storage area managed by another image processing system.

[For production]

In the present invention, a management process that manages an image storage area independently of the processing process manages the transfer of image data to and from an equivalent image storage area management process in another image processing system connected to a computer network. By having the means, it becomes possible to write an image processing program without being aware of the physical arrangement of image data or the image transfer between the image memory and the main memory.

〔Example〕

Hereinafter, the present invention will be described in detail with reference to the drawings.

FIG. 1(a) shows the equipment configuration of an embodiment of an image processing system according to the present invention. In the figure, 1 is a central processing unit (cpt+), which executes programs stored in the main memory. 2 is the main memory, which stores programs,
It has areas and work areas for storing processes and tables, respectively.

3 is an image memory for storing image information, and 4 is an image processing processor for processing data in the image memory.

FIG. 1(b) is a memory configuration diagram of the main memory,
The program area 21 stores programs for registering, occupying, releasing, deleting, and transmitting images shown in FIGS. 2 to 6, and the process area 22 stores management processes, image processing basic module processes, and image processing. Processes such as processing application processes are stored, the work area 23 stores the image size and the image 10 as arguments during processing, and the table area 24 stores a management table.

FIG. 1(c) shows an embodiment of the present invention. here 101
and 102 are individual image processing systems that are both connected to a computer network, and 103 and 10
4 are image processing systems 101 and 102, respectively.
This is a management process that manages the image storage area of . Further, 107 is an application execution process that performs a certain series of image processing procedures, and 105 and 106 are basic module processes that perform processing that is the basic unit of each image processing started by the process 107.

In this example, the operating system (O5) of the computer of the image processing system is UNIX by Bell Laboratories, and the functions of remote command activation and interprocess communication in the network are the rcmd system library and the 5ocket system call in UNIX, respectively. This is realized by

First, an outline of the operation between each process in FIG. 1(c) will be explained. Application execution process 10
7 starts the corresponding basic module process by starting a remote command when image processing needs to be executed. Each unit 105 and 106 in FIG. 1(C) indicates a process that is activated in this way, and 105 represents a basic module process that is executed on the same image processing system on which an image processing application is executed. , 106 indicate basic module processes executed on other image processing systems connected to the computer network.

In this case, the base module process 105 or 106
The argument passed to is an identifier that uniquely determines the image to be processed. Details will be described later.

) and processing parameters, and by writing those arguments following the command name, the command line is passed from the application execution process 107 to the basic module process 105 or 106 as a command line. Further, the ID of the image as a processing result is returned from the basic module process 105 or 106 to the application execution process 107 via the interprocess communication channel that is set at the time of starting the remote command.

The application execution process 107 and the basic module process 105 make various requests for the image storage area to the management process 103, and the basic module process 106 to the management process 104, respectively, using inter-process communication. In addition, the management process itself uses inter-process communication to communicate with other management processes as necessary.
For example, the management process 104 makes various requests to the management process 103 regarding the same type of image storage area. Here, requests for image storage area include image registration, occupation, release,
There are deletion requests and network transmission requests for image data, and the management process 103 or 104 sequentially processes these various requests in the order of arrival.

The operation of the management process for each request will be described below.

FIG. 2 shows an example of a processing procedure of a management process for an image registration request. First, the management process receives the image's X size (xsize) and Y size (ysize) as arguments.
, depth (nbytes) to xsize X ys
izeX nbytas is calculated to calculate the required storage capacity (step 5201). Next, it is determined whether there is a free storage area larger than this storage area in step 52.
02) If the determination is negative, the process is terminated with the error code as the return value (step 520: l).
. On the other hand, if the determination is affirmative, the storage area is secured and the management process registers the necessary information in the management table prepared on the main memory for managing the image storage area (step 520).
4) , the process ends with 10 of the image in the management table 701 and 702 columns (Figure 7) as the return value (step 52).
05).

FIG. 7 shows an example of the contents of a management table in which images are registered. Here, 701 is the name of the host device on which the management process that performed the image registration process is being executed, that is, the host name written in the file /etc/hosts in UNIX. A local ID 702 is given as a natural number during the registration process, and is incremented by one in the order of registration, so that it maintains uniqueness within one management process. By combining the host salt 701 and the local salt 10702, uniqueness can be maintained on the network, so this pair is used as the image ID.

703 indicates the status of the image, "-1" indicates that the image does not exist in the image processing system but exists on another image processing system on the network, and "1" indicates that the image is currently "2" indicates that the image exists in the image processing system in an occupied state, and "2" indicates that the image exists in the image processing system in an unoccupied state.

704 indicates the location of the image, and the host salt of the image processing system where the image currently exists is written. However, this field is used only for images registered in the management process. 705,706. and 707 indicate the X size, Y size, and depth of the image, respectively. Reference numerals 708 and 709 are the start addresses of the image, and indicate a virtual address required for access from the CPU and a physical address required for access from the image processor, respectively.

FIG. 3 shows an example of the operation of the management process in response to an image occupancy request.

First, the management process gets 10 of the images obtained as an argument (
Step 5301), thereby referring to the management table described above to determine whether the requested image exists in the image processing system (Step 5302). In reality, there is a corresponding image registration in the management table, and if the value in the status column 703 is positive, it means that the image exists. If it exists, the process advances to step 5312 to check whether it is occupied or not, and the value in the status column 703 is determined. Here, if this value is "1", it is already occupied, so it is considered an error (step 5313), and if it is "2", it is unoccupied, so it is rewritten to "1" (step 5310).
), the processing ends with the image start addresses 708 and 709 as return values (step 5311).

On the other hand, if a negative determination is made in step 5302,
Compare the host salt in the image ID that is an argument with the host salt on which the management process is being executed. Step 53
03) Determine whether the image is registered in the main management process. If the image is registered in this management process, it is determined whether the requested ID exists in the management table (step 5303A), and the image is found in the image location column 9704 of the management table. Find the host salt (step 5304), and output an image transmission request to the host (step 53).
05). If the determination in step 5303 is negative, find the host salt at IO of the image (step 530B)
, outputs an image transmission request to the host having the host salt (step 5307).

After that, if the request is accepted (step 530B
), image information (information necessary for image management table registration, i.e., 701, 702,
Step 5309), Step 5310
After registering the image in the management table (the image has already been registered in the table because the original image registration was done in the main management process,
Change column 04,708,709. ), return the start address of the image (step 5311), and end the process.

FIG. 4 shows an example of the processing procedure of the management process in response to an image release request.

The flow of this process itself is similar to the occupancy process shown in Figure 3 and steps 5408.5 similar to steps 5308.
413 is provided.

Here, the difference in image processing is step 5305.
．． The transmission request in 5307 is replaced with a release processing request (steps 5405 and 5407), and the processing ends immediately after accepting the request, and if the requested image exists in the image processing system, it is stored in the management table. If the status column 703 is “2”, an error occurs (step 54
12), if it is "1", it is changed to "2" (step 54).
10) is the point at which the process ends.

FIG. 5 shows an example of the processing procedure of the management process for an image deletion request.

The process flow itself is similar to the occupancy process described above, and steps 5301 to 5304, 5306, and 53 in FIG.
Step 5501 similar to 12 and 5313, respectively.
~5504, 5506, 5512 and 5513 are provided.

The difference is that the transmission request in steps 5305 and 5307 is replaced with a deletion processing request (step 5505.
5507), the process ends immediately after the request (
However, if this management process registers the requested image, even if the image does not actually exist in the management storage area, the table registration for managing the location of the image exists, so it cannot be deleted. (step 55151), if the requested image exists in the image processing system, the table registration is deleted and the storage area actually allocated for the image is released (step 5512.
5510).

FIG. 6 shows an example of a management process procedure for an image transmission request. First, the management process uses the image I as an argument.
D and the receiving host salt are obtained (step 5501), and based on this, the management table is referred to and it is determined whether the requested image exists in the image processing system in the same manner as the above-described occupancy process (step 5602). If it exists, image information (information necessary for image management table registration, i.e., 701, 702, 7 in FIG. 7) is transmitted through inter-process communication.
05, 706, and 707 columns), the image data is then transmitted to the receiving host obtained as an argument (steps 5616 and 5617).

On the other hand, if the image does not exist, the host salt in the image ID, which is an argument, is compared with the host salt on which the management process is being executed (step 5603) to determine whether the image is registered in the water management process. determine whether
If the determination is negative, an error code is returned (step 5513).
).

On the other hand, if the image is registered in this management process, the host salt where the image exists is determined from the image location column 704 of the management table (step 5604);
The receiver issues an image transmission request to the host using the received arguments as they are (step 5605), and then, after determining whether the request is accepted (step S[!08), the management table is updated in step 5610. Condition column 7
03 to "-1" and the image location column 704 to the receiving host salt. However, if the original image registration was not performed in this management process, the table registration is deleted.

), and after releasing the storage area, the process ends (step 5615).

In the above embodiment, each basic module of image processing is implemented as a command, and image processing is performed using the remote command function implemented by the UNIX rcmd system library. However, for example, RPC (Remo) by Sun Microsystems
te Procedure Cal) can also be used. In this case, if you register a group of image processing functions on the RPC server, you can pass arguments and returns in a function call format, so you can create an image processing application using a function call format similar to normal programming. can.

〔Effect of the invention〕

As described above, according to the present invention, an image storage area management process that is independent of a process that actually executes image processing is provided with an image IA that is connected to a computer network.
By providing a means to manage the transfer of image data to and from an equivalent management process in the implanted stem, the programmer is not aware of the physical location and transfer of image data, allowing the transfer of image data to other networked image processing systems. This has the effect of allowing you to write programs that use .

Correlation diagram of processes in multiple image processing systems connected to a workpiece. Figure 2 is a flowchart showing an example of the operating procedure in image registration processing of the management process. Figure 3 is an example of the operating procedure in image occupancy processing of the management process. FIG. 4 is a flowchart showing an example of the operating procedure in image release processing of the management process. FIG. 5 is a flowchart showing an example of the operating procedure in image deletion processing of the management process. FIG. 7 is a flowchart showing an example of the operating procedure in the image data transmission process of the process, and FIG. 7 is an explanatory diagram showing an example of the management table.

[Brief explanation of drawings]

FIG. 1(a) is a block diagram of an embodiment of an image processing system related to the present invention, FIG. 1(b) is a memory configuration diagram of the main memory, and FIG.
C) is an embodiment of the present invention, Nect 101, 102,
...Image processing system, 103.104...Management process, 105.106...Basic module process, 107
...Application execution process. Figure (a) Figure (b) Figure 6

Claims (1)

[Scope of Claims] 1) In a plurality of image processing systems connected to each other, each of the image processing systems has a storage means for storing information regarding image data and a management means for managing an image storage area. and one of the plurality of image processing systems.
An image storage area management method, characterized in that the image storage area management method comprises means for managing processing of image data in an image storage area managed by another image processing system. 2) The image storage area according to claim 1, wherein each of the plurality of image processing systems includes means for managing processing of image data in image storage areas managed by the other image processing systems. management method.