MX3's YUV to RGB conversion in motion detection code - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1]   Go Down

MX3's YUV to RGB conversion in motion detection code

  • 6 Replies
  • 4907 Views
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
MX3's YUV to RGB conversion in motion detection code
« 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
*

Offline 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
*

Offline cppasm

  • **
  • 92
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
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
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
*

Offline 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
*

Offline cppasm

  • **
  • 92
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
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
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
Pages: [1]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal