MX3's YUV to RGB conversion in motion detection code

Microfunguy

4037

« on: 18 / November / 2009, 17:41:21 »

Advertisements

MX3 has used the following conversions :-

R = Y + 1.402*V + 0.5

G = Y - 0.3444*U - 0.7141V + 0.5

B = Y + 1.7719*U + 0.5

all clipped to 0 to 255.

These do not seem to correspond to published conversions.

The nearest I have seen are :-

R = Y + (1.402*(V-128))

G = Y - 0.34414*(U-128) - 0.71414*(V-128)

B = Y + (1.772 * (U-128))

They do not look equivalent to me.

Logged

ewavr

1057
A710IS

Re: MX3's YUV to RGB conversion in motion detection code

« Reply #1 on: 18 / November / 2009, 18:06:50 »

Quote from: Microfunguy on 18 / November / 2009, 17:41:21

MX3 has used the following conversions :-

Not only mx3, but also GrAnd in histogram calculation.

Quote

They do not look equivalent to me.

Camera and CHDK uses signed values for u and v (-128 and 127 for maximal saturation, 0 (or -0.5?) for zero saturation).
In your equations u and v are unsigned values (0 and 255 for maximal saturation, 128 (or 127.5?) for zero saturation).
So, both set of equations are equal.
But why 0.5 is added in CHDK calculations? I don't know.

« Last Edit: 18 / November / 2009, 18:08:24 by ewavr »

Logged

cppasm

Re: MX3's YUV to RGB conversion in motion detection code

« Reply #2 on: 19 / November / 2009, 05:59:41 »

Quote from: ewavr on 18 / November / 2009, 18:06:50

But why 0.5 is added in CHDK calculations? I don't know.

This is round up (toward +infinity).
But looks little strange, because it will round negative and positive numbers in different way.
1.5 will be rounded to 2, but -1.5 will be rounded to -1
Adding 0.5 is acceptable for formula with unsigned values (0...255).
But in motion detector and histogram this does not give any noticeable error, so can be left untouched.

Logged

Microfunguy

4037

Re: MX3's YUV to RGB conversion in motion detection code

« Reply #3 on: 19 / November / 2009, 06:09:34 »

'cu' and 'cv' are declared as int and are therefore signed.

I return their values in a uBasic variable, which is a signed int.

I use uBasic 'print' to display the value, internally that uses format specifier %d (signed decimal integer).

The result is 0 to 255, not -127 to +128.

Those are the values used in the RGB calculations.

Should 'cu' and 'cv' be declared as 'char' (assuming that is signed) ?

« Last Edit: 19 / November / 2009, 06:44:59 by Microfunguy »

Logged

ewavr

1057
A710IS

Re: MX3's YUV to RGB conversion in motion detection code

« Reply #4 on: 19 / November / 2009, 08:43:30 »

Quote from: Microfunguy on 19 / November / 2009, 06:09:34

I return their values in a uBasic variable, which is a signed int.

How? This may be an error in the conversion.

Logged

cppasm

Re: MX3's YUV to RGB conversion in motion detection code

« Reply #5 on: 19 / November / 2009, 09:45:08 »

Quote from: Microfunguy on 19 / November / 2009, 06:09:34

Should 'cu' and 'cv' be declared as 'char' (assuming that is signed) ?

char is unsigned by default on ARM platform.

Logged

Microfunguy

4037

Re: MX3's YUV to RGB conversion in motion detection code

« Reply #6 on: 19 / November / 2009, 09:56:50 »

Quote from: cppasm on 19 / November / 2009, 09:45:08

char is unsigned by default on ARM platform.

Yes, I just discovered that when testing my code.

I will post details shortly, I just want to check the RGB calculation results.

At least my spotmeter function is now returning negative values for U and V.

EDIT:

So, I have :-

int spotmeter[3];

and in a loop :

spotmeter[1]+=(signed char)img[(y*vp_w+x)*3];

and after 96 samples from centre of screen :

ubasic_set_variable(1,spotmeter[1]/96);

returns the result in variable 'b'.

The calculated RGB values (calculated 'externally' with uBasic) are then correct.

« Last Edit: 19 / November / 2009, 10:20:44 by Microfunguy »

Logged