edge overlay - page 2 - General Discussion and Assistance - CHDK Forum

edge overlay

  • 41 Replies
  • 27303 Views
Re: edge overlay
« Reply #10 on: 28 / April / 2008, 06:00:39 »
Advertisements
I guess we also have an enhanced pano function,thanks!

For panos, it will be interesting to see how different the height of the images is in the overlap regions due to distortion.

For stereo with a single camera, if you point the camera down at a sheet of paper on a desk-top and capture the outline, if you then move sideways very slightly for the second shot you can see how very different the perspectives are, especially at wide-angle.

Your brain would have great difficulty fusing such an image.

You only need two  distinct points in order to align two images.



David

Re: edge overlay
« Reply #11 on: 28 / April / 2008, 17:18:44 »
[I do not really understand how it works.

Hi,

The display of the c code cuts off the right side so that may make things a little difficult to understand.
Here is an explanation in words:

The edge calculation I do a simple absolute value of the horizontal difference:  abs(pix - pix[i-1]).  (Note: maybe pix[i+1] - pix[i-1] would be better, I'll have to try this)  The layout of the buffers is a little strange so that makes for some complications.  To explain:
The viewport has 6 bytes per 2 pixels in the format U,Y1,V,Y2,Y3,Y4.  This has 4 luminosity values (Y1,Y2,Y3,Y4) and one set of color values (U,V) for the two pixels.  I think the 4 luminosity values are used for antialiasing in the calculation of the RGB dots for the lcd.
The screen overlay has one byte per pixel.  That byte is a code that indexes into a limited pallet of transparent and opaque colors.
I make use of only two codes, transparent and opaque white.  (Maybe using more would improve the edge display... another thing to try out).
Edge Calculation:
Done in place on the stored viewport data.  Done once on a shutter half press.
I use the fact that the viewport has more bytes per pixel than the screen overlay to do the edge calculation in-place, rather than having to allocate a separate buffer for the edge image.  I calculate the edge value for the first pixel as abs(Y1 - previous Y1) and store it in Y2.  For the second pixel I calculate abs (Y3-previousY3) and store it in Y4.
Edge Display:
This is constantly repainted while in shoot mode.  I look at 2 pixels at a time.  That is 6 bytes of viewport and 2 bytes of the screen overlay.  I compare the edge values in Y2 to a threshold that determines whether I write a transparent or opaque pixel to the screen overlay.  Same with Y4.


Hope this helps.
« Last Edit: 28 / April / 2008, 17:22:45 by hiker_jon »

Re: edge overlay
« Reply #12 on: 28 / April / 2008, 18:43:54 »
Hope this helps.

Thanks Jon.

I will have to read this a few times.

I have get absolutely nowhere trying to get this to work on my A620 AFTER I have pressed the shutter.

I tried splitting into two or three operations but could not get it to work.

For some reason, even limiting the number of rows to 0 to 150 no longer works, it did a few days ago.

The overlay after shooting is some of the edges combined with random patterns.

This is going to be extremely useful if it works on DIGIC II cameras.

I will continue tomorrow.


David

Re: edge overlay
« Reply #13 on: 29 / April / 2008, 12:54:34 »

I have get absolutely nowhere trying to get this to work on my A620 AFTER I have pressed the shutter.


Here is a new version that is split into stages, minimizes the amount of calculation when shooting, and has a vertical as well as horizontal edge calculation.  Now it also includes horizontal and vertical shifts using the up,down,left right keys.  Do this in alt mode to avoid changing the camera options.
Code: (cpp) [Select]

// Code to test the idea of an edge overlay
// Put this after  the line #include "motion_detector.h" in main.c
#include "gui_draw.h"
// until the edge thresh is put into conf structure I have hardcoded the threshold  see "thresh" below
#define MARGIN 30
#define CALCYMARGIN 3
#define DELAY 10
#define MEMDELAY 10
#define EDGECOLOR 0x26
#define NSTAGES 8
#define XINC 6
#define YINC 2
void edge_overlay(){
static char *imgbuf = 0;
static int inmem=0;
static int viewport_height;
static int viewport_width;// screenwidth * 3
static int viewport_size;
static int imgmem = 0;
static int ymin = 0;
static  int thresh = 30;
static int delay = 0;
static int memdelay = 0;
static int xoffset = 0;
static int yoffset = 0;
  static unsigned char *img;
int i, hi, c;
int x, y, h, v, ymax, y1, x1;
char * ptrh1;
char * ptrh2;
char * ptrv1;
char * ptrv2;
char * optr;

//if(!conf.edge_thresh) return;

    img=((mode_get()&MODE_MASK) == MODE_PLAY)?vid_get_viewport_fb_d():((kbd_is_key_pressed(KEY_SHOOT_HALF))?
vid_get_viewport_fb():vid_get_viewport_live_fb());
    if (img==NULL){
   img = vid_get_viewport_fb();
}
    viewport_height = vid_get_viewport_height();
viewport_width = screen_width * 3;
    viewport_size = viewport_height * screen_width;
if(imgbuf == 0) imgbuf = malloc(viewport_size * 3);

if((mode_get()&MODE_MASK) != MODE_PLAY) {
if (kbd_is_key_pressed(KEY_RIGHT)) {
xoffset -=XINC;
delay = DELAY;
}
if (kbd_is_key_pressed(KEY_LEFT)) {
xoffset +=XINC;
delay = DELAY;
}
if (kbd_is_key_pressed(KEY_DOWN)) {
yoffset -=YINC;
delay = DELAY;
}
if (kbd_is_key_pressed(KEY_UP)) {
yoffset +=YINC;
delay = DELAY;
}

if (kbd_is_key_pressed(KEY_SHOOT_HALF)) {
if(!(memdelay++)) {
memcpy(imgbuf,img,viewport_size * 3);
ymin = CALCYMARGIN;
inmem = 1;
xoffset = 0;
yoffset = 0;
}
return;
}
else {
if(memdelay) memdelay++;
if(memdelay > MEMDELAY) memdelay = 0;

if (inmem) {
ymax = ymin + (screen_height - 2 * CALCYMARGIN) / NSTAGES;
if(ymax > screen_height - CALCYMARGIN) ymax = screen_height - CALCYMARGIN;
for (y=ymin; y<ymax; y++) {
ptrh1 = imgbuf + y * viewport_width + 7;
ptrh2 = imgbuf + y * viewport_width - 5;
ptrv1 = imgbuf + (y + 1) * viewport_width + 1;
ptrv2 = imgbuf + (y - 1) * viewport_width + 1;
optr = imgbuf + y * viewport_width + 3;
for (x=12; x<(screen_width- 4) * 3; x+=6) {
h = ptrh1[x] - ptrh2[x];
if(h  < 0) h = -h;
v = ptrv1[x] - ptrv2[x];
if(v  < 0) v = -v;
optr[x] = h + v;
h = ptrh1[x + 3] - ptrh2[x + 3];
if(h  < 0) h = -h;
v = ptrv1[x + 3] - ptrv2[x + 3];
if(v  < 0) v = -v;
optr[x + 2] = h + v;
}
}
if(ymin < screen_height-CALCYMARGIN) delay = DELAY;
ymin += (screen_height - 2 * CALCYMARGIN) / NSTAGES;
}
if((ymin >= screen_height-CALCYMARGIN)&& ((gui_get_mode() == GUI_MODE_NONE) || (gui_get_mode() == GUI_MODE_ALT)))
{
if(++delay > DELAY) {
// thresh = (conf.edge_thresh - 1) * 10;
for (y=MARGIN; y<screen_height-MARGIN; y++) {
y1 = y + yoffset;
if((y1 < CALCYMARGIN) || (y1 >= screen_height - CALCYMARGIN)) {
for (x=MARGIN; x < screen_width - MARGIN; x+=2) {
        draw_pixel(x, y, 0);
        draw_pixel(x+1, y, 0);
}
}
else {
for (x=MARGIN; x < screen_width - MARGIN; x+=2) {
x1 = x + xoffset;
if((x1 < 12) || (x1 >= screen_width-13)) {
            draw_pixel(x, y, 0);
            draw_pixel(x+1, y, 0);
}
else {
            c = 0;
if(imgbuf[y1 * viewport_width + x1 * 3 + 3]  > thresh)
c = EDGECOLOR;
// else if(imgbuf[y * viewport_width + x * 3 + 3]  > thresh/2)
// c = 0x01;
            draw_pixel(x, y, c);
            c = 0;
if(imgbuf[y1 * viewport_width + x1 * 3 + 5]  > thresh)
c = EDGECOLOR;
// else if(imgbuf[y * viewport_width + x * 3 + 5]  > thresh/2)
// c = 0x01;
            draw_pixel(x+1, y, c);
}
}
}
}
delay=0;
}
}
}
}

}

//End of edge detector code.  next put  edge_overlay(); after the line histogram_process();
« Last Edit: 30 / April / 2008, 13:53:16 by hiker_jon »

Re: edge overlay
« Reply #14 on: 29 / April / 2008, 13:10:31 »
Here is a new version that is split into stages, minimizes the amount of calculation when shooting, and has a vertical as well as horizontal edge calculation.


thanks Jon, I will check that next.

I have been testing this all day,

Sometimes just rows 30 to 70 does not playbacl properly, other times 30 to full height does playback properly.

May be connected to autofocus.

After focusing, pressing full-shutter quickly seems to work more often.


David

Re: edge overlay
« Reply #15 on: 29 / April / 2008, 13:50:01 »
Does this have the potential to create "sperical" panoramas?
Whoa-Hey! Careful where you point that thing. You're gonna shoot someone!

http://chdk.wikia.com/wiki/DoF_Stacking

Re: edge overlay
« Reply #16 on: 29 / April / 2008, 16:16:27 »
Does this have the potential to create "sperical" panoramas?
It causes an edge image of the last shot picture to be overlaid on the screen.  For panoramas the overlay could be shifted to the left, right, top, or bottom.  Then you would match the next shot to the shifted overlay.

Re: edge overlay
« Reply #17 on: 29 / April / 2008, 16:38:11 »
The new multipart version does not solve the problem so it is something other than a timing problem.
After press-and-release to focus, if you quickly do a full-press it will work quite often.

If you use the two second timer, it works every time !

So, that is fine.

I will decide how to integrate it into SDM and then do some tests.

I will post some images.


David

Re: edge overlay
« Reply #18 on: 29 / April / 2008, 19:44:05 »
The new multipart version does not solve the problem so it is something other than a timing problem.

One last try:  I edited the multipart version to put a delay after saving the viewport to memory.  Prior to this change the code saved the viewport to memory continually while halfpress was on.  Now it just does it once, then requires a few cycles with halfpress off before enabling memory saving again.

The code is getting a little complicated and needs to be rewritten.  I am trying to have it so the saving to memory is done when first halfpress is detected.  Then there is a wait for some cycles with no half press before any more processing is done.  Hopefully that will get the viewport into memory at half press just before the shot then further processing will wait until after the shutter is released.
« Last Edit: 29 / April / 2008, 20:15:19 by hiker_jon »

Re: edge overlay
« Reply #19 on: 30 / April / 2008, 05:45:58 »
Before I try that new verion with a delay, I have a general question.
I am a beginner at programming and am studying CHDK in order to learn.
I carefully line-up and indent all brackets so that I can instantly see if they balance.

I have noticed most experienced programmers, like yourself, do not bother to do this.
For me, it makes the code difficult to read .. the first thing that I do is re-arrange it.

Why do programmers adopt that style ?


David

 

Related Topics


SimplePortal © 2008-2014, SimplePortal