In the good ol’ days of image processing it was common practice to use specialized interface cards (framegrabbers) to connect an image sensor to a computing unit. But as the consumer grade interfaces included in nearly all computers kept evolving over time they today are often “good enough” and much cheaper than specialized hardware you have to add to the IPC.

So we now mostly use Ethernet or even USB ports to do image acquisition.

Whereas a frame grabber usually comes with detailed information on which image format and acquisition bandwidth it can handle, you rarely will find such information on a generic USB or Ethernet port. We could have added this kind of data elements to a machine vision specific definition of such ports to close that gap, but we did not find this very useful.

Such generic port types are widely used and there will be definitions how to describe them outside of the image processing world.

Instead, we decided to keep the information that is specific to image processing applications in a separate object that may be attached to a port using a reference.

Even in such a scenario you may want to have a frame grabber entity, even if this is now a software instead of a hardware component, whose hardware aspects are hosted by another physical interface.

Figure 68 – Image Transceivers

This approach has a big advantage. As consumer interfaces are usually very cheap, modern IPCs come with a lot of them. Often it does not really matter which Ethernet or which USB port the camera is connected to as they are technically identical. So you have some built in redundancy. If you decide to connect the image sensor to Ethernet Port1 instead of Port2, no objects in the model need to be changed. Simply the two “IsHostedBy” references need to be shifted to the other Ethernet port.