Allocating an application context and its systems
Mandatory allocations for an application context
At the beginning of each application, you must:
-
Allocate a MIL application context using MappAlloc(). This creates a control and execution environment for your imaging application.
-
Allocate a MIL system using MsysAlloc(). A MIL system typically refers to a set of hardware components capable of grabbing, storing, processing, and/or displaying images. There are two types of MIL systems:
-
Board-type system. Consists of a Matrox imaging board (or third-party board that is compatible with MIL), the Host CPU and memory, and any available graphics controller. You will need to allocate a MIL system for each Matrox imaging board (or third-party board) that you want to use, whether the board is installed on the local or remote computer.
-
Host-type system. Consists of the Host CPU and memory, and any available graphics controller. You can allocate a Host-type system on the main Host computer or remote computer when a Matrox imaging board (or third party board) is not available or is not required.
When you allocate a system, MIL opens communication channels and initializes the system (or hardware resources). Once Host communication has been established with a system, you can allocate its memory resources, display, and input capabilities. When a remote computer is specified during system allocation, the resources of the specified computer are made available: its specified Matrox imaging board (or third-party board), its CPU, and its memory.
-
At the end of each application, free each system using MsysFree(), and then free the application context using MappFree().
Board-type versus Host-type systems
On a computer without a Matrox imaging board (or supported third-party board), you can allocate a Host-type system which can store, process, and display images, but cannot grab images from a camera. Instead, images can be loaded from file (or a simulated DCF video) and some acquisition capabilities are available through a simulated digitizer. Such a system could be used to process existing images, display results, and perform some simulated acquisition operations.
On a computer with a Matrox imaging board (or supported third-party board), you can allocate a Host-type system and/or a board-type system. If you allocate a Host-type system, the system will be able to store, process, and display images. If you allocate a board-type system, the system will be able to store, process, and display images, and provide additional functionality depending on the installed board.
The board-type systems that allow the use of third-party (non-Matrox) boards are:
-
MIL IEEE 1394b IIDC system. Supports the Matrox Concord F-series adapter boards, and MIL-compatible third-party 1394 adapter boards. IEEE 1394b IIDC systems allow image grabs from IEEE 1394 IIDC cameras.
-
MIL GigE Vision system. Supports Matrox Concord G-series network interface cards (NICs), and MIL-compatible third-party NICs. GigE Vision systems allow image grabs from GigE Vision-compliant cameras.
-
MIL GPU system. Supports most display boards that support DirectX 9.0 or later. Accelerates image processing operations.
Note, systems can have many data buffers, displays, and digitizers.
The functionality provided by Matrox imaging boards (and third-party boards) varies from one board to the next. Some boards only provide frame-grabbing functionality (for example, Matrox CronosPlus), while others provide grabbing and processing functionality (for example, Matrox Radient).
Note, for information about functionality and hardware limitations specific to your target system, refer to the MIL Hardware-specific Notes.
Multiple systems
You can allocate more than one system per application context and then use their identifiers to access their devices and memory resources. Note that, depending on your Matrox imaging board, two concurrent MIL applications might not be able to share the same MIL system. In these cases, only one application can allocate a system for a board at a given time. For information on your Matrox imaging board's capablities, refer to the MIL Hardware-specific Notes.
Processing can be done between many systems. Any operation involving more than one system will be performed by the most appropriate one. By default, if none of these systems is more appropriate than the Host, the Host is used to perform the operation.
Remote systems
When a remote computer is specified during system allocation, both the local and remote computer must have MIL/MIL-Lite installed with the Distributed MIL option. A MIL application that uses remote systems is called a Distributed MIL controlling configuration, and the remote systems are called DMIL remote systems. In a Distributed MIL controlling configuration, multiple DMIL remote systems can collaborate with each other and with local systems across a network (for example, a local area network, or a wide area network such as the internet) controlled by a single MIL application. A group of computers interacting using Distributed MIL is called a cluster.
When developing a Distributed MIL controlling application that uses functionality only available in the full version of MIL, the local computer requires a MIL development license; the remote computer(s) only require appropriate runtime licenses for Distributed MIL and the MIL modules that they actually use. When only running such an application, all computers in the cluster require appropriate runtime licenses for Distributed MIL and the MIL modules that they actually use; sending a command to another computer is not using a module so no specific license is needed in this case.
When developing or running a Distributed MIL application that uses only MIL-Lite functionality, the local and remote computers require a Distributed MIL supplemental license.
For more information on Distributed MIL, see Chapter 29: Distributed MIL.