digic 6 motion detection (was Re: SX60HS Porting) - page 2 - General Discussion and Assistance - CHDK Forum supplierdeeply

digic 6 motion detection (was Re: SX60HS Porting)

  • 87 Replies
  • 28315 Views
*

Offline reyalp

  • ******
  • 12159
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #10 on: 13 / July / 2016, 13:44:57 »
Advertisements
my bad....improvised debug info log trashed memory. 
I have never done anything like this. No sir :haha
Quote
can now trigger 20 or more sequential shots with motion detect...
So i'll clean up a bit and post it when I have time...next few days are busy.
Thanks for comments making me look at stuff closer!!
Thanks for working on this :)

You can get an idea of the response time using md tune http://chdk.wikia.com/wiki/Testing#MD_tune.bas

You may have to adjust the AF Led control code to make it work.
Don't forget what the H stands for.

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #11 on: 17 / July / 2016, 18:41:01 »
Just looking at rgb triggering/processing and I have a question:

Using the liveview hack for chdkptp, I send YUV8B, not YUV8C as was written in the original code....
Code: [Select]
Sending to chdkptp core/live_view.c
// reverse B and C according to Ant
    if (camera_info.state.mode_play)
        vp->fb_type = LV_FB_YUV8C;
    else
        vp->fb_type = LV_FB_YUV8B;

on the receiving end YUV8B is decoded into rgb
by this:
Code: [Select]
void yuvb_live_to_cd_rgb(const char *p_yuv,
                                                unsigned buf_width,
                                                unsigned width,unsigned height,
                                                int skip,
                                                uint8_t *r,uint8_t *g,uint8_t *b) {
        unsigned x,row;
        unsigned row_inc = (buf_width*16)/8;
        const char *p;
        // start at end to flip for CD
        const char *p_row = p_yuv + (height - 1) * row_inc;
        for(row=0;row<height;row++,p_row -= row_inc) {
                for(x=0,p=p_row;x<width;x+=2,p+=4) {
            char p2 = p[2] - 0x80;
            char p0 = p[0] - 0x80;
                        *r++ = yuv_to_r(p[1],p2);
                        *g++ = yuv_to_g(p[1],p0,p2);
                        *b++ = yuv_to_b(p[1],p0);
This seems to be necessary for the SX60HS...chdkptp live view..
Question: is this consistent across all digic 6 cameras? i.e I should subtract 0x80 from the U & V values before using to get rgb?

*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #12 on: 18 / July / 2016, 01:45:38 »
Question: is this consistent across all digic 6 cameras? i.e I should subtract 0x80 from the U & V values before using to get rgb?

Most likely, yes. 80D uses the same trick for the bootloader (didn't check LiveView yet, but after seeing your message, I expect the same behavior).

*

Offline reyalp

  • ******
  • 12159
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #13 on: 19 / July / 2016, 16:36:15 »
Quote from: 62ndidiot link=topic=12918.msg129364#msg129364
Question: is this consistent across all digic 6 cameras? i.e I should subtract 0x80 from the U & V values before using to get rgb?
I think this is what srsa called uyvy_d6 in binview. The record and playback viewports I've configured for g7x use this. AFAIK the sx280 port is currently set to use a uyvy_old buffer, but the uyvy_d6 ones exist and have been identified.

For now, I think it's safe to write your code around the assumption it uses this format.

Future discoveries might affect which buffer we want to use, e.g. if one has lower latency or updates more frequently. My guess is that the _d6 one is the original, since it's higher resolution than other on g7x, but this could be wrong.

Don't forget what the H stands for.


Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #14 on: 20 / July / 2016, 15:06:47 »
Quote
I think this is what srsa called uyvy_d6 in binview. The record and playback viewports I've configured for g7x use this. AFAIK the sx280 port is currently set to use a uyvy_old buffer, but the uyvy_d6 ones exist and have been identified.
Yes binview works for me on a dumped image....do you mean however, that the sx280 port will be an exception, perhaps I should include a define/switch to turn on and off subtraction of 0x80? and if so suggestions?

Also, googling yuv422, I see frequent mention of addition/subtraction of 16  from the Y values together with the 0x80 manipulation of U and V.
YUV to RGB Conversion
http://www.fourcc.org/fccyvrgb.php

   
Code: [Select]
B = 1.164(Y - 16)                   + 2.018(U - 128)

    G = 1.164(Y - 16) - 0.813(V - 128) - 0.391(U - 128)

    R = 1.164(Y - 16) + 1.596(V - 128)

In both these cases, you have to clamp the output values to keep them in the [0-255] range. Rumour has it that the valid range is actually a subset of [0-255] (I've seen an RGB range of [16-235] mentioned) but clamping the values into [0-255] seems to produce acceptable results to me.

 I don't think this matters for motion detection. My strategy is to leave the old code functioning as is, even if I think it may be slightly incorrect. I'll post it and others can comment.


« Last Edit: 20 / July / 2016, 16:04:51 by 62ndidiot »

*

Offline reyalp

  • ******
  • 12159
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #15 on: 20 / July / 2016, 23:31:31 »
Quote from: 62ndidiot link=topic=12918.msg129392#msg129392
Yes binview works for me on a dumped image....do you mean however, that the sx280 port will be an exception, perhaps I should include a define/switch to turn on and off subtraction of 0x80?
I wouldn't. Since all the cameras so far have both kinds of buffers, we will probably settle on using one everywhere.
« Last Edit: 20 / July / 2016, 23:45:45 by reyalp »
Don't forget what the H stands for.

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #16 on: 21 / July / 2016, 14:48:19 »
As far as using mdtune to measure performance with the AF Led, am I missing something, or do I have to enable it by hard coding and recompiling?

Hmmm, examined MD_tune.bas, I see it calls md_af_led_control, which is in modules/luascript.c and on the camera as part of lua.flt...
Apparently it doesn't do what's necessary for me although hardcoding its effect works...what's wrong?
« Last Edit: 21 / July / 2016, 15:51:11 by 62ndidiot »

*

Offline reyalp

  • ******
  • 12159
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #17 on: 21 / July / 2016, 16:13:18 »
As far as using mdtune to measure performance with the AF Led, am I missing something, or do I have to enable it by hard coding and recompiling?
You need to define the led number (used with camera_set_led / script set_led) in platform_camera.h CAM_AF_LED

I think this should work without additional modifications. When wrote my earlier post, I incorrectly thought it was using MMIO control rather than set_led.
Quote
Hmmm, examined MD_tune.bas, I see it calls md_af_led_control, which is in modules/luascript.c and on the camera as part of lua.flt...
The .bas file uses corresponding ubasic code, which is in lib/ubasic.c, but I don't think you should need to touch that.
Don't forget what the H stands for.


Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #18 on: 21 / July / 2016, 17:07:45 »
Thanks.  It works fine now.
« Last Edit: 22 / July / 2016, 15:25:56 by 62ndidiot »

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #19 on: 24 / July / 2016, 16:49:28 »
I've attached my first attempt at adapting motion_detector.c for digic 6 below.

Notes:

1. I've tried to leave the pre-digic 6 code alone, so it will continue to function as it always has.

2. Selecting pixels-step = 1 in Y, R, G, or B modes (Digic 6) will result in every pixel being processed.  I think only 1/4 of the pixels were processed pre digic 6. In U or V mode only half the number of pixels will be processed because U,V are only present once for each pair of pixels as we scan horizontally.

3. I've used THUMB_FW to recognize digic 6. Probably, it would be nicer to have a more flexible way of signalling what processing we need going forward. Also, I've kept everything "in-line" in the hope that it will result in faster execution.

4. To use this code, ensure that lib.c for your platform contains a correct

vid_get_viewport_byte_width() (probably just 1280 bytes)

because the one in generic/wrappers.c has not been ported to digic 6 (yet), or modify this yourself.


5. It seems to me that it would be useful to be able to specify a threshold as a percentage (increase or decrease) rather than an absolute value, because it would be less sensitive to specific parameters like pixels_step, grid geometry, and the specifics of the image like brightness/color characteristics.

Hopefully, with the help of others, I'll be able to make any corrections quickly.