Practical Data Rates and Speeds - sCMOS and CCD Scientific Cameras
There are a number of practical considerations when it comes to running cameras to achieve high frame rates.
The first of these are the fundamental experimental conditions that define what exposures are required to provide a suitable signal to noise ratio. In other words, for many cell biology imaging applications exposures within the range of 25 to 250 milliseconds will be required to allow sufficient signal to be collected. This will set the frame rate of the camera to within a window of 40 and 4 frames per second respectively. However faster speeds are sometimes required e.g. imaging of dynamic processes and these will push the limits of camera frame rates and thus the data transfer.
Camera Communication Overheads Limit “Real World” Practical Speeds
Each communication format uses various handshaking and communication protocols which take up some of the maximum quoted data rate for the interface type. This means that practically the actual maximum continuous data transfer rates are lower than the maximum quoted figures, since some is used by the communication protocol data. How much lower this is will depend on the communication interface itself. For example, USB 3 offers a much lower practical bandwidth compared to the more specialised Camera Link or CoaXPress.
Max length (m)
Quoted Bandwidth (Gbps)
Usable Bandwidth (Gbps)
Data % of maximum available
Practical bandwidth (Gbps)
CXP6 (x4 lines)
Table 7: An outline of the Communication interface types and their practical bandwidth. USB allows less of total bandwidth to be available for data transmission. Camera Link allows almost all the available bandwidth.
The frame rate figures listed for Andor cameras are the frame rates that can be streamed continuously without being limited by the connection interface. This is set in the software from a maximum interface transfer rate value. It is possible to exceed this briefly in a scenario of a “burst” of a limited number of frames up to the internal memory buffer of the camera.
Approx. Spooling File Size*
Example Camera Model
2260 x 2160
Neo 5.5, Zyla 5.5
2048 x 2048
Zyla 4.2 PLUS, Sona, Marana
Zyla 4.2 PLUS, Sona, Marana (cropped image)
Table 8: Examples of spooling file sizes for common image sizes. Note that final file size e.g. of a .sif file will differ due to metadata and file format.
The maximum continuous rate is set in the software as otherwise if you attempt to force a higher sustained frame rate than what the interface can sustain, then the frames would be buffered and fill the on-camera buffer as they wait to get transferred. Once this internal buffer was exceeded the acquisition would time out. Andor Solis software provides a useful data monitor function for sCMOS cameras to help visualise data usage.
Disk Write Speed
A further consideration is the disk write speed. This must be sufficient to exceed the data rate from the camera. Reducing the ROI will reduce the data rate transferred, as will reducing bit-depth. Using a smaller ROI (going from 2048x2048 to 1024x1024 will cut data requirement by 4 (table 8). Reducing the image bit depth. Moving from 16-bit to 12-bit will reduce data rate (and file size). Note that reducing the bit-depth further to e.g. 8-bit would limit the dynamic range significantly and thus image quality significantly to the point the data could be unusable for all but a few applications (table 9).
Bit depth (“image resolution”)
Well depth available before saturation (A/D steps available)
Table 9: A comparison of common scientific imaging camera bit-depth and the well depth available.
Ensuring the data storage and PC are capable of the highest possible data transfer. Streaming data to 2 different discs (historically RAID 0 configurations have been used, but modern SSD allow for high write speeds). Data rate considerations for writing to disk are discussed further in the article PC recommendations.
Multi-camera Data Rates
Multi-camera set-ups have become more common. Various adaptors are available to allow multiple channels to be imaged using 2 or more cameras within the same instance of software. This introduces further bottlenecks into the process, thus 2 cameras running simultaneously may not allow full frame rates. Continuously streaming data from multiple cameras to the disc is the main restriction, so 2 cameras running may potentially cut the practical frame rate in half. Software may also impose certain restrictions to throttle the data rate to the PC for the reasons outlined previously on exceeding maximum data transfer rates. This is an important consideration when running a multi-camera sCMOS configuration due to the very high data rates these cameras can produce. Ways around this issue include:
Using different software. Some camera control software is better optimised to run multiple cameras
Optical splitters like the Optosplit series offer a convenient alternative to obtain multiple image channels over a single sensor.
Camera manufacturers select connections to match the data rates that are possible from the sensor for typical application scenarios.
Increasing readout speed will result in higher noise levels from the camera. Cameras will therefore often feature low noise modes that mean lower frame rates and higher speed, but higher noise modes.
sCMOS cameras offer much flexibility in this regard – with 12-bit modes providing higher speeds and 16-bit providing wider dynamic range.
Some sensors can have a higher data “burst” rate, meaning that for a short sequence of frames it will exceed what can be maintained continuously.
Many CCD cameras have a higher speed “focusing mode”, this will provide a higher frame rate but is not intended for normal high-quality imaging.
Refer to the camera specification sheet to check the frame rates possible in the required mode of operation.
Remember that the application will place limitations on what frame rates are achievable since sufficient signal needs to be collected for an appropriate signal to noise ratio.
Read more from the Camera Connectivity Article Series