Garbled image with Hamamatsu Orca HR?

Question

I've been using an Orca C4742-95 as part of a machine vision experiment.  I have two rigs set up, each of which have the same camera model hooked up.  Both computers are also using the same firewire card, a "Texas Instruments TSB82AA2 1394b OHCI-Lynx IEEE 1394 Host Controller" as Device Manager tells me.  Both devices are using drivers provided by Hamamatsu with the August 2011 revision of the DCAM-API.
When either camera is hooked up to the newer of the computers we are using, the image is garbled if it is set to 16-bit mode.  This is true with HCImage, any of the software that comes with DCAM-API, as well as captured through OpenCV.  Here's an example:
http://imgur.com/PsLKy
The thing is, the problem isn't with the camera - both cameras, camera controllers, and cables work fine on the other computer.  Both computers are running Windows XP, however one was recently ordered and built (we downgraded from Windows 7 to XP in case that was the issue, with no luck).
In HCImage, if I set it to 16 bit, it will only work at 2/3-ish resolution or below - however it captures fine at full resolution when set to 8 bit.  It seems to me that it might be some sort of bandwidth issue at some point, but this computer is brand new and has much higher specs than the other one, which is 6 or 7 years old at this point (and can handle 16 bit at full resolution with no trouble.)
I've been trying for days to reach Hamamatsu support, so I was wondering if anyone here had any suggestions or past experience with this sort of issue.  If anyone knows a way to set the bit depth to 8 bit by default (or if there's a call I can make via the API to do this; I was unable to find any documentation), that would also help, as I'm using OpenCV to capture the stream and we need a video stream to move forward.  Any help would be greatly appreciated!
Solved!
Go to Solution.

Answer 1

This is a common issue with FireWire cameras on newer systems. Basically the issue is that the OHCI FireWire chipsets (provided by only a few vendors) typically only have a few KB of buffer space on-board. This is not normally a problem for most applications that use bulk transfer-style mechanism where there is flow control of the data and buffering. However, IIDC FireWire cameras make use of an isochronous transfer mechanism where they transmit a packet every bus cycle regardless of whether the host can accept it or not.
This is further hirt because over the past few years, transfer latences over PC busses (like PCI express vs PCI) have gotten longer. This increase in latency is due to various design decisions that favor overall throughput over latency. Additionally, the push to lower power consumption of these high-speed busses means they use aggressive power saving technologies to put links to sleep when they are idle and the CPU itself does agressive power savings as well. These techniques all increase latencies for certain types of operations. This is usually not a problem for throughput of transfers that use flow control but can cause issues for isochronous transfers like FireWire uses.
One thing you can do is try to disable some of the power saving features on your system. For instance, Windows 7 lets you change the overall power management strategy of your system. You can switch it to the maximum performance profile, and this tends to disable things like CPU sleep states and ASPM on PCIe links. You could also check and see if there are some power savings features you can disable in the BIOS.
Additionally, on some systems with integrated video, the update of the display can use a lot of memory bandwidth and compete with the firewire card for bandwidth to system memory. Disabling the Windows Aero interface has been known to help in some situations.
Point Grey has a really good support article that has some great info that should apply to any vendor's cameras as well:
http://www.ptgrey.com/support/downloads/documents/TAN2010003_Image_tearing_causes_and%20_solutions.p...
Eric