yuv histogram compared with rgb

[Jonas Van Otterdijk]

Hi,
Grabbing images with YUV 4:2:2 gives a lot more “noise” on the image histogram than doing the same using the RGB way.
How come?

See images for details

How come?

YUV:

RGB:

 

Thanks,

[Andrey_Dmitriev]

I guess, its more or less expected result, because the two chroma components are sampled at half the sample rate of luma (the horizontal chroma resolution is resampled to half size). So, you will lost some info (but you shouldn't see much visual differences).

Can you post also the images please? 

Andrey.

[Jonas Van Otterdijk]

Thanks Andrey for your quick response,

The reason why I asked the question is:

1. Sony camera (supports only YUV) does not work correctly on my new setup (latest imaq, Lv2009,…) because of the “noise” problem.
2. Allied camera works fine using RGB setting on new setup, not with YUV setting.
3. Sony camera with YUV setting at customer site works fine on old setup (old imaq (unknown version), labview 7.0)

So, I was thinking about a driver problem; Legacy drivers are not supported by default using the current versions of imaq labview 2009… but I was not sure completely. I was thinking about YUV compression or something...
Kind regards,

Jonas


Here the image i've used for the histograms above, but it really does not seem to matter what image i use.

[BruceAmmons]

The interesting thing is that the YUV favors odd values over even values (or the reverse - couldn't quite tell from the histogram), which gives the histogram a jagged appearance.  Perhaps the algorithm that converts YUV to RGB has changed.  If it worked fine in an older version, I would report it as a possible bug.

Bruce

[BlueCheese]

Jonas,

One thing to keep in mind is that the camera itself is doing some color conversions and thus it is quite likely that you'll see differences in the quality of that implementation (possibly even between two firmware versions of the same camera). The camera is likely using a Bayer filter and doing on-board de-Bayering and converting to RGB or YUV. It is quite likely that the conversion to YUV and back to RGB is going to yield different results than going straight to RGB on the camera itself.

Now, if you are noticing a difference between different versions of our driver, this would only be likely if you are going way back to really old versions. I believe if you were to go back really old versions of the Legacy 1394 driver, they might not have made use of the IPP and MMX optimizations of the newer versions. It is possible that the newer implementations yield slightly different results (but I have no idea if it would contribute as much change as you are seeing).

If you'd like to experiment, you could try playing with the registry key in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\niimaqdxk\Parameters called DecoderImplementation. I believe the default is 3 for the most optimized implementation and you try values between 0 and that.

Eric

[ScottSmith]

[Great thread!]

Building on Eric's remark, indeed most machine vision color cameras use a Bayer filter, interpolating color information through de-Bayering.  (The alternative, a three-plane camera, would be prohibitively expensive for all but the most demanding applications.)

Some (Bayer filter) color cameras only send RAW (non de-Bayered) information to the PC.  This is very efficient in bandwidth usage, but keeps camera electronics (and cost) to a minimum,and puts the de-Bayering burden on the software side.

Many (Bayer filter) color cameras also offer one or more YUV or RGB de-Bayering options in camera firmware, AS WELL AS the option to send in RAW format to the PC.  Different YUV and RGB algorithms vary in the nuances of their rendering, as well as in performance and bandwidth utilization.   Classic example of time-space tradeoff, as well as guaging quality-level needed for a given machine vision application.

Scott