Method and apparatus for saving a definition for automated data processing

Abstract

A number of items of data are obtained from a data source and are processed and then stored in a data destination. The data items may each include image data, text data, numeric data or some other type of data, or a combination of these different types of data. The processing of the data is controlled by a project definition which includes several modules selected from a variety of available modules. The modules have input and output ports that are interrelated by binding information. Each project definition is expressed in a public communication protocol, one example of which is the extensible Markup Language (XML) protocol.

Claims

1. A computer-implemented method for facilitating creation of a definition for automated data processing, comprising the steps of:

providing a set of predetermined function definitions which are different, at least one of said predetermined function definitions defining a function for manipulating image data; and

preparing a project definition expressed in a public communication protocol, said project definition defining a project for manipulating said image data according to said one predetermined function definition and including:

a plurality of function portions which each correspond to one of said function definitions in said set, and which each define at least one input port and at least one output port that are functionally related according to the corresponding function definition;

a further portion which includes a source portion identifying a data source and defining an output port through which data from the data source can be produced, and which includes a destination portion identifying a data destination and defining an input port through which data can be supplied to the data destination; and

binding information which includes binding definitions that each associate a respective said input port with one of said output ports; and

wherein one of said function definitions implements a function which varies in dependence on control input and said preparing step includes the step of including in said project definition, for each said function portion therein that corresponds to said one of said function definitions, respective control information for use as said control input:

wherein said function blurs an image, expands an image, or performs at least one mathematical computation using said image data; and

wherein said control information selects between a plurality of blurring techniques, selects between a plurality of colors to fill resulting added area, or selects between a plurality of mathematical equations.

2. A computer-implemented method according to claim 1, including the step of selecting as said public communication protocol the eXtensible Markup Language (XML) protocol.

3. A computer-implemented method according to claim 1, wherein said preparing step includes the step of including in said project definition a list which identifies at least some of said function, source and destination portions, said project definition including for each said portion in said list a section which sets forth any said control information for that portion, and a section which includes said binding definitions for that portion.

4. A computer-implemented method according to claim 3, wherein said preparing step includes the step of including in said project definition a plurality of process definitions which each include a respective said list, said lists each including a subset of said function, source and destination portions, and said subsets being mutually exclusive.

5. A computer-implemented method according to claim 1, wherein said function cooperates with a separate image processing application to perform an operation using said separate image processing application.

6. A computer-readable medium encoded with a computer program which recognizes a set of predetermined function definitions that are different, and which is operable when executed to facilitate preparation in a public communication protocol of a project definition for automated data processing which includes:

a plurality of function portions which each correspond to one of said function definitions in said set, and which each define at least one input port and at least one output port that are functionally related according to the corresponding function definition;

a further portion which includes a source portion identifying a data source and defining an output port through which data from the data source can be produced, and which includes a destination portion identifying a data destination and defining an input port through which data can be supplied to the data destination; and

binding information which includes binding definitions that each associate a respective said input port with one of said output ports; and

wherein at least one of said predetermined function definitions defines a function for manipulating image data and said project definition defines a project for manipulating said image data according to said one predetermined function definition;

wherein one of said function definitions implements a function which varies in dependence on control input and said program is operable when executed to include in said project definition, for each said function portion therein that corresponds to said one of said function definitions, respective control information for use as said control input:

wherein said function blurs an image, expands the image, or performs at least one mathematical computation using said image data; and

wherein said control information selects between a plurality of blurring techniques, selects between a plurality of colors to fill resulting added area, or selects between a plurality of mathematical equations.

7. A computer-readable medium according to claim 6, wherein said program is operable when executed to use as said public communication protocol the eXtensible Markup Language (XML) protocol.

8. A computer-readable medium according to claim 6, wherein said program is operable when executed to include in said project definition a list which identifies at least some of said function, source and destination portions, said project definition including for each said portion in said list a section which sets forth any said control information for that portion, and a section which includes said binding definitions for that portion.

9. A computer-readable medium according to claim 8, wherein said program is operable when executed to include in said project definition a plurality of process definitions which each include a respective said list, said lists each including a subset of said function, source and destination portions, and said subsets being mutually exclusive.

10. A computer-readable medium according to claim 6, wherein said function cooperates with a separate image processing application to perform an operation using said separate image processing application.

Description

TECHNICAL FIELD OF THE INVENTION

This invention relates in general to automated processing of multiple items of data and, more particularly, to a method and apparatus for saving a definition which controls such automated data processing.

BACKGROUND OF THE INVENTION

There are a variety of situations in which automated processing of a number of data items is desirable. One specific example of such an application is product catalogs. Product catalogs, whether in the form of a paper catalog or an Internet "Web" site, frequently have numerous pictures which each depict a respective one of the various items that are available for sale. Many years ago, these pictures were prepared using optical negatives and photographs. Currently, however, the trend is to maintain and process these pictures in the form of computer files containing digital images.

A given paper or on-line catalog will usually include products from a variety of different manufacturers, and it is common for each manufacturer to provide its own digital images. There will typically be variation between the form of images provided by different manufacturers, for example in terms of characteristics such as the size, shape, resolution, tint, and so forth. It is even possible that the images from a single given manufacturer may have different forms. Accordingly, in order for the images throughout a catalog to have a generally similar appearance, the various images from various sources need to be processed to adjust characteristics such as size, shape, resolution, and/or tint, so as to bring them into general conformity with each other.

A further consideration is that a manufacturer's images do not represent a static situation, because manufacturers are constantly adding new products with new images, discontinuing existing products and associated images, and providing updated images for existing products. Moreover, there may be other reasons for adjusting images. For example, with respect to a paper or on-line catalog intended for use during the Christmas season, there may be a desire to put a festive frame around each image, such as a frame of holly leaves and berries. Moreover, stylistic changes in the images are often desirable.

The traditional approach for carrying out these various types of image processing tasks has involved manual adjustments effected on an image-by-image basis, through use of image processing software requiring extensive operator interaction. However, this is extremely time consuming and expensive. Many organizations currently employ a number of graphic artists to do this work, at great expense.

A less common approach has been the preparation of a hard-coded software routine to process images, written in line-by-line source code. However, these routines are time-consuming and expensive to generate, are likely to include errors or "bugs", and have little flexibility because they cannot be modified quickly and cheaply. Moreover, they can only be prepared and executed by a skilled programmer, rather than by a graphic artist who is skilled in image processing but has limited computer skills. It is difficult to find persons who have both artistic and computer skills, and they command large salaries.

Thus, while these traditional approaches have been generally adequate for their intended purposes, they have not been satisfactory in all respects. One specific aspect of this, as mentioned above, is the fact that, to the extent automated procedures have previously been developed to process multiple items of data, these-procedures have been expressed in the form of hard-coded source code. An associated problem is that this source code must be separately compiled for various different hardware platforms on which it will be utilized, through use of various different compiler programs.

SUMMARY OF THE INVENTION

From the foregoing, it may be appreciated that a need has arisen for a method and apparatus for saving a definition that controls automated data processing, in a manner which is efficient and user friendly. According to the present invention, a method and apparatus are provided to address this need.

In particular, one form of the present invention involves providing a set of predetermined function definitions which are different, and preparing a project definition expressed in a public communication protocol. The project definition includes: a plurality of function portions which each correspond to one of the function definitions in the set, and which each define at least one input port and at least one output port that are functionally related according to the corresponding function definition; a further portion which includes a source portion identifying a data source and defining an output port through which data from the data source can be produced, and which includes a destination portion identifying a data destination and defining an input port through which data can be supplied to the data destination; and binding information which includes binding definitions that each associate a respective input port with one of the output ports.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention will be realized from the detailed description which follows, taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a diagrammatic view of a configuration which embodies the present invention, and which includes a data source, two data destinations, and a project definition;

FIGS. 2-5 are each a diagrammatic view of a respective different icon which can be used to diagrammatically represent a portion of a project definition of the type shown in FIG. 1;

FIG. 6 is a diagrammatic view similar to FIG. 1 of a different project definition according to the present invention;

FIG. 7 is a diagrammatic view of a different way of visually representing the project definition of FIG. 6;

FIG. 8 is a diagrammatic view similar to FIG. 1 of yet another project definition according to the present invention;

FIG. 9 is a block diagram of a system which embodies the present invention, including the capability to create and execute project definitions of the type shown in FIGS. 1 and 6-8;

FIGS. 10-12 are each a flowchart showing a respective sequence of operations carried out by respective portions of the software within the system of FIG. 9;

FIG. 13 is a diagrammatic view of a dialog box which can be displayed by the system of FIG. 9 during execution of a project definition;

FIG. 14 is a diagrammatic view of a screen which can be displayed by the system of FIG. 9 to permit a user to carry out functions such as creation, modification and execution of a project definition;

FIG. 15 is a diagrammatic view of a different way in which the project definition of FIG. 8 can be visually represented;

FIG. 16 is a diagrammatic view of two modules of a project definition, in conjunction with binding menus that are used to define a relationship between the depicted modules;

FIG. 17 is a diagrammatic view of a further dialog box, which can be displayed by the system of FIG. 9 during creation of a project definition; and

FIG. 18 is a diagrammatic view of yet another dialog box, which can be displayed by the system of FIG. 9 during creation of a project definition.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a block diagram of a configuration 10 which embodies features of the present invention, and which includes a computer subdirectory 12 that serves as a data source and contains a plurality of files with images therein, a project definition 14 that defines how data from the files in the subdirectory 12 should be processed, and two computer subdirectories 16 and 17 that serve as data destinations into which files containing the processed data will be stored. The project definition 14 is executed by a computer, in a manner described in more detail later, and successively obtains the files from the subdirectory 12, processes each file 12 in a manner described below, and then deposits the processed file in either the subdirectory 16 or the subdirectory 17. For purposes of the present discussion, it is assumed that the files in the subdirectory 12 contain image data, but they could alternatively contain some other type of data. Also, the terms directory, subdirectory, folder and subfolder are all used here to refer to directories.

The specific project definition 14 shown in FIG. 1 has been designed to be relatively simple for purposes of illustrating some basic concepts of the present invention, and basically will do two things. First, it will take each file obtained from the subdirectory 12, and evaluate the size of the file. With respect to size, it is important to remember the distinction between the size of an image, which is measured in pixels in each of the height and width directions, and the size of the file containing the image, which is typically measured in kilobytes (KB). In FIG. 1, files above a certain size are to be placed in the subdirectory 16 after processing, whereas all other files are to be placed in the subdirectory 17 after processing. Second, the project definition 14 will take the name of each file, and superimpose this name on top of the image in the file. For example, if a given file is named "elephant" and contains an image of an elephant, the word "elephant" will be superimposed on top of the image of the elephant.

The subdirectory 12 is not itself a part of the project definition 14. Subdirectory 12 may be local to the computer executing the project definition 14, may be disposed in another nearby computer accessible through a local area network (LAN), may be disposed in a remote computer many miles away which must be accessed through the Internet, or may be accessed in some other manner. The project definition 14 thus needs to know where to find the subdirectory 12 and the data therein. Accordingly, the project definition 14 includes a source module 21, which includes a definition of where to locate the subdirectory 12, and how to access it. The source module 21 successively obtains the files from the subdirectory 12. Each time the source module 21 receives a file from the subdirectory 12, it outputs the image data from the file through a first output port, as indicated diagrammatically at 22, and outputs a text string representing the file name through a second output port, as indicated diagrammatically at 23.

Lines of the type shown at 22 and 23 are referred to herein as binding lines. For convenience, image data is indicated by a wide double-line binding line, as shown in 22, whereas other types of data are indicated by a thin single-line binding line, as shown at 23. Alternatively, different types of binding lines could be distinguished in some other manner, for example by presenting them in different colors. Where an input port and an output port are associated with each other by a binding line, they are said to be bound to each other.

In the embodiments disclosed herein, an image or other data element obtained from a data source by a project definition is processed to completion by the project definition before the next successive image or data item from that data source is provided to the project definition. However, it will be recognized that it would alternatively be possible for a project definition to simultaneously have several successive images or data elements at various levels of processing, for example through the use of appropriate pipelining techniques. Conceptually, one way to view the project definition 14 of FIG. 1 is that execution proceeds on a module-by-module basis through the project definition along the double-line image data binding lines, from the source module 21 to the branch module 26, and then to either the action module 31 followed by the destination module 37, or alternatively to the action module 32 followed by the destination module 38. Another way to view the project definition 14 is that each of the modules is ready at all times to carry out its respective function, and does so as soon as all data needed to carry out that function arrives at the input port(s) of that module.

Image data that is output at 22 by the source module 21 flows to an input port of a branch module 26. The branch module 26 checks the size of the file associated with each image that arrives at its input port. If the file size for a given image is above a predetermined size, then the branch module 26 outputs the image data at 27 through a first output port. Otherwise, it outputs the image data at 28 through a second output port. The image data at 27 flows to an input port of an action module 31, whereas the image data at 28 flows to an input port of an action module 32.

For the sake of simplicity, the action modules 31 and 32 in the example of FIG. 1 have identical functions. More specifically, each has a further input port which receives the text string represented by binding line 23. As mentioned above, this text string contains the name of the file associated with the image data. The action modules 31 and 32 each have the capability to take the text string and superimpose it on the associated image data, and then output the result at 33 or 34 through an output port. The data at 33 flows to an input port of a destination module 37, and data at 38 flows to an input port of a destination module 38. Again, for simplicity, destination modules 37 and 38 are functionally identical.

In this regard, and as was the case with the subdirectory 12, the subdirectories 16 and 17 may each be local or remote, and may be accessed in different ways. Further, one or both of the subdirectories 16 and 17 may be located in proximity to the subdirectory 12, or may be remote from the subdirectory 12. Consequently, since the subdirectories 16 and 17 are not part of the project definition 14, the project definition 14 needs to know where to find them and how to access them, so that it knows where to deposit processed data. Accordingly, the destination modules 37 and 38 each include a definition of where to find the associated subdirectory 16 or 17, and how to access it. Thus, when the project definition 14 has finished processing all of the files from the subdirectory 12, the subdirectory 16 will contain a processed version of the files which are larger than a specified size, and the subdirectory 17 will contain a processed version of the remaining files. Further, each of the files in subdirectories 16 and 17 will contain an image which has the associated file name superimposed on it.

A brief comment regarding the use of the terms "process" and "sub-process" will help to avoid confusion. A project definition of the general type shown at 14 in FIG. 1 may include two or more mutually exclusive sets of modules, which are each referred to as a process. In the particular example of FIG. 1, for the sake of simplicity, the project definition 14 includes only one process, which contains all of the modules 21, 26, 31-32, and 37-38. This process has two portions, which are respectively disposed above and below the broken line 42 in FIG. 1.

The modules 21, 23, 31 and 37 which are above the broken line 42 are referred to herein as a main process, and the modules 32 and 38 which are below the broken line 42 are referred to as a sub-process. Technically, the main process and the sub-process are each a respective sub-process of the overall process. However, the first sub-process in every process is mandatory, and is always the starting point for execution of the process, and thus it is referred to as the main "process" rather than as the main "sub-process", even though it is actually a sub-process of the overall process. The presence of one or more additional sub-processes is entirely optional, and execution may or may not be transferred to each, depending upon factors such as whether branch modules are present and the particular data which is being processed. Consequently, they are referred to as sub-processes. An input or output port of a given module can be bound to ports of other modules within any of the sub-processes of the same process, but cannot be directly bound to ports of modules in other processes of the same project definition.

Where a branch module in a main process is capable of routing data to a sub-process, the data is always transferred to the first module in that sub-process, rather than to an intermediate module partway along the sub-process. The same is true where a branch module in a sub-process is capable of transferring data to a different sub-process. A further characteristic in the disclosed embodiments is that branch modules are allowed to route data to a later sub-process, but never to an earlier sub-process or the main process. Moreover, while one output port of a branch module can route data to the next successive module in the current sub-process (which may be the main process), the other output port is not permitted to route data to a module in the current sub-process, but must route data to a different sub-process. However, it will be recognized that an alternative embodiment could accommodate branch modules having the capability to route data to an earlier sub-process (which may be the main process), to a module partway along a different sub-process (which may be the main process), or to two modules which are both within the current sub-process. In fact, the alternative embodiment need not conceptually organize modules of an overall process into groups treated as respective sub-processes.

As discussed above, the branch module 26 will route each image either at 27 to the action module 31 or at 28 to the action module 32. If the data is routed to action module 31, then action module 31 and destination module 32 operate on the image data, while action module 32 and destination module 38 remain idle. Alternatively, if an image were instead to be routed at 28 to the action module 32, then action module 32 and destination module 38 would operate on the image data, while action module 31 and destination module 37 remained idle. Thus, in the example of FIG. 1, the branch module 26 determines whether processing of each image will be carried out by continuing along the main process, namely in action module 31 and destination module 37, or will be carried out in the sub-process, namely in action module 32 and destination module 38.

The project definition 14 in FIG. 1 is a simple example, but has been configured to show at least one example of each of the four types of modules that are recognized in the disclosed embodiments of the present invention. In other words, the disclosed embodiments of the present invention recognize source modules, one example of which appears at 21, branch modules, one example of which appears at 26, action modules, two examples of which appear at 31 and 32, and destination modules, two examples of which appear at 37 and 38. As reflected by the brackets along the bottom of FIG. 1, branch modules and action modules are sometimes referred to collectively herein as function modules. Source modules deal with the question of where to find the data to be processed, branch modules deal with the question of which data should and should not be processed in a specified manner, action modules deal with the question of what processing should be performed on the data, and destination modules deal with the question of where to put the processed data.

In order to put the present invention into perspective, it is helpful to understand one possible application for a project definition of the type shown at 14 in FIG. 1. Product catalogs, whether in the form of a paper catalog or an Internet "Web" site, frequently have numerous pictures each depicting a respective one of the various items that are available for sale. Many years ago, these pictures were prepared using optical negatives and photographs. Currently, however, the trend is to maintain and process these pictures in the form of computer files containing digital images.

A given paper or on-line catalog will usually include products from a variety of different manufacturers, and it is common for each manufacturer to provide its own digital images. There will typically be variation between the form of images provided by different manufacturers, for example in terms of characteristics such as the size, shape, resolution, tint, and so forth. It is even possible that the images from a given manufacturer may have different forms. Accordingly, in order for the images throughout a catalog to have a generally similar appearance, the various images from various sources need to be processed to adjust characteristics such as size, shape, resolution, and/or tint, so as to bring them into general conformity with each other. A further consideration is that a manufacturer's images do not represent a static situation, because manufacturers are constantly adding new products with new images, discontinuing existing products and their images, and providing updated images for existing products. Moreover, there may be other reasons for adjusting images. For example, with respect to a paper or on-line catalog intended for use during the Christmas season, there may be a desire to put a festive frame around each image, such as a frame of holly leaves and berries. Moreover, stylistic changes in the images are often desirable.

The traditional approach for carrying out these various types of image processing tasks has involved manual adjustments effected on an image-by-image basis, through use of image processing software requiring extensive operator interaction. However, this is extremely time consuming and expensive. Many organizations employ a number of graphic artists to do this work, at great expense.

A less common approach has been preparation of a hard-coded software routine to process images, written in line-by-line source code. However, these routines are time-consuming and expensive to generate, are likely to include errors or "bugs", and have little flexibility because they cannot be modified quickly and cheaply. Moreover, they can only be prepared and executed by a skilled programmer, rather than by a graphic artist who is skilled in image processing but has limited computer skills. It is difficult to find persons who have both artistic and computer skills, and they command large salaries.

In contrast to these known approaches, a project definition of the type shown at 14 in FIG. 1 provides the capability to automate image processing so that a large number of images can be automatically and rapidly processed in a defined manner, and at far less expense than would be involved with the traditional and common approach of manual processing. Further, and as described in more detail later, the present invention provides a simple and user-friendly approach for creating and modifying project definitions of the type shown at 14 in FIG. 1, thereby permitting graphic artists who have limited computer skills to easily and accurately create a project definition while substantially avoiding the likelihood of bugs, with far less overall time and expense than is involved with the known approaches discussed above. The advantages of the present invention over the known approaches will become even more apparent as the present invention is discussed in greater detail below. While the foregoing example of catalog preparation focused on processing of image data, and while the disclosed embodiments involve primarily the processing of image data, the present invention is also advantageous for applications which involve processing of other types of data.

The foregoing discussion of FIG. 1 described one specific example of each of the source, branch, action and destination categories of modules. The present invention actually recognizes several types of modules in each category. More specifically, TABLE 1 describes several different types of source modules, TABLE 2 describes several different types of branch modules, TABLE 3 describes several different types of action modules, and TABLE 4 describes several different types of destination modules. Some of the module types set forth in TABLES 1-4 could be omitted, or additional module types could be included, without departing from the present invention. The module types set forth in TABLES 1-4 are referred to herein as standard module types. As discussed later, the present invention also provides for the creation of custom module types, for example through modification of one of the standard module types set forth in TABLEs 1-4. The resulting custom module type can either be substituted for the standard module type from which it was derived, using the same name, or can be used to supplement the standard module types, using a unique new name.

A few comments are appropriate regarding TABLEs 1-4. First, the present invention permits the use of virtual paths, where a table is provided to associate each virtual path with an actual path. Where a project definition uses a virtual path term, each computer on which that project definition may be executed would include a respective table entry to associate that virtual path with a respective actual path. Thus, the project definition can be executed without change on each such computer, but will use a different actual path on each computer wherever the virtual path term appears, without any need to actually modify the path information within the project definition itself.

A further consideration is that, in the disclosed embodiments, project definitions recognize various types of data, including image data, numeric data in a floating point or "float" format, and string data in the form of a series of text characters. In the discussion which follows, references to data types are typically preceded by the prefix "em", such as "emImage", "emFloat", or "emString". This is an arbitrary prefix, which has been used to facilitate implementation of the disclosed embodiments. For example, if data is received from an external source with an indication that it includes data of a type "emFloat", it can be assumed that it conforms to the appropriate format. In contrast, if the data type is merely indicated to be "float", it would be necessary to evaluate the associated data in an attempt to determine which of various formats for floating point data it conforms to, but even then it may not be possible to tell.

A feature of the present invention is that many of the module definitions in TABLEs 2 through 4 have input ports configured so that the input port will accept data in various formats and, if that data is not in the format preferred by that input port, the input port will automatically convert the data to its preferred format. This feature is referred to as data matching. For example, if a number in a floating point format is supplied to an input port which expects data in a string format, the floating point value will be converted to a text string which represents the number. Input ports which have this capability are identified in TABLES 1-4 as having a data type of "emVariant". This does not mean that actual data can be formatted in the "emVariant" format. Instead, "emVariant" refers only to the capability of the input port to be bound to an output port that produces data conforming to other valid data types, such as "emFloat" or "emString".

With respect to image data, it should be understood that data for a given image may include two or more objects and/or layers. For example, an image may have two layers which are each an object. Similarly, if a mask is created for an image, the mask will be added to the image data in the form of a separate layer. Also, if text is superimposed onto an image, for example as discussed above in association with the action modules 31-32 in FIG. 1, the text will be added as an object, separate from other pre-existing objects of the image data. All the objects associated with a given image can be combined into a single object, through use of a "Flatten Image" definition which is set forth in TABLE 3.

In general, the definitions of source, branching, action and destination modules in TABLEs 1-4 are believed to be self-explanatory. However, there is one definition as to which a supplementary comment may be helpful. In this regard, the "Database Access" definition in TABLE 1 is a source module which obtains data in a manner that includes accessing a database. The database will include a table that has a plurality of rows called records, which each include a plurality of columns called fields. If the data being retrieved is string data, it may be retrieved directly from one of the fields in the table of the database. On the other hand, if the data being retrieved includes image data, the image data will typically be stored separately from the database, for example within files in a subdirectory, and one field in the table must contain a string with a complete path to the image data.