AU2006228339A1 - Processing system - Google Patents

Description

WO 2006/103460 PCT/GB2006/001191 Processing System This invention is concerned with a processing system, and more specifically a system, the various parts of which are provided to manage computer processor 5 intensive tasks in a reliable, robust, scalable and efficient manner. Yet fur-ther specifically, the invention is concerned with the management and control of multiple user requests (including the possibility of many users making single requests, and one or only a few users making multiple requests) for computer processing power, the results of which produce one or more computer files which are to be returned to the 10 user by predetermined means. Although the following description is almost exclusively concerned with a processing system for managing and controlling multiple user requests for image rendering tasks, it will be understood by those skilled in the art that the system hereinafter 15 described may apply equally to other computer processor intensive tasks, such as database rationalisation, numerical analysis (such as finite element analysis), and data manipulation in general. Indeed, the system hereinafter described may be used in a wide variety of applications in which there is a requirement to manage, control and distribute processor-intensive processing tasks in a reliable, effective, efficient, and 20 scalable manner. Computer image rendering has long been known to be a highly computer processor intensive, and indeed computer memory-hungry task, both in terms of physical disk space required (computer files describing high resolution images are often of the 25 order of many megabytes or MB), and in terms of the RAM into which such image files must be loaded before any alterations or modifications to those images can be carried out in the software from which they were originated. There are already in existence a wide variety of computer programs for creating, 30 altering, and manipulating images, in both two and three dimensions. At the time of filing of this application, it is probably the case that the use of computer-aided design 1 WO 2006/103460 PCT/GB2006/001191 tools, software and product prototyping is fairly ubiquitous across all manufacturing industries, not least because the computer and the relevant software loaded thereon is capable of providing an exceptionally detailed spatial visualisation of the product being developed. The on-screen image of the product can thus be viewed on screen 5 by any user having the same or compatible software to that in which the file was created or from which it originated. Furthermore, with compatible computer-aided manufacturing equipment, it has become possible in recent years to manufacture products using the original computer files, and this has allowed for huge increases in manufacturing productivity. 10 The advertising industry is fundamentally concerned with the display of products, their packaging and any associated artwork, brand, logos and the like in a- manner which catches the public eye, or at least alerts the attention of the public to the existence of those products. The reader will instantly appreciate that there is a myriad 15 of different advertising techniques, the majority of which use various different media to achieve its aims. Of most relevance to this application is the use of printed media to advertise products, because currently and for the foreseeable future, anything which is to be printed on practically any media will originate from a computer loaded with industry-standard software packages, such as Adobe® Photoshop (traditionally 20 used for the generation of very detailed computer images, artwork, textures, layers and the like) and 3D Studio MaxTM (which is traditionally used for the creation of 3D images, models, and animations and the like). While this application focuses predominantly on printed media, it is to be mentioned that the system hereinafter described is capable of producing images in various formats or file types-e.g. TIF 25 files are commonly used in print, PNG files are useful in web development, and JPG or JPEGs are good for general distribution. Accordingly, images produces in these fonmats can be used for print, web, multimedia, screen and broadcast applications. In a conventional situation, it is known in the advertising industry to model a three 30 dimensional product or article in a modelling package such as 3D Studio Max. It is important for the purposes of this invention that the modelling package uses a 2 WO 2006/103460 PCT/GB2006/001191 polygonal and/or parametric modelling algorithm or technique so that any changes to the size of the article in terms of on-screen size (and the actual physical size of the article represented in the software) are mathematically calculated to ensure that the enlarged article bears as exact and identical a resemblance to the initial model as is 5 possible. Thereafter, the graphic artist will generally turn to an image creation and manipulation software package, such as Adobe Photoshop, to either create or manipulate a pre-existing artwork or texture file. In the case of a simple product 10 container such as a tin or beverage can, the artwork files may be relatively simple containing only text, logos, relatively few colours and/or complex images, whereas in the case of a complex product, such as a shoe, the artwork will be complex in both content and shape, and will be more akin to a "texture" as opposed to simple artwork. For example, a model of a tin might comprise a single artwork file (the label, which 15 contains text, logos, images and colour), and might also include various maps (textures) created by the artist to simulate attributes such as reflections and relief textures. In any event, it is common practice in the field of image creation and rendering to 20 firstly model the particular product or article shape in a 3D package, and then to create an artwork or texture file (typically a vector-based artwork file) for application and combination with the 3D file. In cases where artwork is supplied, artwork may be a vector/raster hybrid converted into raster. Typically, this format is non-scaleable, but is originated, applied, and stored at a high resolution of detail that can be drawn 25 upon and is mostly used at a much lower quality than the source. At this stage, there is no specification by the user as to the eventual physical size of the image which is required to be printed, its required print resolution, or the type of file which is ultimately required. These parameters are specified immediately prior to 30 a rendering process. Accordingly, at this stage in the process, it is possible to vary the 3D model to any desired size without any loss in ultimate image quality. The reason 3 WO 2006/103460 PCT/GB2006/001191 for this is the fact that the 3D model is polygonally and/or parametrically (and thus mathematically) defined. The artwork is described in a vector or vector/raster hybrid format (also a mathematical definition), and therefore cannot be scaled past its original size without loss in quality, but in general the quality provided in such files 5 (and certainly as far as this application is concerned) is far in excess of that ultimately required by a user. Importantly though, any resizing of either article model or artwork is mathematically calculated as opposed to being simply scaled according to the re sizing request. In this regard, it is also to be mentioned that the term "re-size" and its cognate expressions can be taken to include the alternate construction whereby the 10 virtual "camera" through which the user is viewing the model and artwork on-screen is re-positioned so that the model appears larger or smaller. Ultimately the effect achieved is the same. Once a user has these two essentially mathematical descriptions of on the one hand a 15 3D product or article, and on the other hand artwork intended to be applied integrally with or to the surface of that article, a rendering process can be undergone whereby the artwork file is virtually "applied" to or connected with the 3D product model so as to become part thereof, and the re-sizing and image resolution parameters can be chosen prior to the carrying out of the process. The rendering process is highly 20 processor intensive because during the creation of the final rendered image, an enormous number of mathematical calculations are required to be carried out as both the polygonal-based article model file and the image/artwork file are resized and combined to provide the final rendered image at the required size (i.e. physical x, y dimensions) and the required resolution (usually specified in d.p.i. or dots per inch). 25 Typically, it is worth mentioning that the image/artwork file may be initially provided as a combination of vector and raster-based elements which may subsequently be finalised into a full raster image at as high a resolution and quality as possible. The rendering process has long been known to be a very resource-hungry processing 30 technique, and is often used in benchmarking tests for processors to test their speed. The demands on processor and memory resources can be further understood when 4 WO 2006/103460 PCT/GB2006/001191 during a rendering process, the colour of the pixel, which might depend on its native colour, its texture, reflection, glossiness, the amount of light and shadow it is receiving, the amount of shadow that is cast upon it etc., must be calculated for every single pixel in an image. This process may have to be repeated hundreds of thousands 5 and possibly millions of times per image. In commercial image processing and manipulation environments, normal practice has been to provide graphic artists with computers having exceptionally highly specifications to ensure that any image rendering which is required to be done by 10 them can be carried out on a local basis at their own computers without either causing interruption to their office computer system in general and without taking too much time on that computer-it is worth mentioning that during more complex image rendering processes, it is common for the computer processor (at least that in a personal computer anyway) to be entirely utilised so that the effectiveness of the 15 computer in carrying out any other task is dramatically and drastically reduced and it becomes ultimately useless while the rendering is taking place. The fundamental difficulty, at least as far as this application is concerned, is that while in the vast majority of circumstances, it is acceptable for image rendering to be 20 carried out on local, albeit highly specified PCs, this system cannot work for a multi user system where either a large number of users wish to make image rendering requests, or a relatively few number of users wish to make a large number of different image rendering requests, based on 3D product/article models and associated artwork files which might be centrally stored, e.g. on a computer server. Additionally, the 25 local processing model precludes the receipt of remote processing requests, for example over a WAN. The applicants therefore have determined that it would be incredibly beneficial, and it is an object of this invention, to provide a system whereby multiple users could make 30 multiple image rendering requests and be later notified that their requests had been 5 WO 2006/103460 PCT/GB2006/001191 completed, whereby the user might then take some further action to retrieve the rendered image files. The fundamental difficulty with providing such a system is the need to have some 5 means of controlling how the processor of one or more machines operates. The reader may be aware of the "SETI@home" project which is currently in existence and widely known within the scientific research and IT communities, and which is embodied in a small downloadable program which individual PC users can install on their local machines to allow their machines to be integrated into a distributed 10 computing network. Briefly, this program allows the particular PC on which it is loaded to communicate with the SETI@home management program which in turn retrieves processed data or delivers unprocessed data to that PC for processing. The reason for the existence of 15 this project is that "SETI" or the "Search for Extra-terrestrial intelligence" involves monitoring the radio-frequency spectrum of the cosmos digitally and processing the results of each and every measurement taken. This requires the processing of such a vast amount of data that no single computer has yet been built which can carry out the job, and hence the concept of distributed computing used, whereby individuals 20 having only relatively small amounts of spare processing power devoted their computers to analysing only tiny fragments of the data, and then returning this data to the SETI management program for depositing in a database. Distributed, grid or cluster computing (such as the SETI@home project) is not new, 25 and there already exist a number of different mechanisms by which this might be carried out, but the present invention is distinguished from such systems as will become apparent from the below. The above is provided as an example of distributed computing where it is possible to 30 easily divide the enormous processing task into numerous (indeed maybe millions or even billions) of smaller tasks and to distribute these to individual PCs for 6 WO 2006/103460 PCT/GB2006/001191 processing. In the case of image rendering, this is much less easy to achieve (although it can and has already been done). Those in commercial image rendering houses will already be aware of the difficulties of providing production level image rendering wherein a number of successive image rendering requests are sent to a 5 single computer (usually a server or other high-end machine) without allowing significant time between each request. It is well known that placing too high a demand on any computer can easily cause it to fail by crashing, and image rendering is no exception. 10 It is an object of the invention to provide a system for controlling, distributing, returning and retrieving information about computer processor-intensive tasks conducted on one or more computers having processing capability, and specifically providing a management tool for achieving this. 15 It is a further object of the invention to provide a universal application and server information translation tool for monitoring, controlling, distributing and retrieving both processor-intensive tasks, in particular (though not exclusively) image rendering, and for providing information about the status of such tasks. 20 According to the present invention there is provided a computer processor intensive task management system including a front end element in the form of a graphical user interface to receive user input in the form of task parameters, a webserver element which contains all the various sections of the specific graphical 25 user interface for display and through which user input is made during the task parametrization procedure, said webserver element being capable of dealing with a plurality of client requests to display said graphical user interface on a plurality of separate clients and also dealing with a plurality of user inputs received from each of said clients; 7 WO 2006/103460 PCT/GB2006/001191 a middleware element which communicates with the webserver element and receives task parameters for each and every task requested by user, said middleware element further communicating with a back end element comprising processing power in the form of one or more clusters 5 of one or more computers having processing power for conducting the processor intensive tasks requested, and a storage element where the results of conducting the processor intensive tasks may be stored, wherein the middleware element includes 10 a queue function, a calculation function, a memory function, and a task distribution function, said queue function being used to hold details of all the tasks requested by the webserver, including the various parameters specifying those tasks, said calculation function being used to determine the likely amount of processor time involved in completing the particular task requested based on the task parameters 15 received by said middleware element for that task, said memory element being used to contain details of previously distributed tasks and the particular clusters to which they were sent, said distribution function being used to successively and intermittently distribute tasks within the queue, and wherein the distribution of the tasks in the queue by the middleware element is 20 made dependent on their determined completion time and also takes into account the predicted processor activity of clusters in the back end element to which previous tasks have already been sent. It is preferable that the middleware element further comprises a division function 25 which is capable of subdividing each requested task into smaller tasks each of which then occupies a position in the queue as would conventional non sub-divided tasks and may be prioritised and distributed accordingly. Preferably the queue element may be made up of both subdivided task portions and 30 whole tasks, and the distribution of either to the back end element is still managed by the middleware element according to the determination of likely processing time. 8 WO 2006/103460 PCT/GB2006/001191 Most preferably the webserver communicates with the storage element to retrieve details of completed tasks for display to users at clients of said webserver. Most preferably the particular tasks are image rendering tasks, in which case the 5 system further includes a database element containing details of each 3d article model and artwork adapted for that article, said back end element communicating with the database element to retrieve the relevant 3d article model file and artwork file for that article as a first step in the image rendering process, secondly rendering those two files according to the particular parameters given for that particular image 10 rendering task, and thirdly returning the rendered file to the storage element for later collection by the user. Most preferably, where the tasks are image rendering tasks, the storage element also includes small 3D images, based on the actual 3d article model file and associated 15 artwork file but reduced in resolution and size for display on a simple web-front end, and which can be selectively rotated about a variety of different axes, so that the user can choose in the graphical user interface which particular orientation of the image he wishes to have rendered by the system. 20 Those skilled in the art will be aware that web-based plug-ins are available which allow this functionality, the most notable being Shockwave® produced by Macromedia@. As an example, a web browser with such a plug-in installed can accept a suitable, 25 compatible image of a product have artwork pre-applied thereto, and using particular buttons of a mouse, can accurately and precisely control the angular orientation of the article being displayed in the browser. [Currently, it is to be noted that a very similar effect can be seen for mobile phones at www.nokia.com. In this display, the orientation of the mobile phone can be changed on screen so that any user can see all 30 sides of the phone in view.] 9 WO 2006/103460 PCT/GB2006/001191 It is preferable that in addition to this facility for viewing a digitised image of the article in any particular desired orientation, the graphical user interface (GUI) also includes provision for entering angular orientation parameters (as well as other parameters such as physical image size, resolution, quality etc.) manually through a 5 keyboard. Most preferably, the GUI allows for a user to select from a number of predefined parameters. 10 Examples of the types of processor intensive tasks to which the system of the invention might be ideally suited are 3D image rendering, scientific simulation, very large data warehouse systems, and any task which requires a large quantity of processing power or highly scalable multiple instances of lesser processing power. 15 As described above, the middleware consists of a set of applications which allow the users to utilize the power of large distributed computer networks (e.g. cluster/grid), for software that would not usually have access to this type of processing power. Effectively it acts as a translator between the client and the back end element. 20 Preferably, the middleware element is non-hardware or software specific in that it can handle various configurations of distributed/clustered server systems hardware, and can work with whatever configuration is needed to provide the optimum throughput and stability for any given task processing requirement. 25 As a result of this invention, and in particular the middleware element thereof, multiple clients can utilize any number of server rendering options and maintain a consistent throughput and level of performance, eliminating bottlenecks and data bandwidth issues associated with single server systems. 30 This makes the middleware a very flexible and dynamic piece of software, cutting down on the re-development time and cost of creating bespoke software every time a 10 WO 2006/103460 PCT/GB2006/001191 different type of server based renderer was needed. This also can be scaled up, almost indefinitely, providing more processing power, as demand grows. The middleware provided hereby can add extra functionality and stability to off the 5 shelf products, and is able to bring them into an automated enterprise class environment. For example, proprietary software such as 'BackBurner' by 'discreet', which is capable of linking in to 3D Studio Max for distributed network rendering, but the applicants herefor found that the "backburner" software regularly failed by crashing the server when only a relatively few number of image rendering requests 10 were made of it from 3D Studio Max. Middleware had to be created to provide the utilities and procedures required for a commercial, enterprise scalable, online (i.e. using web front end) rendering service. According to a further aspect of the invention, there is also provided an image 15 rendering service including all the elements of the system mentioned above. Most preferably the middleware element is capable of communicating with the various other elements of the system to retrieve and return relevant process information from and to said system elements. 20 Unlike existing proprietary software, the middleware described herein can process multiple users and multiple unique and non-unique image rendering requests simultaneously. Furthermore, it achieves this without producing errors or crashing, and most preferably this is achieved by assigning a unique ID to each task request it 25 receives (or first sub-dividing the particular tasks, assigning unique IDs to each of these tasks and then re-combining the tasks post processing) and communicates with the database element to ensure that the correct information and procedures are being performed for the correct user. 11 WO 2006/103460 PCT/GB2006/001191 Further preferably, the middleware element includes a time stamp facility for each task or subdivided task so that they can be processed and released to the user within specific time thresholds. 5 It is worth mentioning that proprietary software will release image rendering jobs only when a render node is available and' would not be able to add unique delays or settings, if required, and as can be achieved hereby. Also, not only does the middleware element access a database for article model and 10 artwork information and files, said database element can also include other less task specific information such as user accounts, angle data and product hits, render times and system performance. During the complete cycle of an image render, the middleware element will have handled and logged all associated data, which is used for maintenance, future system development, and marketing etc. The nature, amount, 15 and diversity of this data cannot be produced using existing proprietary software. The middleware element is also designed to accommodate different rendering platforms and acts as a multilingual translator. Existing proprietary software will process jobs using its native language and rendering platform only. 20 A yet further aspect of the middleware application is that commercial and industrial deployment considerations, such as account handling, billing and order tracking may be easily dealt with. Furthermore, the middleware element provides a means whereby requests from remote users with no knowledge of the particular system employed by 25 the invention can be received and processed apparently effortlessly without any requirement on the part of the user to understand how grid or distributed computing actually operates. A specific embodiment of the invention will now be described with reference to the 30 following figure. It should be noted that this specific embodiment is provided by 12 WO 2006/103460 PCT/GB2006/001191 way of example only, and a skilled reader will understand from the foregoing that the invention may easily be applied to other processor intensive applications.. Figure 1A provides a schematic overview of the system according to the invention, 5 Figure 1B provides a schematic indication of the proprietory work involved prior to the carrying out of processor intensive imaging rendering tasks by the system according to the invention, 10 Figure 2 shows a schematic of the system according to the present invention, and Figure 3 shows a schematic flow chart providing a simplistic representation of the process also according to the present invention. 15 Referring firstly to Figure 1A, there is shown a user/client "front end" 2A segregated virtually by dotted line 3A which communicates over the internet with a webserver element 4A (which might be incorporated as part of the overall middleware element of the invention, but is more likely to be separate therefrom) which in turn communicates with a middleware element 6A. Said middleware element comprises a 20 master application server 8A, a master database 10A, and a master storage component 12A. The master application server 8A is typically employed as a process scheduler, a render resource manager, a product updater, and/or an image processer/archiver. The master database 10 OA contains information such as product data, user data, server data, and financial data, whereas the master storage 12A may 25 contain master 3D article files, master artwork files, output files and proxy models. Said middleware element 6A may be accessed remotely, again over the internet, LAN, WAN or similar, by a production controller 14A, system analyst, or article and/or artwork modeller who might upload new article files and artwork files into the 30 middleware element 6A, which is additionally bounded in the Figure by dotted line 16A. 13 WO 2006/103460 PCT/GB2006/001191 The final components in the system overview Figure are the one or more render clusters 18A, 20A, 22A. In accordance with the invention, the middleware element communicates with these render clusters which perform the processor intensive tasks 5 before returning the resulting images back to the middleware for storage and/or ultimate return to the user/client. Although it will be clear from the following that certain configurations and functional elements of the middleware element are possible, the schematic Figure of 1A makes 10 clear that the middleware element might contain at least a storage and database element together with an application server element. Optionally, the middleware element might also include the webserver element. It is also to be mentioned that the application server element of the middleware might 15 additionally conduct one or more of the following functions: Post processing of images; Video compositing; Multi-frame image storage (to embrace animation); Resource management of the system at large; 20 Cluster node monitoring; Software Update propagation through system. Additionally, it is envisaged that an email notification/management engine might be included in the middleware element for issuing automatic notification to clients/users 25 when their processing requests are completed. Also, the middleware might automatically upload completed/processed image files directly to clients'/customers' servers using FTP (file transmission protocol). Referring now to Figure 1B, and in particular Sections (a) and (b) thereof, the 30 preparatory process steps for creating both suitable art work and/or textures files, and 3D model files are shown. Specifically, as far as creating art work or textures files is 14 WO 2006/103460 PCT/GB2006/001191 concerned, there are four potential means by which an art work or texture file may be originated, namely by taking a scan from existing art work, 2, using digital photography, 4, using existing digital artwork, 6, or creating an art work file from scratch, 8. In the case of pre-existing art work (2, 4, 6) additional preparation and 5 image manipulation will be required, 10, before a finished texture or art work file 12 can be provided. Referring now to Section (b) of Figure 1, it is a pre-requisit of the invention that a detailed 3D model in digital form be provided in conjunction with the relevant art 10 work or texture file 12, and in this regard either a 3 dimensional scan may be made of the article to be modelled, 14, and existed computer aided design (CAD) file may be used, 16, or a 3D model digital file may originated in a suitable software package such as 3D studio max, as indicated at 18. (Of course, it is envisaged that the application of artwork to article files may be automated to a certain extent; e.g. once 15 a standard tin shape has been produced by a modeller, large numbers of variants of artwork files can be produced by bespoke computer automation resulting in multiple types of tin, each with their own artwork). In a case of pre-existing model files, further preparation will be required as indicated 20 at 20 before a completed high resolution geometry file of the article which is being modelled is generated, 22. At this stage, the finished art work or texture file 12 may be applied to the high resolution geometry model file as generally indicated at 24, whereafter a completed high resolution model' including both geometry and artwork and/or textures is provided, 26. (It is to be mentioned that this file can be simplified 25 to create a low-resolution counterpart file). In accordance with the invention, this completed digital high resolution file is then stored in a suitable location, most probably on a storage element of the system (herein after described) as indicated at 28, and as a final step a database element of 30 the system is then updated with the relevant particulars of the completed high 15 WO 2006/103460 PCT/GB2006/001191 resolution digital file containing both the geometrical model and combined or associated artwork or textures, as indicated generally at 30. The reader will also understand from the above description of the system that a low 5 resolution model including associated artwork is required for display on the front end user interface to provide users of the system with a virtual image of the article and applied artwork which can be angularly orientated as desired by the user in the front end interface, but which nevertheless does not represent a significant band width limitation on the flow of information to and from the user, ie such files must be 10 relatively small. In this regard, the various process steps for high resolution model rendering as previously described are generally the same, and corresponding reference numerals suffixed with an A are used in the second part of section (b) of Figure 1. As can be seen at 26A, the various prior process steps result in a completed low resolution model digital file which includes the geometrical article shape which 15 has been modelled together with combined artwork and/or textures from the process described in section (a) of Figure 1. Once this digital file is in existence, it can then be exported as shown at 32, its resources are then stored for future reference at 34, and the relevant database element of the system is updated at 36. 20 Referring now to Figure 2, the various components and overview operation of the system according to the invention are described. The system includes various hardware and software elements including firstly a client PC40 networked in someway either by being connected to the internet, and intranet, 25 LAN or WLAN as indicated at 42. The client is indicated at 40 and provides a means by which a user 44 may interact with and/or control the system as a whole. The client communicates with a web server element 46 which includes a hardware element of a webserver 48 capable of servicing multiple client requests along communication channels 42 (of which there may be many 10s, 1 00s, or possibly even 30 1000s) and it is the web servers task to provide all the HTML, XML or other format files which may be displayed on the client computer 40, dependent on requests made 16 WO 2006/103460 PCT/GB2006/001191 thereby. The webserver element 46 also includes a database 50 with which the webserver communicates to access the low resolution models 26a created in the modelling process for display on the client computer 40. The webserver 48, as will be understood by the skilled reader is common practice, also receives the various 5 parameters for each image rendering request made by the user in the form of user input 52, and it is this user input which characterises each image rendering request made by the user. This information is then passed to a middleware element 54 which is responsible for the core management of the image rendering server cluster 56 and its ultimate output 58 in the form of rendered digital image files which are stored in a 10 suitable storage element 60 to which the webserver element 46 may optionally have access and be able to communicate therewith as indicated at 62. The image rendering server cluster 56 and/or the middleware element 54 can communicate with a database element 64 through communication channels 66, 68 respectively, and it is within this database element that various critical pieces of information, not to mention the 15 original artwork and/or texture files, and 3D article models may be stored. In accordance with the invention, the middleware element 54 comprises a variety of different functions schematically indicated at 72, 76, and these may include a queue function 70, a calculation function 72, a memory function 74, and a task distribution 20 function 78. There may also optionally be provided a division function 78. Referring now to Figure 3 in which the operation of the system is described, the overall purpose of the system as a whole is to enable users to view a large number of generally low resolution article model files on screen having relevant art work and/or 25 textures applied thereto and to orientate such models on screen using both keyboard and mouse (not shown), and to select various parameters for a render process to be conducted by the backend element of the system (basically consisting of the render server cluster 56). Such parameters will typically be the final size of the rendered image, and its resolution, but there may obviously be other parameters depending on 30 the complexity of the user interface. It is worth mentioning that the system according to the invention can provide a nunber of different file types (e.g., .png, .jpg and .tif) 17 WO 2006/103460 PCT/GB2006/001191 that are to be extended, so that the user can choose from web ready images (png), distribution ready images (jpg) and print ready images (tif). Accordingly, once the user has chosen the particular image on screen, its 5 orientation, and provided the various image rendering parameters required by the user interface provided on the client 40, a request is then sent to the webserver to begin the image rendering process of the particular image selected according to the various parameters given. At this stage, the webserver element then communicates with the middleware element of the system passing all the relevant information in terms of the 10 parameters and particular article thereto, and at this stage the middleware element then begins the process of determining the likely time taken to complete the image rendering request, and to prioritise and/or subdivide this particular image rendering task according to a variety of different factors including the number of requests already having been made of the render server cluster, the urgency of the particular 15 task, the relative state of completion of previously made image rendering requests as determined from the queue function, and a variety of other different variables. Accordingly it is to be understood that the middleware forms the overriding control colonel of the system in terms of both managing the tasks submitted to it and thence to the back end render server cluster 56, and in distributing those tasks either to 20 particular processing units within the render server cluster 56 (marked as A, 1, 2, 3, 4, 5, 6) or indeed further (not shown) render server clusters with which the middleware element 54 may communicate. Once the middleware element 54 has made all the relevant calculations and determinations as to priority, urgency etc, it then submits instructions to the back end element of the system, or a particular 25 hardware processing element thereof, and this in turn retrieves the relevant high resolution 3D geometric models, and the high resolutions artwork and/or texture files from the database element 64 and commences the processing task. Once the processing, ie the image rendering task is completed by the render server cluster or a particular element thereof, the completed and rendered image file is sent to the 30 storage element 60, and a communication is initiated between the render server cluster 56 and the middleware element 54 to indicate to said middleware element 54 18 WO 2006/103460 PCT/GB2006/001191 that the particular task is completed. At this stage, the middleware element 54 will communicate with the webserver element 46 to provide an indication that a particular user requested image rendering task is complete and further to provide an indication of the storage location where the completed rendered file may be retrieved from (a 5 particular location on the storage element 60). As all users of the system will be identifiable by their user name or other unique identifier, and information regarding that user will be stored as profile information in the database element 64, when that particular user logs back on to the client machine 10 after the completion of a previously requested image rendering task, the user will be notified through the graphical user interface provided on the client by the webserver, and thereafter the user will be able to request that the completed rendered file be downloaded for subsequent use. 15 In terms of the particular step identified in the flow chart provided in Figure 3, the above system can be specified by the provision of an essentially public website 80 to which a user 44 has access. That public website 80 receives user input 82, firstly in terms of a user log in 84, such information being queried at 86 against the database record for that particular user indicated generally at 88, and if the log in credentials 20 are correct then the user is permitted to access the first page of the graphical user interface supplied by the webserver to allow image rendering requests of the various articles held in the database to be made. This part of the process is generally indicated in Figure 3 at 90. 25 At this stage, the interface then receives further user input 92 and in the further various interactions between the web based interface provided on the client by the webserver and the user, indicated generally at 94, the user will provide a variety of different information to both select a desired article or product shown on the interface, provide various image rendering parameters connected to a desired image 30 rendering task for the particular article chosen, and all the various pieces of information which forms part of the overall user input will then be submitted through 19 WO 2006/103460 PCT/GB2006/001191 the webserver and will ultimately reside in the database element of the system. The final part of the total user input will involve the submission of the request for image rendering to be completed, and at this stage, the webserver will communicate with the middleware element, as generally indicated at 96 in Figure 3, and at this stage the 5 middleware element will then manage the process of image rendering by the render server cluster as previously described, and as schematically flow charted in Figure 3 at 98. The final stage in the process is the completion of particular image rendering tasks by 10 the render server cluster, and the return of the image rendered digital files to the user through the system, and this particular part of the process is schematically flow charted in Figure 3 at 100. It is important to note that the webserver element 46, and in particular the webserver 15 48, together with the middleware element 50 (which is envisaged as a software only element, but need not necessarily be so) are both capable of communicating either directly -or indirectly with the database element 64 in which all the details of particular image rendering tasks and the particular users requesting those tasks is stored. In Figure 2, the communication between the webserver element 46 and the 20 database element 64 is shown as being indirect though the middleware element 54, but this need not necessarily be the case, and the webserver 48 may communicate directly with the database element 64. In summary therefore, a computer processor intensive task management system is 25 described. The system includes a front end element in the form of a graphical user interface to receive user input in the form of task parameters, a webserver element to contains all the various sections of the specific graphical user interface for display and through which user input is made during the task parametrization procedure, a middleware element which communicates with the webserver element and receives 30 task parameters for each and every task requested by user, and a back-end element 20 WO 2006/103460 PCT/GB2006/001191 comprising processing power. The system also includes a storage element which may optionally be integrated with the middleware element or separate therefrom. 21

Claims (12)

1. A computer processor intensive task management system including a front end element in the form of a graphical user interface to receive user input in 5 the form of task parameters, a webserver element which contains all the various sections of the specific graphical user interface for display and through which user input is made during the task parametrization procedure, said webserver element being capable of dealing with a plurality of client requests to display said graphical user interface on a plurality of 10 separate clients and also dealing with a plurality of user inputs received from each of said clients; a middleware element which communicates with the webserver element and receives task parameters for each and every task requested by user, said middleware element further communicating with 15 a back end element comprising processing power in the form of one or more clusters of one or more computers having processing power for conducting the processor intensive tasks requested, and a storage element where the results of conducting the processor intensive tasks may be stored, 20 wherein the middleware element includes a queue function, a calculation function, a memory function, and a task distribution function, said queue function being used to hold details of all the tasks requested by the webserver, including the various parameters specifying those tasks, said calculation function being used to determine the likely amount of processor time 25 involved in completing the particular task requested based on the task parameters received by said middleware element for that task, said memory element being used to contain details of previously distributed tasks and the particular clusters to which they were sent, said distribution function being used to successively and intermittently distribute tasks within the queue, 30 and wherein the distribution of the tasks in the queue by the middleware element is made dependent on their determined completion time and also takes into account the 22 WO 2006/103460 PCT/GB2006/001191 predicted processor activity of clusters in the back end element to which previous tasks have already been sent.

2. A system according to claim 1 wherein the middleware element further 5 comprises a division function which is capable of subdividing each requested task into smaller tasks each of which then occupies a position in the queue as would conventional non sub-divided tasks and may be prioritised and distributed accordingly. 10

3. A system according to claim 2 wherein the queue element is made up of both subdivided task portions and whole tasks, the distribution of either to the back end element being managed by the middleware element according to the determination of likely processing time. 15

4. A system according to any preceding claim wherein the webserver communicates with the storage element to retrieve details of completed tasks for display to users at clients of said webserver.

5. A system according to any preceding claim wherein the particular tasks are 20 image rendering tasks, said system further includes a database element containing digital files representing each article and artwork adapted for application to that article, said back end element communicating with the database element to retrieve the relevant article file and artwork file for that article as a first step in the image rendering process, secondly rendering those two files according to the particular 25 parameters given for that particular image rendering task, and thirdly returning the rendered file to the storage element for later collection by the user.

6. A system according to claim 5 wherein the storage element also includes small images, based on the actual article file and associated artwork file but reduced 30 in resolution and size for display on a simple web-front end, and which can be selectively rotated about, translated along, and/or transformed in relation to a variety 23 WO 2006/103460 PCT/GB2006/001191 of different axes, so that the user can choose in the graphical user interface which particular orientation of the image he wishes to have rendered by the system.

7. A system according to any preceding claim wherein the middleware element 5 is not specific, either in terms of hardware or software, to the configurations of the different elements of the system.

8. A system according to claim 7 wherein the middleware element is provided in the form of an application programming interface (API). 10

9. A system according to any preceding claim wherein the middleware element includes a time stamp facility for each task or subdivided task so that they can be processed and released to the user within specific time thresholds. 15

10. A computer program comprising computer program code means adapted to perform the steps required in the delivery of the system according to any of claims 1 9 when loaded on a computer.

11. The computer program of claim 10 when embodied on a computer readable 20 medium.

12. An image rendering service including all the elements of the system as claim in any preceding claim. 24