100GigE Unleashed

The bottleneck is no longer in the camera. It is in the system.

Most machine vision engineers know exactly when a system is failing. What they often cannot explain is why, because the camera metrics look fine, the interface is running at full bandwidth, and the hardware on paper should be more than capable. The answer, in an increasing number of high-speed deployments, is that the problem was never where they were looking. A single modern industrial camera can generate more data per second than an entire machine vision system could handle a decade ago. Multi-camera installations today routinely push aggregate data rates into the tens of gigabytes per second range, and the sensors capable of doing this are no longer exotic or expensive. The bottleneck has moved. It is no longer inside the camera.

This shift is not just a technical curiosity. It changes where engineering effort needs to go, what skills system integrators need, and which suppliers actually have the experience to deliver. Image processing is increasingly moving from CPU-based architectures toward GPU-accelerated pipelines, often combined with edge computing close to the sensor. In these environments, capturing the image has become the easy part. Handling the data is where systems succeed or fail.

Over the past decade, CMOS sensor technology has advanced at an extraordinary pace. Sony in particular has driven many of these developments with its Pregius and Pregius S platforms, which have become a cornerstone of modern industrial imaging. Higher resolutions, improved sensitivity and steadily increasing frame rates have unlocked applications that were difficult or even impossible only a few years ago. But this same progress has fundamentally shifted where the real engineering challenges in imaging systems lie. For a long time, the primary bottleneck in high-performance machine vision was either the sensor itself or the camera interface used to transport image data to the host system. Today, that is increasingly no longer the case. Modern sensors can generate enormous data streams, and high-bandwidth interfaces such as 100GigE are fully capable of transporting them. The real challenge begins only after the image data leaves the camera.

When PowerPoint becomes reality

In recent months, several camera manufacturers have finally begun introducing their first 100GigE cameras, platforms that had previously existed for years mostly on product roadmaps and presentation slides. Their growing availability is an important step for the machine vision industry. High-speed Ethernet imaging opens the door to applications that previously required specialized and costly hardware interfaces, and it allows machine vision systems to move closer to modern data-center architectures, with all the flexibility and scalability that brings.

What is easy to overlook in the current wave of announcements is that high-bandwidth Ethernet imaging itself is not new. Emergent Vision Technologies introduced its first 10GigE cameras more than twelve years ago, followed by 25GigE platforms over eight years ago, and 100GigE cameras based on Gpixel sensors more than six years ago. From the beginning, these platforms were designed for applications in which traditional machine vision architectures quickly reach their limits: large-scale multi-camera inspection systems, volumetric capture studios, scientific imaging platforms and high-speed motion analysis setups where the number of cameras is measured not in single digits but in dozens. Working in these environments for more than a decade has produced a straightforward observation. The camera itself was rarely the real bottleneck. The decisive factor was almost always the system architecture behind it.

That observation is not abstract. One recent customer deployment makes it concrete. A manufacturer in the food processing industry needed an AI-based automated optical inspection system running up to 21 cameras simultaneously, with all image data routed through a single network switch to one host system equipped with three GPUs. The customer’s own AI inference code ran directly on that hardware, processing the full camera stream in real time and with no tolerance for dropped frames or processing delays. For more than two years, the customer had attempted to make this architecture work with cameras from one of the largest machine vision manufacturers in the world. The hardware was capable on paper. In practice, the system could not sustain stable operation at the required camera count. CPU overhead from standard GVSP implementations saturated the host long before the GPU pipeline became the limiting factor. Frames were dropped, latency was inconsistent and the AI inference results were unreliable. When Emergent was brought in, the full 21-camera setup was running stably on the same single host using 10GigE cameras combined with an optimized GVSP driver stack and a turnkey setup based on eCapture Pro, Emergent’s real-time multi-camera acquisition and processing software with a graphical user interface for system setup, monitoring and data handling. The customer’s AI inference code was integrated as a custom plugin within this framework, allowing direct processing of the incoming image streams without additional data handling overhead. This avoided the need to build large parts of the acquisition, visualization and runtime infrastructure from scratch and significantly reduced the time required to bring the system into stable operation. The three GPUs were finally doing exactly what they were supposed to do: running the customer’s AI code, not fighting for CPU cycles with the networking stack. The cameras were never the problem. The data pipeline was.

Sony sensors expand the 100GigE platform

Until now, all 100GigE area-scan and line-scan camera platforms from Emergent have been based on Gpixel’s sensor family, which has proven highly capable for high-speed imaging and enabled the first generation of high-bandwidth Ethernet camera systems. The next step in this evolution is now driven by Sony’s latest sensor generation.

Sony’s newest CMOS sensors based on Pregius S fourth-generation technology combine high resolution, high frame rates and improved sensitivity within a compact pixel architecture. With pixel sizes ranging from 5.48 down to 2.74 um, these sensors enable significantly higher resolutions while maintaining the image quality and efficiency that industrial inspection systems demand. The portfolio spans a wide performance range, from high-speed mid-resolution sensors to platforms exceeding 100 megapixels, covering a broad set of application requirements.

The first models of this new generation, including the HZ-12000-SB (IMX926), HZ-25000-SB (IMX925) and HZ-100-SB (IMX927), have already entered production. Additional cameras will follow throughout late 2026 and early 2027, aligned with Sony’s ongoing sensor release roadmap. From a system perspective, these sensors represent considerably more than just higher resolution numbers. At full performance, a single camera can generate several gigabytes of image data per second. In multi-camera environments, aggregate data rates quickly scale into tens or even hundreds of gigabytes per second, which makes the question of how that data is transported and processed more critical than ever.

Sony’s roadmap also includes lower frame rate versions of these large-format sensors, such as the IMX937 and IMX938 class, targeting applications where maximum resolution is required but full sensor speed is not. These variants open up additional design options, since depending on application requirements they can be combined with lower-bandwidth interfaces such as 10GigE or 25GigE, enabling more cost-efficient system architectures while maintaining high image quality. Future camera platforms based on these sensors will complement the current 100GigE portfolio as well as the established 10GigE EROS and 25GigE BOLT families, giving system designers more flexibility to balance resolution, bandwidth and overall system cost across different application scenarios.

The GVSP challenge and how to solve it

In machine vision, GigE Vision has long been the established interface standard at lower bandwidths, covering 1, 2.5 and 5GigE installations. The GigE Vision Streaming Protocol (GVSP) is the part of that standard responsible for the actual image data transport, and its appeal has always been the same: standard networking infrastructure, broad software compatibility, and no proprietary hardware lock-in. Emergent has been pushing GigE Vision into high-speed territory for over a decade, well before the rest of the industry followed, which is precisely why the implementation challenges that come with scaling to 10, 25 and 100GigE are not new ground for the company.

Data PathThe challenge lies in how that protocol is implemented at these higher bandwidths. What many integrators initially blame on CPU utilization is more accurately a memory bandwidth problem. In traditional GVSP implementations, incoming image data passes through multiple buffer copies. Each copy consumes memory bandwidth, and at high data rates with multiple simultaneous camera streams, that cumulative load quickly saturates the system long before the CPU itself becomes the limiting factor. The result is familiar: dropped frames, unstable behavior and a host system that struggles even when CPU utilization numbers look manageable on paper.

Emergent addressed this from the beginning through a zero-copy GVSP architecture. Rather than routing data through successive memory buffers, the implementation places image data directly into its final destination in a single transfer. This eliminates up to three times the memory bandwidth overhead of conventional approaches and reduces CPU interaction to the minimum required by the standard. As illustrated in Figure 2, the difference between a traditional GVSP implementation and a zero-copy architecture is substantial, and it becomes more pronounced with every additional camera stream added to the system.

RDMA and GigE Vision 3.0

The next evolution in this space is the upcoming GigE Vision 3.0 standard, which introduces native support for RDMA, or Remote Direct Memory Access. RDMA achieves zero-copy data transport at the standard level, allowing network interfaces to transfer image data directly into application memory buffers without intermediate copies and without requiring CPU intervention for each packet. In this respect it addresses the same memory bandwidth problem that Emergent’s optimized GVSP architecture has solved for years, but makes the approach more broadly accessible across the industry. At the time of publication, the standard is expected to be formally ratified or already in its final stages of ratification.

For Emergent, this is familiar ground. The zero-copy principle has been at the core of the company’s GVSP implementation from the beginning, developed out of operational necessity in high-bandwidth multi-camera deployments where no margin existed for architectural inefficiency. GigE Vision 3.0 now brings this capability to a wider set of implementations, and Emergent fully supports both approaches. That said, RDMA brings its own trade-offs. Certain implementations introduce constraints around multicast streaming, which continues to play an important role in scalable multi-camera systems. As shown in Figure 3, each transport method offers distinct characteristics, and the right choice depends on the full system context rather than bandwidth numbers alone.

From camera streams to data pipelines

Once image data reaches the host system, the real work begins. Modern high-performance imaging systems increasingly rely on GPU-based processing pipelines for inspection, reconstruction or AI inference, and getting data from the network interface into GPU memory efficiently is itself a significant engineering challenge. Technologies such as GPU Direct under Windows allow image data to be transferred from the network interface toward GPU memory with minimal overhead, avoiding the CPU bottleneck that would otherwise constrain throughput.

In practice, integrating these mechanisms efficiently into an application pipeline can be non-trivial, particularly when dealing with multiple high-bandwidth streams. In multi-camera environments where total data rates reach tens or even hundreds of gigabytes per second, the integration between camera interfaces, system memory, GPU processing pipelines and storage infrastructure needs to be carefully designed end to end. As illustrated in Figure 4, these architectures range from compact single-camera edge systems to large multi-camera installations built around network switches and multiple GPU workstations. The contrast with traditional frame grabber-based approaches is significant: Ethernet-based systems allow flexible scaling using standard network infrastructure, while frame grabber architectures require dedicated hardware per camera group and grow in complexity and cost accordingly.

The economic dimension matters too. In some high-speed deployments, stability is achieved by simply adding more hardware: additional servers, dedicated network interfaces, separate processing nodes to distribute the load. This can work, but it often produces unnecessarily complex and expensive architecture. By optimizing data transport, reducing CPU overhead and designing efficient processing pipelines from the start, it becomes possible to support significantly larger camera counts within fewer host systems. Stable multi-camera installations do not require a one-camera-per-computer approach. Carefully designed systems can scale to dozens of cameras while keeping hardware requirements and operational complexity under control, and that balance between performance, stability and cost is often what determines whether a high-speed imaging project succeeds in production or stays a proof of concept.

To simplify this integration, software frameworks such as eSDK Pro – recognized as a Top Innovation 2026 by InVision earlier this year – provide access to optimized data paths including GPU Direct. Instead of requiring extensive low-level development, these approaches allow system designers to focus on application logic and avoid spending hundreds of engineering hours on transport, memory handling and interface-level optimization when building high-performance imaging pipelines.

The next phase of high-speed vision

With Sony’s newest sensor generation now entering production and GigE Vision 3.0 bringing RDMA support to the broader industry, high-speed Ethernet imaging is entering a new phase. High-performance sensors, high-bandwidth Ethernet infrastructure and modern GPU compute architectures are converging in ways that open up applications previously out of reach for most system integrators. More companies will begin exploring this space, and the technology itself will continue to mature quickly.

What the past decade of real deployments consistently shows, however, is that the camera specification is rarely what determines success. The systems that work reliably in production are the ones where every stage of the imaging pipeline has been designed with the full data flow in mind, from sensor to interface, from interface to host, from host memory to GPU and onward to storage or output. The food processing line with 21 cameras that ran for two years without a working solution is not an exception. It is the rule. In high-speed vision, the camera was never the real bottleneck. The system architecture is. And getting that architecture right requires something that no datasheet can provide: experience earned from real deployments, at scale, under real operating conditions.