US20050185494A1 - Method and system for extensible data processing - Google Patents
Method and system for extensible data processing Download PDFInfo
- Publication number
- US20050185494A1 US20050185494A1 US11/115,844 US11584405A US2005185494A1 US 20050185494 A1 US20050185494 A1 US 20050185494A1 US 11584405 A US11584405 A US 11584405A US 2005185494 A1 US2005185494 A1 US 2005185494A1
- Authority
- US
- United States
- Prior art keywords
- operator
- multiport
- base
- image
- processing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T1/00—General purpose image data processing
- G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
- G06F9/4492—Inheritance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T1/00—General purpose image data processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
- G06V10/00—Arrangements for image or video recognition or understanding
- G06V10/94—Hardware or software architectures specially adapted for image or video understanding
Definitions
- the invention relates generally to images of specimens.
- the invention relates to extendable image processing architectures.
- An image of a biological specimen can be a useful tool in diagnosing a variety of pathological conditions. For instance, images of biological specimens can reveal cells in the process of dividing. Since cancer is characterized by rapidly dividing cells, an image showing an unusually large number of cells dividing can indicate the presence of cancerous cells.
- one operation can be a filter that selectively generates a processed image according to filtering criteria, such as selecting a particular type of specimen within an image.
- the processed image could then be presented to another processing operation, such as a threshold operation that renders a new processed image of specimen images that exceed a particular defined threshold.
- the number and types of image processing operations can change over time, and vary with respect to a desired application.
- a change is usually required to the image processing software code which requires completely recompiling the code with the changes.
- conventional systems do not allow parametric changes on the fly during runtime of an application without stopping the application and/or needing to recompile the application code.
- a system for assembling an application for processing image or image-derived data includes a base operator configured to interface with one or more derivative operator classes, each operator class including an operator object for executing a processing function on the image or image-derived data.
- the system according to the embodiment further includes a base multiport node class configured to provide a multiport node object for each operator object.
- the multiport node objects instantiate a pluggable operator for connecting the multiport node objects together at runtime according to user-defined parameters, and wherein the connection of multiport node objects implements the processing functions of the operator objects to execute the application.
- a method of assembling an application for processing image or image-derived data includes providing a base operator having an interface for interacting with one or more derivative operator classes, each operator class including an operator object for executing an processing function on the image or image-derived data.
- the method further includes providing a base multiport node configured to provide a multiport node for each interacting operator object, and connecting the multiport nodes with a pluggable operator instantiated by the multiport nodes.
- FIG. 1 illustrates a system for imaging a biological specimen.
- FIG. 2 is a pictorial representation of an extendible and dynamically reconfigurable processing architecture.
- FIG. 3 is a schematic diagram of interconnected multiport nodes.
- FIG. 4 is a block diagram of a processing architecture to illustrate a functional flow of an implementation of one algorithm, in accordance with an embodiment of the invention.
- FIGS. 5 and 6 show specific examples of a processing application configured in accordance with an plug-in architecture of an embodiment of the invention.
- FIG. 1 illustrates a system 10 for imaging and/or viewing of a specimen 14 .
- the system 10 includes a stage 12 where a specimen 14 can be positioned.
- An imaging device 16 views the specimen 14 through an optics assembly 18 .
- the imaging device 16 is configured to generate an image of the specimen 14 and can be moved relative to the specimen 14 .
- Moving the imaging device 16 relative to the stage 12 can include moving the stage 12 while holding the imaging device 16 stationary or moving the imaging device 16 while holding the stage 12 stationary.
- the imaging device 16 can be moved so it views different regions of the specimen 14 .
- the imaging device 16 can then generate an image of each of these different regions.
- Suitable imaging devices 16 include, but are not limited to, area cameras.
- the optics assembly 18 controls the focal plane of the imaging device 16 such that the imaging device 16 is focused on a surface of the specimen 14 of at a particular depth within the specimen 14 .
- the system 10 also includes a processing unit 20 in communication with the imaging device 16 , a display 22 and one or more user interfaces 24 .
- the processing unit 20 houses electronics 26 for controlling various operations of the system 10 .
- the electronics 26 can control movement of the imaging device 16 relative to the specimen 14 .
- the display 22 can be used to show at least a portion of one or more specimen images 38 which have been generated by the system 10 .
- the displayed image is visible to an operator in a display area.
- the display 22 can also be used to indicate a variety of system 10 conditions to the operator.
- An operator can use the one or more user interfaces 24 to interact with the system 10 and vary system parameters. For instance, an operator can use a user interface to manipulate the display area 28 . The operator can change the portion of a specimen image 38 which is visible by scrolling to a new portion of the specimen image 38 , zooming in and/or zooming out on the specimen image 38 .
- a suitable user interface includes, but is not limited to, a keyboard and a mouse. Although a single processing unit 20 , one or more user interfaces 24 and display 22 are illustrated, the system 10 can include a plurality of processing units 20 , displays 22 and user interfaces 24 .
- the electronics 26 can include one or more processors 30 for performing instructions stored or carried on a machine readable medium 32 .
- processors 30 include, but are not limited to, programmed general purpose digital computers, microprocessors, digital signal processors (DSP), integrated circuits, application specific integrated circuits (ASICs), logic gate arrays and switching arrays.
- the one or more processors 30 are in communication with one or more working memories 34 and one or more storage memories 36 .
- Suitable working memories 34 include, but are not limited to, volatile memories such as RAM and other memories from which a processor primarily works during execution of instructions.
- Suitable storage memories 36 include, but are not limited to, non-volatile memories such as a disk drive.
- the working memory and/or the storage device are examples of or contain machine readable media which store data developed during operation of the system 10 and/or instructions to be executed by the one or more processors 30 .
- Other machine readable media which can serve as the working memory and/or the storage device include, but are not limited to, optical discs such as a compact disk (CD), CD-ROM, CD-R (a recordable CD-ROM that can be read on a CD-ROM drive), CD-RW (multiple-write CD), CD-E (recordable and erasable CD), or DVD (digital video disc).
- the machine readable media can include one or more of the following: a magnetic data storage diskette (floppy disk), a Zip disk, DASD storage (e.g., a conventional “hard drive” or a RAID array), magnetic tape, RAM, electronic read-only memory (e.g., ROM, EPROM, or EEPROM), paper punch cards, or transmission media such as digital and/or analog communication links.
- a magnetic data storage diskette floppy disk
- DASD storage e.g., a conventional “hard drive” or a RAID array
- magnetic tape e.g., a conventional “hard drive” or a RAID array
- RAM random access memory
- electronic read-only memory e.g., EPROM, or EEPROM
- paper punch cards e.g., paper punch cards, or transmission media such as digital and/or analog communication links.
- one or more of the machine readable media are positioned outside or remote from the processing unit 20 .
- the machine readable medium 32 may be part of, or may be connected to, a server computer that is connected to a network, in order to make the machine-readable code available to other computers.
- the network may be a local area network (LAN), a wide area network (WAN), or any other type of network.
- This arrangement enables one or more other computers connected to the network to copy instructions and/or data from the machine readable medium 32 that is part of, or connected to, the (server) computer, to a machine readable medium 32 that is part of, or connected to, the processing unit 20 . This may be accomplished, for example, by connecting computers from one or more networks, over the Internet.
- the machine readable medium 32 may be part of, or may be connected to, a computer that is operating a bulletin board system 10 (BBS), which can be accessed by other computers.
- BBS bulletin board system 10
- This arrangement enables the processing unit 20 to connect to the BBS and copy the instructions and/or data from the machine readable medium 32 that is part of, or connected to, the computer that is operating the BBS, to the machine readable medium 32 in communication with the processing unit 20 .
- FIG. 2 is a pictorial representation of an extendible and dynamically reconfigurable processing architecture 100 .
- the processing architecture 100 can be implemented as an object-oriented software program running in the processing unit 20 for processing image data.
- FIG. 2 illustrates generalization/inheritance (i.e. “is-a”) and aggregation (“has-a”) relationships among domain abstractions in an object-oriented embodiment of the architecture.
- base processing abstraction classes include a base multiport node 102 and a base operator 104 .
- Processing abstractions are formed of the base abstractions and their derivatives.
- base operator derivatives provide image- or image-derived data processing and measurement operator classes
- base multiport node derivatives dynamically assemble the base operator objects into a functional processing system at runtime.
- the abstract base classes provide interfaces for object collaborations, and serve as a basis for user-customization of processing applications.
- the base operator 104 is an abstract class implementing an API.
- a new class is derived from the base operator 104 , and override the appropriate virtual functions.
- the system only calls functions in the base operator API to accomplish processing tasks, and therefore the system is not dependent on additional functions (helper functions, etc.) added to the interface of these newly-derived classes.
- Each operator object 110 has N inputs and M outputs (also referred to as ports) and return these values through a series of functions for getting the number of respective ports. For each input and output port, the operator object 110 returns the type information for that port.
- the operator implementation overrides a base operator's virtual function, called processOperatorInputs( ), that processes the operator object inputs. All base operator objects are responsible for creating and managing the lifetime of their outputs, thus the operator object's 110 virtual destructor must free these output resources when the object is destroyed.
- the operator object 110 when the operator object 110 is constructed by the system, the following general interface protocols are established.
- a function processOperatorInputs( ) When a function processOperatorInputs( ) is called, an array of pointers to n valid base object 101 objects is passed in through the apInput input parameter. An array that holds m pointers to base object 101 objects is passed in though the apOutput parameter—a processOperatorInputs( ) function is expected to copy the appropriate base object pointers into this array to represent the result of the operation for which it is responsible.
- the type information does not generally change during the operator object's lifetime. Similarly, the operator object does not change the type information associated with its outputs.
- the three classes, the base multiport node 102 , multiport node 106 and pluggable operator 108 isolate the base operator 104 from dependencies within the structure of the system, while providing the interconnection and modular processing functionality.
- the pluggable operator 108 has a pointer to each base operator derived object 110 .
- the pluggable operator 108 calls the operator class functions to determine the number of inputs and outputs, and their associated types. This information enables the pluggable operator 108 to create the input and output arrays, which contain the pointers to the base object class 101 objects. These arrays are used as parameters for an operator input processing function, to accomplish the associated image processing.
- the pluggable operator 108 calls the node's 106 predecessors to get references to the appropriate base object class 101 objects and then copies these references into the input array before calling the operator input processing function. Similarly, when the call to the operator inputs processing function returns to the pluggable operator 108 , the results of the operation can then be passed to the node's ancestors from the output references in the same manner.
- the call direction is one way from the pluggable operator 108 to the base operator-derived operator object, and never the other way.
- the pluggable operator 108 calls functions of the operator objects 10 only through a base operator 104 abstract base class interface. The use of the base operator 104 as an abstract base class isolates the system from changes in implementations of the operator objects 10 derived from the base operator 104 .
- the pluggable operator 108 is derived from the abstract base class multiport node 106 .
- the multiport node 106 includes implementations necessary to support the plugging aspects for the interconnection of the operator ports between processing nodes.
- the multiport node 106 does not directly support the base operator objects 10 , and has no dependencies on them.
- the pluggable operator 108 makes all calls to the operator object functions, and isolates the rest of the system from these calls and functions.
- the multiport node 106 is derived from the base multiport node 102 class.
- the base multiport node 102 is a pure abstract interface without implementation code.
- the base multiport node 102 forms an application programming interface (API). Since the system generally handles processing nodes through the base multiport node 102 , changes to the partial implementation of multiport nodes 106 do not require recompilation of those components though this abstract interface.
- API application programming interface
- a maker function for the class must be implemented so that instances of the new object can be constructed and dynamically loaded by the system at runtime. Since object code for the new operator will be compiled after the processing application is compiled, it is not possible to directly link this newly defined operator object into the application. However, since the pluggable operator 108 operates on this new operator object though the base operator 104 , it is not necessary for the system to know all of the details related to this specific operator object. If the system can get a valid base operator pointer from a dynamically created object derived from the base operator base class, this will enable the system to dynamically load the new object into the system, and the pluggable operator 108 can operate on it.
- the maker function operates as follows in an exemplary embodiment.
- the API user also defines a standard C function that constructs this new operator and returns a pointer to it. For instance, if a new operator called CabcLinearFilter was derived from base operator 104 , a standard C function returning a valid base operator pointer would suffice. For instance, a single statement can be used such as (new CabcLinearFilter).
- the system can construct the new operator object 10 .
- the path to the DLL and the name of the maker function must be known.
- Conventional operating systems allow dynamical loading of libraries into a running process, such as, e.g. LoadLibrary( ), dlopen( ), etc.
- the library module, shared object, etc.
- the address of specific functions are then available though the function names, for example, GetProcAddress( ), dlsym( ), etc.
- the maker function it will have a valid base operator pointer for passing to the pluggable operator 108 object.
- the base operator 104 abstracts processing functionality of the application.
- the base operator 104 is an abstract base class whose primary responsibility is to provide a generalized interface so that processing functions done by operator objects, derived from the base operator, such as functions to provide a data source, filter, threshold, or data sink, etc. can be dealt with in a generic manner.
- the getSymbolicName( ) and setSymbolicName( ) are exemplary names that represent functions for assigning an arbitrary text label to the operator object for identification and description of the particular operator object.
- This text label may be something like “Edge detecting Linear Filter,” and can be changed throughout the operator object's lifetime.
- the base multiport node class abstracts the plugging together of and doing processing on, interconnected base multiport nodes.
- the base multiport node class is an abstract base class whose primary responsibility is to provide a generalized interface to isolate the system using it from the actual implementation details that support the behaviors provided. For instance, a user of the base multiport node class knows nothing about the object that does the actual processing (i.e. the actual operator object derived from the base operator).
- the multiport node abstract class implements the plugging together with other multiport nodes, which enables the multiport nodes to do their ‘work’ on their inputs.
- the multiport node class is derived from base multiport node, in part to isolate the base multiport node class from changes in the implementation of the algorithm. Since the pure virtual functions are not all implemented in the multiport node class, this class is still abstract, and thus cannot be directly instantiated.
- the multiport node includes the following functions. For initializing the input/output port count, the following functions can be used:
- the pluggable operator class is derived from multiport node class, and is a fully implemented class—it can be instantiated. Of the three classes discussed in the multiport node class hierarchy, the pluggable operator class is the only class that knows about the base operator class, and which operations are held by the base operator class to accomplish the actual processing done by the multiport nodes that are connected together.
- the pluggable operator implements many of the pure virtual functions in the base multiport node interface by forwarding calls to a member function of the operator object that it holds.
- the pure virtual member function in the base multiport node interface is implemented by the pluggable operator class.
- the PluggableOperator::doIt( ) function ultimately calls the virtual BaseOperator::processOperatorInputs( ) member function to do the processing work
- the virtual processOperatorInputs( ) function can be implemented by the class derived from the base operator class.
- the initializing, processing and de-initializing functions of the pluggable operator include:
- the configuration and persistence functions which can include calls forwarded to the base operator object managed by the pluggable operator are:
- FIG. 3 is a schematic diagram of interconnected multiport nodes 106 .
- Each multiport node 106 has N input ports 111 and M output ports 1112 .
- the multiport nodes 106 derived from the base multiport node class, implement the connectivity from outputs 112 of one or more multiport nodes 106 to inputs 111 of one or more other multiport nodes 106 .
- the connectivity defines the functionality of an image processing application, and supports pluggability of one functional node to another.
- a pluggable operator derived from the multiport node 106 , supports the actual processing performed by the interconnected multiport nodes 106 via operator objects 110 .
- FIG. 4 is a block diagram of a processing architecture to illustrate a functional flow of an implementation of one algorithm, in accordance with an embodiment of the invention.
- images are obtained from a cytometer 118 by a source multiport node 120 .
- the processing architecture then performs image processing functions and extracts sub portions of the original image so that areas of interest (AOI) can be inserted into an image table for archival storage.
- AOI areas of interest
- the directed arrows illustrate the connectivity between the output and input ports of the multiport nodes.
- the input ports are shown on the left side of the box labeled “pluggable operator,” and the output ports are shown on the right side of the box.
- the interconnectivity of the multiport nodes is supported by the multiport node class hierarchy.
- the boxes directly below the pluggable operators are operator objects 110 that are derived from the base operator.
- the solid connector signifies that the pluggable operator owns the operator object.
- the operator objects are configured to manage their own outputs.
- the image/measurement output objects are connected by a line with a solid connector.
- Some of the operator objects may not own objects that they use, and are indicated by a hollow connector.
- FIGS. 5 and 6 show specific examples of a processing application configured in accordance with an plug-in architecture of an embodiment of the invention. Other configurations are possible.
- FIG. 5 shows a plurality of multiport nodes connected together to accomplish a specific set of operator object functions.
- image data is provided by a cytometer microscopy imaging platform.
- Each multiport node, labeled as such, is related to an operator object such as “queue,” “filter,” and so on.
- the multiport nodes are connected together such that execution of all of the operator objects accomplishes a desired application.
- FIG. 6 demonstrates a system in which the same application shown in FIG. 5 can be used for processing multiple threads of image- or image-derived data, such as when multiple scans of the same images are performed.
- the disclosure can be applied to processing images of non-biological specimens.
- the specimens can be semiconductor wafer and/or integrated circuits. Accordingly, the disclosure can be useful for inspection of integrated circuits and other solid state applications.
Abstract
A system and method of assembling an application for processing image or image-derived data is disclosed. The system includes a base operator configured to interface with one or more derivative operator classes, each operator class including an operator object for executing a processing function on the image or image-derived data. A base multiport node class is provided, which is configured to provide a multiport node for each operator object. The multiport nodes instantiates a pluggable operator for connecting the multiport nodes together at runtime according to user-defined parameters. The connection of multiport nodes implements the processing functions of the operator objects to execute the application.
Description
- This application claims the benefit of U.S. Provisional Application No. 60/177,111, filed Jan. 20, 2000 and entitled “A Software Framework for Scanning Cytometry,” which is incorporated herein in its entirety.
- 1. Field of the Invention
- The invention relates generally to images of specimens. In particular, the invention relates to extendable image processing architectures.
- 2. Description of the Related Art
- An image of a biological specimen can be a useful tool in diagnosing a variety of pathological conditions. For instance, images of biological specimens can reveal cells in the process of dividing. Since cancer is characterized by rapidly dividing cells, an image showing an unusually large number of cells dividing can indicate the presence of cancerous cells.
- Various image processing operations can be performed on the images or image-derived data. For instance, one operation can be a filter that selectively generates a processed image according to filtering criteria, such as selecting a particular type of specimen within an image. The processed image could then be presented to another processing operation, such as a threshold operation that renders a new processed image of specimen images that exceed a particular defined threshold.
- The number and types of image processing operations can change over time, and vary with respect to a desired application. In order to change the image processing operations, or change parameters of particular processing operations, a change is usually required to the image processing software code which requires completely recompiling the code with the changes. Further, conventional systems do not allow parametric changes on the fly during runtime of an application without stopping the application and/or needing to recompile the application code. For the above reasons, there is a need for a system and method for customizing an image processing platform, which supports the ability to be dynamically defined during run time of the image processing operations.
- The invention relates to a architecture for a customizable image processing platform. In one embodiment of the invention, a system for assembling an application for processing image or image-derived data includes a base operator configured to interface with one or more derivative operator classes, each operator class including an operator object for executing a processing function on the image or image-derived data. The system according to the embodiment further includes a base multiport node class configured to provide a multiport node object for each operator object. The multiport node objects instantiate a pluggable operator for connecting the multiport node objects together at runtime according to user-defined parameters, and wherein the connection of multiport node objects implements the processing functions of the operator objects to execute the application.
- In accordance with another embodiment, a method of assembling an application for processing image or image-derived data includes providing a base operator having an interface for interacting with one or more derivative operator classes, each operator class including an operator object for executing an processing function on the image or image-derived data. The method further includes providing a base multiport node configured to provide a multiport node for each interacting operator object, and connecting the multiport nodes with a pluggable operator instantiated by the multiport nodes.
-
FIG. 1 illustrates a system for imaging a biological specimen. -
FIG. 2 is a pictorial representation of an extendible and dynamically reconfigurable processing architecture. -
FIG. 3 is a schematic diagram of interconnected multiport nodes. -
FIG. 4 is a block diagram of a processing architecture to illustrate a functional flow of an implementation of one algorithm, in accordance with an embodiment of the invention. -
FIGS. 5 and 6 show specific examples of a processing application configured in accordance with an plug-in architecture of an embodiment of the invention. -
FIG. 1 illustrates asystem 10 for imaging and/or viewing of aspecimen 14. Thesystem 10 includes astage 12 where aspecimen 14 can be positioned. Animaging device 16 views thespecimen 14 through anoptics assembly 18. Theimaging device 16 is configured to generate an image of thespecimen 14 and can be moved relative to thespecimen 14. Moving theimaging device 16 relative to thestage 12 can include moving thestage 12 while holding theimaging device 16 stationary or moving theimaging device 16 while holding thestage 12 stationary. As a result, theimaging device 16 can be moved so it views different regions of thespecimen 14. Theimaging device 16 can then generate an image of each of these different regions.Suitable imaging devices 16 include, but are not limited to, area cameras. Theoptics assembly 18 controls the focal plane of theimaging device 16 such that theimaging device 16 is focused on a surface of thespecimen 14 of at a particular depth within thespecimen 14. - The
system 10 also includes aprocessing unit 20 in communication with theimaging device 16, adisplay 22 and one ormore user interfaces 24. Theprocessing unit 20 houseselectronics 26 for controlling various operations of thesystem 10. For instance, theelectronics 26 can control movement of theimaging device 16 relative to thespecimen 14. Thedisplay 22 can be used to show at least a portion of one ormore specimen images 38 which have been generated by thesystem 10. The displayed image is visible to an operator in a display area. Thedisplay 22 can also be used to indicate a variety ofsystem 10 conditions to the operator. - An operator can use the one or
more user interfaces 24 to interact with thesystem 10 and vary system parameters. For instance, an operator can use a user interface to manipulate thedisplay area 28. The operator can change the portion of aspecimen image 38 which is visible by scrolling to a new portion of thespecimen image 38, zooming in and/or zooming out on thespecimen image 38. A suitable user interface includes, but is not limited to, a keyboard and a mouse. Although asingle processing unit 20, one ormore user interfaces 24 anddisplay 22 are illustrated, thesystem 10 can include a plurality ofprocessing units 20, displays 22 anduser interfaces 24. - The
electronics 26 can include one ormore processors 30 for performing instructions stored or carried on a machinereadable medium 32.Suitable processors 30 include, but are not limited to, programmed general purpose digital computers, microprocessors, digital signal processors (DSP), integrated circuits, application specific integrated circuits (ASICs), logic gate arrays and switching arrays. - The one or
more processors 30 are in communication with one or moreworking memories 34 and one ormore storage memories 36. Suitable workingmemories 34 include, but are not limited to, volatile memories such as RAM and other memories from which a processor primarily works during execution of instructions.Suitable storage memories 36 include, but are not limited to, non-volatile memories such as a disk drive. - The working memory and/or the storage device are examples of or contain machine readable media which store data developed during operation of the
system 10 and/or instructions to be executed by the one ormore processors 30. Other machine readable media which can serve as the working memory and/or the storage device include, but are not limited to, optical discs such as a compact disk (CD), CD-ROM, CD-R (a recordable CD-ROM that can be read on a CD-ROM drive), CD-RW (multiple-write CD), CD-E (recordable and erasable CD), or DVD (digital video disc). Alternatively, instead of, or in addition to an optical disc, the machine readable media can include one or more of the following: a magnetic data storage diskette (floppy disk), a Zip disk, DASD storage (e.g., a conventional “hard drive” or a RAID array), magnetic tape, RAM, electronic read-only memory (e.g., ROM, EPROM, or EEPROM), paper punch cards, or transmission media such as digital and/or analog communication links. - In some instances, one or more of the machine readable media are positioned outside or remote from the
processing unit 20. For instance, the machinereadable medium 32 may be part of, or may be connected to, a server computer that is connected to a network, in order to make the machine-readable code available to other computers. The network may be a local area network (LAN), a wide area network (WAN), or any other type of network. This arrangement enables one or more other computers connected to the network to copy instructions and/or data from the machinereadable medium 32 that is part of, or connected to, the (server) computer, to a machinereadable medium 32 that is part of, or connected to, theprocessing unit 20. This may be accomplished, for example, by connecting computers from one or more networks, over the Internet. - In other instances, the machine
readable medium 32 may be part of, or may be connected to, a computer that is operating a bulletin board system 10 (BBS), which can be accessed by other computers. This arrangement enables theprocessing unit 20 to connect to the BBS and copy the instructions and/or data from the machine readable medium 32 that is part of, or connected to, the computer that is operating the BBS, to the machine readable medium 32 in communication with theprocessing unit 20. -
FIG. 2 is a pictorial representation of an extendible and dynamically reconfigurable processing architecture 100. The processing architecture 100 can be implemented as an object-oriented software program running in theprocessing unit 20 for processing image data.FIG. 2 illustrates generalization/inheritance (i.e. “is-a”) and aggregation (“has-a”) relationships among domain abstractions in an object-oriented embodiment of the architecture. In particular, base processing abstraction classes include abase multiport node 102 and abase operator 104. Processing abstractions are formed of the base abstractions and their derivatives. For instance, base operator derivatives provide image- or image-derived data processing and measurement operator classes, and base multiport node derivatives dynamically assemble the base operator objects into a functional processing system at runtime. The abstract base classes provide interfaces for object collaborations, and serve as a basis for user-customization of processing applications. - As illustrated in
FIG. 2 , all processing operations are derived from thebase operator 104. In an exemplary embodiment, thebase operator 104 is an abstract class implementing an API. In order to create a new processing operator, a new class is derived from thebase operator 104, and override the appropriate virtual functions. The system only calls functions in the base operator API to accomplish processing tasks, and therefore the system is not dependent on additional functions (helper functions, etc.) added to the interface of these newly-derived classes. - An outline of the functionality and responsibilities for an implementation of base operator derived classes, or operator objects 110 is as follows. Each
operator object 110 has N inputs and M outputs (also referred to as ports) and return these values through a series of functions for getting the number of respective ports. For each input and output port, theoperator object 110 returns the type information for that port. To implement the algorithm functionality, the operator implementation overrides a base operator's virtual function, called processOperatorInputs( ), that processes the operator object inputs. All base operator objects are responsible for creating and managing the lifetime of their outputs, thus the operator object's 110 virtual destructor must free these output resources when the object is destroyed. - In a specific example, when the
operator object 110 is constructed by the system, the following general interface protocols are established. When a function processOperatorInputs( ) is called, an array of pointers to nvalid base object 101 objects is passed in through the apInput input parameter. An array that holds m pointers to base object 101 objects is passed in though the apOutput parameter—a processOperatorInputs( ) function is expected to copy the appropriate base object pointers into this array to represent the result of the operation for which it is responsible. For each input port, the type information does not generally change during the operator object's lifetime. Similarly, the operator object does not change the type information associated with its outputs. If an operator has either its connectivity to other processing nodes changed, or its configuration changed, it is possible that this could cause a change in the number of input/output ports and their associated types. Changes in the connectivity or the configuration of operators are not allowed in the midst of a processing cycle; thus, the number and types of the input/output ports should never change during a processing cycle. - The three classes, the
base multiport node 102,multiport node 106 andpluggable operator 108 isolate thebase operator 104 from dependencies within the structure of the system, while providing the interconnection and modular processing functionality. Thepluggable operator 108 has a pointer to each base operator derivedobject 110. Thepluggable operator 108 calls the operator class functions to determine the number of inputs and outputs, and their associated types. This information enables thepluggable operator 108 to create the input and output arrays, which contain the pointers to thebase object class 101 objects. These arrays are used as parameters for an operator input processing function, to accomplish the associated image processing. - Based on the processing connectivity of the
multiport nodes 106, thepluggable operator 108 calls the node's 106 predecessors to get references to the appropriatebase object class 101 objects and then copies these references into the input array before calling the operator input processing function. Similarly, when the call to the operator inputs processing function returns to thepluggable operator 108, the results of the operation can then be passed to the node's ancestors from the output references in the same manner. The call direction is one way from thepluggable operator 108 to the base operator-derived operator object, and never the other way. Thepluggable operator 108 calls functions of the operator objects 10 only through abase operator 104 abstract base class interface. The use of thebase operator 104 as an abstract base class isolates the system from changes in implementations of the operator objects 10 derived from thebase operator 104. - As illustrated by the class hierarchy shown in
FIG. 2 , thepluggable operator 108 is derived from the abstract baseclass multiport node 106. Themultiport node 106 includes implementations necessary to support the plugging aspects for the interconnection of the operator ports between processing nodes. Themultiport node 106 does not directly support the base operator objects 10, and has no dependencies on them. Thepluggable operator 108 makes all calls to the operator object functions, and isolates the rest of the system from these calls and functions. - The
multiport node 106 is derived from thebase multiport node 102 class. Thebase multiport node 102 is a pure abstract interface without implementation code. In an exemplary embodiment, thebase multiport node 102 forms an application programming interface (API). Since the system generally handles processing nodes through thebase multiport node 102, changes to the partial implementation ofmultiport nodes 106 do not require recompilation of those components though this abstract interface. - After the API user has defined a new processing element to be derived from
base operator 104 as anoperator object 10, a maker function for the class must be implemented so that instances of the new object can be constructed and dynamically loaded by the system at runtime. Since object code for the new operator will be compiled after the processing application is compiled, it is not possible to directly link this newly defined operator object into the application. However, since thepluggable operator 108 operates on this new operator object though thebase operator 104, it is not necessary for the system to know all of the details related to this specific operator object. If the system can get a valid base operator pointer from a dynamically created object derived from the base operator base class, this will enable the system to dynamically load the new object into the system, and thepluggable operator 108 can operate on it. - The maker function operates as follows in an exemplary embodiment. Within the same dynamic link library (DLL) defining the new operator, the API user also defines a standard C function that constructs this new operator and returns a pointer to it. For instance, if a new operator called CabcLinearFilter was derived from
base operator 104, a standard C function returning a valid base operator pointer would suffice. For instance, a single statement can be used such as (new CabcLinearFilter). - Once a new base operator-derived
operator object 110 has been defined along with the appropriate maker function, the system can construct thenew operator object 10. The path to the DLL and the name of the maker function must be known. Conventional operating systems allow dynamical loading of libraries into a running process, such as, e.g. LoadLibrary( ), dlopen( ), etc. Once the library (module, shared object, etc.) is loaded by the process, the address of specific functions are then available though the function names, for example, GetProcAddress( ), dlsym( ), etc. After the system calls the maker function, it will have a valid base operator pointer for passing to thepluggable operator 108 object. These steps allow the system to dynamically load, create and connect a processing block that uses the functionality in this newly defined operator. - In more detail, and in accordance with an exemplary embodiment, the roles and responsibilities of the base abstract classes and derivatives follows.
- The
base operator 104 abstracts processing functionality of the application. Thebase operator 104 is an abstract base class whose primary responsibility is to provide a generalized interface so that processing functions done by operator objects, derived from the base operator, such as functions to provide a data source, filter, threshold, or data sink, etc. can be dealt with in a generic manner. - In an embodiment, the getSymbolicName( ) and setSymbolicName( ) are exemplary names that represent functions for assigning an arbitrary text label to the operator object for identification and description of the particular operator object. This text label may be something like “Edge detecting Linear Filter,” and can be changed throughout the operator object's lifetime.
- These classes are implementations that are subclassed from the base operator abstract class. There are several pure virtual functions not implemented by the base operator that must be implemented before the derived class can be instantiated, or actually created in an executable. One responsibility of an operator object is to create and manage its own outputs. In an example embodiment, other functions of the operator objects are:
-
- getName( ): returns a label that describes the operator object. This label can be constant over the object's lifetime.
- getNumOperatorInputs( ): defines how many inputs (images, measurement, etc) that the operator utilizes to accomplish its processing task(s). The number of inputs can be from 0 to n.
- getInPortTypeInfo( ): for each of the inputs, describes the type with which they are compatible. For instance, if
input port 0 says it requires a BaseImage type, a CQMIplImage can be provided at this port, since CQMIplImage is derived from BaseImage and therefore is compatible. - getNumOperatorOutputs( ): defines how many outputs (images, measurement, etc) that the operator will provide as output upon completion of its processing task(s). The number of inputs can be from 0 to n.
- getOutPortTypeInfo( ): for each of the outputs, describes the type with which they are compatible. For instance, if
output port 0 says it provides a BaseImage compatible type, a CQMIplImage can be provided at this port as CQMIplImage is derived from BaseImage (and is thus is compatible).
- For configuration and persistence, the following functions can be used:
-
- getConfigList( ): retrieves the current configuration parameters.
- setConfigList( ): sets the current configuration parameters, assuming each parameter is valid.
- validConfig( ): verifies whether the operator has a valid configuration.
- reset( ): restores the default configuration.
- restoreConfig( ): read from an istream to restore the configuration.
- saveConfig( ): write to an ostream to save the configuration.
- For pre- and post-processing, the following functions can be used:
-
- initValidateInputsSetupOutputs( ): determines if the current configuration is valid for the operator. Creates valid output(s) based on the configuration and the inputs and return references to these valid output(s). This function merely has to create valid outputs, and does not have to do the actual processing done in the processOperatorInputs( ) function. Further, this function is generally called only once before the processOperatorInputs( ) function is called.
- processOperatorInputs( ) performs the actual processing. In general, this function is called several times during a processing loop. For instance, when processing a 10unit×10unit image scan, each operator is called 100 times.
- The general guarantee to the processing function is as follows:
-
- An array of valid pointers to valid inputs is passed in via an array and these inputs are valid during the function call.
- An array that can hold pointers for each of the outputs will be passed in as well. Upon successful completion of the processing done by this operator, references to the outputs (managed by this operator) are copied into this array before returning from this function. This is how the results of this operation are passed to the outside. The output references must remain valid until the next call to one of the following three functions (initValidateInputsSetupOutputs, processOperatorInputs or deinit), or when the operator object is destroyed.
- deinit ( ): when finished with processing, this function is called so the operator can finish up any other needed processing, free resources used in its processing, etc. This function is generally called only once after the calls to processOperatorInputs( ) are finished. Once this function is called, the initValidateInputsSetupOutputs function must be successfully called before the processOperatorInputs( ) function is called again.
- The base multiport node class abstracts the plugging together of and doing processing on, interconnected base multiport nodes. The base multiport node class is an abstract base class whose primary responsibility is to provide a generalized interface to isolate the system using it from the actual implementation details that support the behaviors provided. For instance, a user of the base multiport node class knows nothing about the object that does the actual processing (i.e. the actual operator object derived from the base operator).
- The multiport node abstract class implements the plugging together with other multiport nodes, which enables the multiport nodes to do their ‘work’ on their inputs. The multiport node class is derived from base multiport node, in part to isolate the base multiport node class from changes in the implementation of the algorithm. Since the pure virtual functions are not all implemented in the multiport node class, this class is still abstract, and thus cannot be directly instantiated.
- In an example implementation, the multiport node includes the following functions. For initializing the input/output port count, the following functions can be used:
-
- setNumInPorts( ): called by the pluggable operator sub-class since only it knows about the BaseOperator::getNumoperatorInputs( ) function to get the information.
- setNumOutPorts( ): called by the pluggable operator sub-class since only it knows about the BaseOperator::getNumOperatorOutputs( ) function to get the information.
- For connectivity with other multiport nodes, the following functions can be used:
-
- attachInPort( ): attaches a specified input port to a specific output port of another multiport node.
- attachOutPort( ): attaches a specified input port to a specific output port of another multiport node.
- validateConnectivityAtInPort( ): validates that a specific input port is connected to another multiport node.
- validateConnectivityAtOutPort( ): validates that a specific output port is connected to another multiport node.
- validateConnectivityForNode( ): validates connectivity for all input and output ports.
- For getting input data for a multiport node from predecessor nodes:
-
- getOutPortDataRef( ): for a specific output port, retrieves a reference (pointer) to output data that is owned and managed by a predecessor multiport node. The pluggable operator subclass calls the getOutPortDataRef function to get valid input data pointers so that it can call this output data from a predecessor multiport node is used by the pluggable operator class to pass input data into the BaseOperator:: processOperatorInputs( ) function.
- The pluggable operator class is derived from multiport node class, and is a fully implemented class—it can be instantiated. Of the three classes discussed in the multiport node class hierarchy, the pluggable operator class is the only class that knows about the base operator class, and which operations are held by the base operator class to accomplish the actual processing done by the multiport nodes that are connected together.
- The pluggable operator implements many of the pure virtual functions in the base multiport node interface by forwarding calls to a member function of the operator object that it holds. For example, the pure virtual member function in the base multiport node interface is implemented by the pluggable operator class. The PluggableOperator::doIt( ) function ultimately calls the virtual BaseOperator::processOperatorInputs( ) member function to do the processing work In one embodiment, the virtual processOperatorInputs( ) function can be implemented by the class derived from the base operator class.
- The initializing, processing and de-initializing functions of the pluggable operator include:
-
- getOutPortDataRef( ): for a specific output port, retrieves a reference (pointer) to output data that is owned and managed by a predecessor multiport node. The pluggable operator calls a getOutPortDataRef function to get valid input data pointers so that it can call the output data from a predecessor multiport node. This pointer is used by the pluggable operator to pass input data into the BaseOperator:: processOperatorInputs( ) function.
- The configuration and persistence functions, which can include calls forwarded to the base operator object managed by the pluggable operator are:
-
- getConfigList( ): retrieves the current configuration parameters by forwarding call to the base operator object it manages.
- setConfigList( ): sets the current configuration parameters (assuming parameter(s) are valid) by forwarding call to the base operator object it manages.
- validConfig( ): determines whether the operator currently has a valid configuration by forwarding call to the base operator object it manages.
- reset( ): restore a default configuration by forwarding the call to the base operator object it manages.
- restoreConfig( ): this function reads from an istream to restore the configuration by forwarding call to the base operator object it manages.
- saveConfig( ): this function writes to an ostream to save the configuration by forwarding call to the base operator object it manages.
- For pre- and post-processing, including calls forwarded to the base operator object managed by the pluggable operator:
-
- initValidateSetup( ): determines if the current configuration and input parameters are valid for the operator managed by the pluggable operator, validates each of the inputs passed in, creates valid output(s) based on the configuration and the inputs and return references to these valid output(s). Once the input/output arrays are set up and initialized, the function calls the BaseOperator::initValidateInputsSetupOutputs( ) to do the work. Upon returning from the initValidateInputsSetupOutputs( ) function, the pluggable operator can save references to the valid output objects so that the multiport nodes connected to this node's outputs can get valid inputs when their initValidateSetup( ) function is called.
- doIt( ): performs the actual processing. This processing is accomplished by forwarding the call to base operator object it manages. After some setup of the input and output arrays, the function BaseOperator::processOperatorInputs( ) is called to do the actual processing work.
- deinit( ): when finished with processing, this function is called on the base operator managed by this pluggable operator so that operator object can finish any final processing, free resources used in its processing, etc. This is done by forwarding the call to the BaseOperator::deinit( ) function. Once this function is called, the PluggableOperator::initValidateSetup( ) function must be successfully called before the doIt( ) function is called again.
-
FIG. 3 is a schematic diagram of interconnectedmultiport nodes 106. Eachmultiport node 106 hasN input ports 111 and M output ports 1112. Themultiport nodes 106, derived from the base multiport node class, implement the connectivity fromoutputs 112 of one or moremultiport nodes 106 toinputs 111 of one or more othermultiport nodes 106. The connectivity defines the functionality of an image processing application, and supports pluggability of one functional node to another. A pluggable operator, derived from themultiport node 106, supports the actual processing performed by theinterconnected multiport nodes 106 via operator objects 110. -
FIG. 4 is a block diagram of a processing architecture to illustrate a functional flow of an implementation of one algorithm, in accordance with an embodiment of the invention. In the embodiment, images are obtained from acytometer 118 by a sourcemultiport node 120. The processing architecture then performs image processing functions and extracts sub portions of the original image so that areas of interest (AOI) can be inserted into an image table for archival storage. - The directed arrows illustrate the connectivity between the output and input ports of the multiport nodes. The input ports are shown on the left side of the box labeled “pluggable operator,” and the output ports are shown on the right side of the box. The interconnectivity of the multiport nodes is supported by the multiport node class hierarchy. The boxes directly below the pluggable operators are
operator objects 110 that are derived from the base operator. The solid connector signifies that the pluggable operator owns the operator object. The operator objects are configured to manage their own outputs. Thus, the image/measurement output objects are connected by a line with a solid connector. Some of the operator objects may not own objects that they use, and are indicated by a hollow connector. -
FIGS. 5 and 6 show specific examples of a processing application configured in accordance with an plug-in architecture of an embodiment of the invention. Other configurations are possible.FIG. 5 shows a plurality of multiport nodes connected together to accomplish a specific set of operator object functions. In the example, image data is provided by a cytometer microscopy imaging platform. Each multiport node, labeled as such, is related to an operator object such as “queue,” “filter,” and so on. The multiport nodes are connected together such that execution of all of the operator objects accomplishes a desired application.FIG. 6 demonstrates a system in which the same application shown inFIG. 5 can be used for processing multiple threads of image- or image-derived data, such as when multiple scans of the same images are performed. - Although the above disclosure is applicable to biological specimens, the disclosure can be applied to processing images of non-biological specimens. For instance, the specimens can be semiconductor wafer and/or integrated circuits. Accordingly, the disclosure can be useful for inspection of integrated circuits and other solid state applications.
- Other embodiments, combinations and modifications of this invention will occur readily to those of ordinary skill in the art in view of these teachings. Therefore, this invention is to be limited only by the following claims, which include all such embodiments and modifications when viewed in conjunction with the above specification and accompanying drawings.
Claims (20)
1. A system for assembling an application for processing image or image-derived data, comprising:
a base operator configured to interface with one or more derivative operator classes, each operator class including an operator object for executing a processing function on the image or image-derived data; and
a base multiport node class configured to provide a multiport node for each operator object, the multiport nodes instantiating a pluggable operator for connecting the multiport nodes together at runtime according to user-defined parameters, and wherein the connection of multiport nodes implements the processing functions of the operator objects to execute the application.
2. The system of claim 1 , wherein each multiport node includes N inputs and M outputs, each input and output having a connection with at least one other multiport node.
3. The system of claim 1 , wherein the pluggable operator includes a pointer to an operator object.
4. The system of claim 1 , wherein the pluggable operator is an class derived from the multiport node.
5. The system of claim 3 , wherein the pluggable operator is configured to call the operator object.
6. The system of claim 3 , wherein the pointer is based on the user-defined parameters.
7. The system of claim 6 , wherein the user-defined parameters are dynamically definable at run time of the application.
8. The system of claim 7 , wherein the pluggable operator is configured to adapt the pointer array to changes in the user-defined parameters.
9. The system of claim 8 , wherein each multiport node is configured to adapt to changes in the pointer array.
10. The system of claim 9 , wherein the base operator interface is configured to enable more or less operator classes at runtime.
11. A method of assembling an application for processing image or image-derived data, comprising:
providing a base operator having an interface for interacting with one or more derivative operator classes, each operator class including an operator object for executing an processing function on the image or image-derived data;
providing a base multiport node configured to provide a multiport node for each interacting operator object; and
connecting the multiport nodes with a pluggable operator instantiated by the multiport nodes.
12. The method of claim 11 , wherein the pluggable operator includes a pointer to an operator object.
13. The method of claim 12 , wherein the pointer is configured according to a set of user-defined parameters specified by the base operator.
14. The method of claim 11 , wherein the connection of the multiport nodes defines the application.
15. The method of claim 14 , further comprising receiving user-defined parameters at runtime of the application.
16. The method of claim 13 , further comprising reconfiguring the connections of the multiport nodes according to user defined parameters received at runtime of the application.
17. The method of claim 12 , wherein connecting the multiport nodes is based on the user-defined parameters.
18. The method of claim 11 , wherein each multiport node includes N inputs and M outputs.
19. The method of claim 18 , wherein each input and output of each multiport node is connected to at least one other multiport node.
20. The method of claim 11 , further comprising reconfiguring the application with at least one new operator object at runtime of the application.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/115,844 US20050185494A1 (en) | 2000-01-20 | 2005-04-26 | Method and system for extensible data processing |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17711100P | 2000-01-20 | 2000-01-20 | |
US09/766,390 US6886168B2 (en) | 2000-01-20 | 2001-01-19 | Method and system for extensible data processing |
US11/115,844 US20050185494A1 (en) | 2000-01-20 | 2005-04-26 | Method and system for extensible data processing |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/766,390 Continuation US6886168B2 (en) | 2000-01-20 | 2001-01-19 | Method and system for extensible data processing |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050185494A1 true US20050185494A1 (en) | 2005-08-25 |
Family
ID=22647236
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/766,390 Expired - Lifetime US6886168B2 (en) | 2000-01-20 | 2001-01-19 | Method and system for extensible data processing |
US10/228,759 Expired - Lifetime US7352920B2 (en) | 2000-01-20 | 2002-08-26 | Managing images of microscopic specimens |
US11/115,844 Abandoned US20050185494A1 (en) | 2000-01-20 | 2005-04-26 | Method and system for extensible data processing |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/766,390 Expired - Lifetime US6886168B2 (en) | 2000-01-20 | 2001-01-19 | Method and system for extensible data processing |
US10/228,759 Expired - Lifetime US7352920B2 (en) | 2000-01-20 | 2002-08-26 | Managing images of microscopic specimens |
Country Status (5)
Country | Link |
---|---|
US (3) | US6886168B2 (en) |
EP (1) | EP1249005A2 (en) |
AU (1) | AU2001229666A1 (en) |
CA (1) | CA2397912A1 (en) |
WO (1) | WO2001054061A2 (en) |
Families Citing this family (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6971066B2 (en) * | 1997-08-18 | 2005-11-29 | National Instruments Corporation | System and method for deploying a graphical program on an image acquisition device |
US7158888B2 (en) | 2001-05-04 | 2007-01-02 | Takeda San Diego, Inc. | Determining structures by performing comparisons between molecular replacement results for multiple different biomolecules |
US7756305B2 (en) | 2002-01-23 | 2010-07-13 | The Regents Of The University Of California | Fast 3D cytometry for information in tissue engineering |
US7327396B2 (en) * | 2002-04-10 | 2008-02-05 | National Instruments Corporation | Smart camera with a plurality of slots for modular expansion capability through a variety of function modules connected to the smart camera |
US8442280B2 (en) * | 2004-01-21 | 2013-05-14 | Edda Technology, Inc. | Method and system for intelligent qualitative and quantitative analysis of digital radiography softcopy reading |
WO2005104941A2 (en) * | 2004-04-14 | 2005-11-10 | Edda Technology, Inc. | Lesion marking and characterization quality assurance method and system |
EP1746499A1 (en) | 2005-07-05 | 2007-01-24 | Siemens Aktiengesellschaft | System and method for developping a software or softwarecomponent and method for operating such a software |
US7933435B2 (en) * | 2005-11-21 | 2011-04-26 | Vala Sciences, Inc. | System, method, and kit for processing a magnified image of biological material to identify components of a biological object |
US20100194868A1 (en) * | 2006-12-15 | 2010-08-05 | Daniel Peled | System, apparatus and method for flexible modular programming for video processors |
WO2010044870A1 (en) * | 2008-10-14 | 2010-04-22 | The Burnham Institute For Medical Research | Automated scanning cytometry using chromatic aberration for multiplanar image acquisition |
BRPI0921978A2 (en) | 2008-11-26 | 2019-01-15 | Calgary Scient Inc | method of providing remote access to application program state and storage media. |
US10055105B2 (en) | 2009-02-03 | 2018-08-21 | Calgary Scientific Inc. | Method and system for enabling interaction with a plurality of applications using a single user interface |
US8640147B2 (en) * | 2010-11-11 | 2014-01-28 | International Business Machines Corporation | Method and system for virtualizing connection end-points in distributed, component based applications at runtime |
US9741084B2 (en) | 2011-01-04 | 2017-08-22 | Calgary Scientific Inc. | Method and system for providing remote access to data for display on a mobile device |
CA2734860A1 (en) | 2011-03-21 | 2012-09-21 | Calgary Scientific Inc. | Method and system for providing a state model of an application program |
CN103782541B (en) | 2011-08-15 | 2018-11-27 | 卡尔加里科学公司 | A method of it provides and remotely accesses at least one application program |
EP2761808A4 (en) | 2011-09-30 | 2015-05-20 | Calgary Scient Inc | Uncoupled application extensions including interactive digital surface layer for collaborative remote application sharing and annotating |
SG11201402546WA (en) | 2011-11-23 | 2014-06-27 | Calgary Scient Inc | Methods ans systems for collaborative remote application sharing and conferencing |
US9613390B2 (en) | 2012-05-02 | 2017-04-04 | Nvidia Corporation | Host context techniques for server based graphics processing |
US9805439B2 (en) | 2012-05-02 | 2017-10-31 | Nvidia Corporation | Memory space mapping techniques for server based graphics processing |
US9542715B2 (en) | 2012-05-02 | 2017-01-10 | Nvidia Corporation | Memory space mapping techniques for server based graphics processing |
US9311169B2 (en) * | 2012-05-02 | 2016-04-12 | Nvidia Corporation | Server based graphics processing techniques |
EP3075111B1 (en) | 2013-11-29 | 2017-12-20 | Calgary Scientific Inc. | Method for providing a connection of a client to an unmanaged service in a client-server remote access system |
US10015264B2 (en) * | 2015-01-30 | 2018-07-03 | Calgary Scientific Inc. | Generalized proxy architecture to provide remote access to an application framework |
Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5313387A (en) * | 1989-06-30 | 1994-05-17 | Digital Equipment Corporation | Re-execution of edit-compile-run cycles for changed lines of source code, with storage of associated data in buffers |
US5359730A (en) * | 1992-12-04 | 1994-10-25 | International Business Machines Corporation | Method of operating a data processing system having a dynamic software update facility |
US5410703A (en) * | 1992-07-01 | 1995-04-25 | Telefonaktiebolaget L M Ericsson | System for changing software during computer operation |
US5504917A (en) * | 1986-04-14 | 1996-04-02 | National Instruments Corporation | Method and apparatus for providing picture generation and control features in a graphical data flow environment |
US5631974A (en) * | 1990-08-31 | 1997-05-20 | Canon Research Centre Europe, Ltd. | Image processing |
US6006279A (en) * | 1997-01-21 | 1999-12-21 | Canon Information Systems, Inc. | Plug-in module host framework |
US6011919A (en) * | 1994-07-25 | 2000-01-04 | Canon Information Systems Research Australia Pty Ltd. | Method of providing efficiency to a graphical programming language with alternative form determination and cost of execution estimation |
US6018743A (en) * | 1996-10-04 | 2000-01-25 | International Business Machines Corporation | Framework for object-oriented interface to record file data |
US6202208B1 (en) * | 1998-09-29 | 2001-03-13 | Nortel Networks Limited | Patching environment for modifying a Java virtual machine and method |
US6240550B1 (en) * | 1998-07-21 | 2001-05-29 | Touchtunes Music Corporation | System for remote loading of objects or files in order to update software |
US6463583B1 (en) * | 1999-04-08 | 2002-10-08 | Novadigm, Inc. | Dynamic injection of execution logic into main dynamic link library function of the original kernel of a windowed operating system |
US6557017B1 (en) * | 1998-02-06 | 2003-04-29 | Xerox Corporation | Image production system theme integration |
US6651080B1 (en) * | 1998-10-16 | 2003-11-18 | Sun Microsystems, Inc. | Techniques for implementing pluggable virtual machines |
US7020766B1 (en) * | 2000-05-30 | 2006-03-28 | Intel Corporation | Processing essential and non-essential code separately |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5313575A (en) * | 1990-06-13 | 1994-05-17 | Hewlett-Packard Company | Processing method for an iconic programming system |
AU724393B2 (en) * | 1995-11-30 | 2000-09-21 | Chromavision Medical Systems, Inc. | Method and apparatus for automated image analysis of biological specimens |
US20040085443A1 (en) * | 2000-12-13 | 2004-05-06 | Kallioniemi Olli P | Method and system for processing regions of interest for objects comprising biological material |
-
2001
- 2001-01-19 WO PCT/US2001/001928 patent/WO2001054061A2/en active Application Filing
- 2001-01-19 CA CA002397912A patent/CA2397912A1/en not_active Abandoned
- 2001-01-19 EP EP01942766A patent/EP1249005A2/en not_active Ceased
- 2001-01-19 US US09/766,390 patent/US6886168B2/en not_active Expired - Lifetime
- 2001-01-19 AU AU2001229666A patent/AU2001229666A1/en not_active Abandoned
-
2002
- 2002-08-26 US US10/228,759 patent/US7352920B2/en not_active Expired - Lifetime
-
2005
- 2005-04-26 US US11/115,844 patent/US20050185494A1/en not_active Abandoned
Patent Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5504917A (en) * | 1986-04-14 | 1996-04-02 | National Instruments Corporation | Method and apparatus for providing picture generation and control features in a graphical data flow environment |
US5313387A (en) * | 1989-06-30 | 1994-05-17 | Digital Equipment Corporation | Re-execution of edit-compile-run cycles for changed lines of source code, with storage of associated data in buffers |
US5631974A (en) * | 1990-08-31 | 1997-05-20 | Canon Research Centre Europe, Ltd. | Image processing |
US5410703A (en) * | 1992-07-01 | 1995-04-25 | Telefonaktiebolaget L M Ericsson | System for changing software during computer operation |
US5359730A (en) * | 1992-12-04 | 1994-10-25 | International Business Machines Corporation | Method of operating a data processing system having a dynamic software update facility |
US6011919A (en) * | 1994-07-25 | 2000-01-04 | Canon Information Systems Research Australia Pty Ltd. | Method of providing efficiency to a graphical programming language with alternative form determination and cost of execution estimation |
US6018743A (en) * | 1996-10-04 | 2000-01-25 | International Business Machines Corporation | Framework for object-oriented interface to record file data |
US6006279A (en) * | 1997-01-21 | 1999-12-21 | Canon Information Systems, Inc. | Plug-in module host framework |
US6557017B1 (en) * | 1998-02-06 | 2003-04-29 | Xerox Corporation | Image production system theme integration |
US6240550B1 (en) * | 1998-07-21 | 2001-05-29 | Touchtunes Music Corporation | System for remote loading of objects or files in order to update software |
US6202208B1 (en) * | 1998-09-29 | 2001-03-13 | Nortel Networks Limited | Patching environment for modifying a Java virtual machine and method |
US6651080B1 (en) * | 1998-10-16 | 2003-11-18 | Sun Microsystems, Inc. | Techniques for implementing pluggable virtual machines |
US6463583B1 (en) * | 1999-04-08 | 2002-10-08 | Novadigm, Inc. | Dynamic injection of execution logic into main dynamic link library function of the original kernel of a windowed operating system |
US7020766B1 (en) * | 2000-05-30 | 2006-03-28 | Intel Corporation | Processing essential and non-essential code separately |
Also Published As
Publication number | Publication date |
---|---|
WO2001054061A3 (en) | 2001-12-20 |
CA2397912A1 (en) | 2001-07-26 |
AU2001229666A1 (en) | 2001-07-31 |
WO2001054061A2 (en) | 2001-07-26 |
US7352920B2 (en) | 2008-04-01 |
US20030033090A1 (en) | 2003-02-13 |
US6886168B2 (en) | 2005-04-26 |
US20010033299A1 (en) | 2001-10-25 |
EP1249005A2 (en) | 2002-10-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20050185494A1 (en) | Method and system for extensible data processing | |
US5742848A (en) | System for passing messages between source object and target object utilizing generic code in source object to invoke any member function of target object by executing the same instructions | |
US6993706B2 (en) | Method, apparatus, and program for a state machine framework | |
US7010778B2 (en) | Method, apparatus, and program for a state machine framework | |
US20020199034A1 (en) | System and method for visual application development without programming | |
US7237199B1 (en) | Architecture for an application framework | |
US8539441B2 (en) | Method and system for specifying and developing application systems with dynamic behavior | |
US5805796A (en) | System architecture for implementing modular diagnostics | |
US6633313B1 (en) | Event routing mechanism in a computer system | |
JP2011165208A (en) | Method and system for developing image processing application | |
Hanus | A functional logic programming approach to graphical user interfaces | |
Kuck et al. | Improving the avango vr/ar framework: Lessons learned | |
Kafura et al. | Concurrent object-oriented languages and the inheritance anomaly | |
US6704802B1 (en) | Method and system for communicating between independent software modules | |
US6571146B1 (en) | Method for updating feature recipes in a history-based solid model | |
EP0981086A1 (en) | Method for creating composite object methods and attributes | |
US7062773B1 (en) | System and method for providing graphical user interface control enhancers | |
CN113485686B (en) | Information system program generation method and device, electronic equipment and storage medium | |
US8028274B2 (en) | Integrating loosely coupled tools using contracts and references | |
Adam et al. | The role of service abstraction and service variability and its impact on requirements engineering for service-oriented systems | |
Zhao et al. | Role modelling for component design | |
Nesnas et al. | A robotic software developed using object-oriented design | |
Bubak et al. | Towards a monitoring interface specification for distributed Java applications | |
Lin | A Framework for Automatic Algorithm Animation | |
P´ nek et al. | Object-oriented developmental environment for image-analysis applications: implementation for 2D gel electrophoretogram analysis |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |