Garbled image with Hamamatsu Orca HR?

[DivideByZer0]

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!

[DivideByZer0]

Also, I noticed that when I preview the stream in AMCAP and resize the window, the image is fine while the window is being dragged but as soon as I stop dragging it becomes garbled again.

[Tim_O1]

Hi DivideByZer0,

Usually when you get garbled images in your acquisition it has to do with the camera’s spec not matching up to your settings. Make sure your camera has the specs to output 16 bits. I did a quick search on it and it looks like it’s designed for a 10 or 12 bit digital output.

ORCA-100 (Model C4742-95) Cooled Digital Camera

http://www.well.ox.ac.uk/_asset/file/hamamatsu-c4742-95-orca.pdf

Tim O

[DivideByZer0]

Thanks for the response, that makes sense but the same software is installed for this camera on the other computer, which works fine with 16 bit acquisition (note that either camera works fine on that PC, and both computers have the same software, drivers, etc installed.)  I'm not in the lab right now but I'll double check to make sure that the two camera's model numbers and hardware IDs are the same; also I'll make sure that the software isn't somehow acquiring in 12 bit on the other PC.  (although, even in the PC it isn't working on, it still says 12 bit in a different section of the settings - perhaps there's an issue with how it's trying to convert it up to a 16 bit image?)

[DivideByZer0]

Okay, it looks like the cameras are both the exact same model.

If this is a hardware issue it seems like it might be a faulty firewire card (the computers have the same card but perhaps they're not acquiring at the same bandwidth?  I did check the registry values for the card speeds and I also got the hotfixes that are supposed to address that issue though).

Also, if anyone knows of a way to acquire at either a lower bit depth or a lower resolution (or to set these as default with the camera drivers) that would also help, since we don't need 16 bit (or 12 bit mapped/converted to 16 bit) acquisition at this point in the project. 

[Tim_O1]

Hi DivideByZer0,

I would look into the user manual for your acquisition software to find how to acquire at a lower bit depth or a lower resolution. If you use our software it is very easy to setup your vision acquisition to exactly the way you want it.

NI Vision Acquisition Software

http://sine.ni.com/nips/cds/view/p/lang/en/nid/207702

Tim O

[DivideByZer0]

Thanks!  I finally got in touch with Hamamatsu, and since my lab owns several of their cameras we might be able to get access to their SDK (although we do plan on using your software in the future as the project progresses.)  We also had some luck with the CMU 1394 driver, although we didn't get too far with implementing it.  The tech I spoke with thought that it was a hardware issue with the motherboard affecting the bandwidth for the firewire card.

[BlueCheese · Accepted solution]

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

[DivideByZer0]

I downloaded the Point Grey Research PGRIdleStateFix utility and turned off idle states, and that solved the problem!  We're now getting 16 bit full resolution image acquisition through OpenCV with no issues at all.  Thank you very much for your help, we have been stuck on this issue for three weeks and now can move forward with our application development and research.  Also thanks Tim for your suggestions, I really appreciate the assistance!  I'll be sure to let Hamamatsu know about this issue so they can hopefully address it in future drivers and applications.

-Brendan