Cropped zebra or zebra specific OSD - page 8 - Feature Requests - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 3 4 5 6 7 [8] 9 10   Go Down

Cropped zebra or zebra specific OSD

  • 90 Replies
  • 43016 Views
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Cropped zebra or zebra specific OSD
« Reply #70 on: 25 / December / 2008, 13:20:18 »
Advertisements
Quote from: ewavr on 25 / December / 2008, 12:34:19
IMHO, we cannot expect in playback mode that value of PROPCASE_SHOOTING is equal to 1  :D.

p.s. Reading 4 bytes to short variable is also not too good idea.

Wow. Well, diff below to change that to int and make zebra work in play mode again. Seems to work on my a570is...



Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Cropped zebra or zebra specific OSD
« Reply #71 on: 25 / December / 2008, 15:43:57 »
Oops, on second thought that diff doesn't work  :(. Or, it did on first try right after boot, but now that I've played around with it more it looks like that buffer play of osd restore zebra makes play mode zebra invisible for most of the time. Or something like that; I'm no expert on those display buffers...
Logged
*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: Cropped zebra or zebra specific OSD
« Reply #72 on: 25 / December / 2008, 16:29:05 »
Quote from: fudgey on 25 / December / 2008, 15:43:57
Oops, on second thought that diff doesn't work  :(. Or, it did on first try right after boot, but now that I've played around with it more it looks like that buffer play of osd restore zebra makes play mode zebra invisible for most of the time. Or something like that; I'm no expert on those display buffers...
I don't understand how works new zebra.
However, if we change:

            n=draw_guard_pixel();
            if(!ready || n==0) return 0;

to 
            n=draw_guard_pixel();
            if(!ready) return 0;

zebra works always.
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Cropped zebra or zebra specific OSD
« Reply #73 on: 25 / December / 2008, 19:18:53 »
This is how I think it works (remember I didn't write any of the zebra code except that border-only RAM savings thing; I may be wrong):


Zebra (old and new) is drawn to buffer buf[] in RAM, size equal to screen resolution. When drawing is complete, buf[] is copied to Canon's screen buffers, found next to each other at address given by vid_get_bitmap_fb(). These are display buffers for OSD overlay or something like that, not containing camera images. Only one is active, I'm not sure how they get switched (in half shoot maybe never, but during face detection maybe very rapidly).

Live view image is accessed in address given by vid_get_viewport_fb().
Play mode image is accessed in address given by vid_get_viewport_fb_d()

These three vid_get_...() functions are from platform sub lib.c and just return addresses found by whoever has ported CHDK to a camera.

In rec mode, more than one viewport buffers (3?) are used. Some cameras have the function vid_get_viewport_live_fb(), which returns the active one. It was found when searching for ways to speed up motion detection. But not all cameras have this yet as it requires some work to be done by a person who has a camera (or someone to find a way to find this from disassembly, maybe nobody has ever looked). Zebra (old and new) does use this "live" one for cameras that it's been found. This is the source image for zebra calculation, but neither old nor new zebra draw there.

In play mode viewport height (but not OSD bitmap height?! A great candidate for vertical offset problems between play mode image and zebra?) is smaller (at least in some cameras) than in REC mode.

New zebra recovers Canon OSD. It achieves it by making a copy (full or partial depending on #define ZEBRA_CANONOSD_BORDER_RESTORE) of the buffer Canon draws their OSD to before zebra draws anything on top of it. When the time comes, Canon OSD is copied from this cur_buf storage to buf[].

There's also new zebra function draw_guard_pixel(). It's used to figure out which OSD bitmap buffer should be used for Canon OSD restore. Before it exits, it draws a green pixel in the middle of both OSD bitmap buffers' left side. Before that it checks which buffer has been updated by Canon firmware by checking which green pixel is no longer green. It's a kludge but at least in REC mode it works, because Canon OSD doesn't draw to the very edge of the LCD while half shooting, so after Canon OSD update middle pixels will be transparent in the updated buffer. You can see the green pixel on the screen if you look carefully, during autoexposure/focus and during entire half shoot if zebra is not drawn due to good exposure.

Apparently in play mode the above is different. draw_guard_pixel() returns zero if neither OSD bitmap buffer was refreshed by Canon firmware. Clearly this happens nearly always in play mode (I'm able to have it return something else if I half shoot while CHDK is booting to play mode). I guess this is because half shoot doesn't do anything to Canon OSD in play mode so the green pixels stay put.

Ljl's code stopped zebra draw if draw_guard_pixel() returns zero. In rec mode this would indicate some sort of error, but I guess there's no reason to stop zebra from being drawn to both buffers just because Canon OSD rescue will only succeed with 50% probability (assuming the error condition doesn't make things even less probable).

The copy of this Canon OSD bitmap buffer is placed in cur_buf[] if border restore is disabled. If border restore is enabled, only narrow stripes from top and bottom (cur_buf_top[] and cur_buf_bot[])) are stored. In border restore mode get_cur_buf(pixelindex) is used for referencing this split buffer instead of cur_buf[pixelindex]. It checks if the requested pixel is in either of the buffers and returns the desired value or transparent color if outside the buffer.

The copy is required, because zebra is drawn to that exact buffer (and the other one too). So, first zebra draw wouldn't need this cur_buf (because it could check for Canon OSD there while it's drawing), but after that there will be zebra lines all over and we can't have them cumulating.


Logged
*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Cropped zebra or zebra specific OSD
« Reply #74 on: 28 / December / 2008, 07:31:42 »
this sounds complicated :D
gimme something easy to comitt to svn, like a diff ;)
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Cropped zebra or zebra specific OSD
« Reply #75 on: 28 / December / 2008, 08:40:25 »
Quote from: PhyrePhoX on 28 / December / 2008, 07:31:42
this sounds complicated :D
gimme something easy to comitt to svn, like a diff ;)

That short to int thing should be added asap I suppose, it's a definite bug, although I have no clue if gcc will actually compile it to be dangerous.

But play mode zebra is a bit more complex. If I do as ewavr suggests, zebra is indeed drawn in play mode half shoot along with histogram if they are enabled, but there are two problems, both caused by zebra not knowing which display buffer is active. I don't know if these things affect all camera models equally, I can only speak for my a570is.

1) Play mode zebra doesn't know which display buffer to read the LCD image from. Actually for most cameras it doesn't in REC mode either (ones that don't have the MD speedup implemented, see my previous message). In REC mode the buffers are refreshed and swapped repeatedly, so zebra is just a little bit slower to react for those cameras most of the time. But in PLAY mode buffer is changed only when display is updated, i.e. when changing image, display mode or navigating menus, zooming/panning etc. There seem to be 2 buffers in use for this, and zebra is drawn from the wrong one half the time.

An easy way to try this (on a build which draws zebra in PLAY mode) is to shoot something with a overexposed spot in it, go to play mode, half shoot, zoom, half shoot, pan around, half shoot etc. Half the time zebra is drawn according to the previous image position/size, half the time it's correct.

2) The very same (for writing this message I didn't check if this was the same actual buffer or another one i.e. does play mode write to the buffers used for osd in rec mode or somewhere else) thing makes "new zebra" work against us. Half the time OSD restore will restore something we don't want it to, we can see for example parts of (assuming border restore mode) Canon menu on the screen with weird colors.


Canon OSD restore for zebra is not needed in play mode; actually half shooting with zebra enabled without Canon OSD restore would be a nice way of getting rid of Canon OSD to see the entire image all nice clean! So, it should be disabled for play mode.

But even if that's done, zebra will still be incorrectly drawn half the time, at least for my cameras and ones like it, maybe all of them, before we figure out & implement a way to find which buffer to draw from.
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Cropped zebra or zebra specific OSD
« Reply #76 on: 28 / December / 2008, 09:48:56 »
Attached a diff which fixes the 4-bytes-to-a-short bug, enables zebra in play mode, disables Canon OSD restore for play mode zebra (does not release the memory).

I took the liberty of limiting number of mode_get()'s to one per zebra draw, I guess it should be enough and that !mode_get()==MODE_REC (pseudo code) safely equals to MODE_PLAY in regard of zebra requirements.

This doesn't fix play mode zebra calculating from previous LCD view half the time when zooming around in PLAY mode, but it's better to have it work partially than not at all IMO.
Logged
*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Cropped zebra or zebra specific OSD
« Reply #77 on: 28 / December / 2008, 15:39:17 »
comitted to #655. i tested everything, worked fine on s3is (though it worked fine before :D).
cant test zebra in playmode, since my cam switches to recmode as soon as i halfpress the shutter.
Logged
*

Offline mngc

  • ***
  • 113
  • a590is fw 1.0.1b & sx110is fw 1.0b
Re: Cropped zebra or zebra specific OSD
« Reply #78 on: 29 / December / 2008, 12:07:00 »
Thanks everybody.

Now i try my a590is fw1.01b with chdk 0.9.0-657. Zebra record mode ok. Histogram record mode ok.
Zebra in play back mode, changed the problem, wrong, now blinking the zebra (not on the overexposured areas again, similair an older build). I think the zebra not from the correct image display buffer.
(i'm not a expert, please help, thanks)

Record mode histogram ok, playback histogram works again, /histogram parameters-Show live histogram->Shoot/ but similar an older build, zoomed image with histogram show the original full image histogram. Buffer problem, too?
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Cropped zebra or zebra specific OSD
« Reply #79 on: 29 / December / 2008, 17:07:06 »
mngc, see my previous post. If you keep zooming, panning and changing pictures, are histogram and zebra ALWAYS incorrect, or are they correct for example half the time like on my a570?


a590 port is very new, could vid_get_viewport_fb_d() be still incorrect? Or in the case of it being one of multiple (2) buffers, it may have the one that's more often incorrect (for a570is play zebra seems usually correct the first time I try it, and it goes bad when zooming etc).
Logged
Pages: 1 ... 3 4 5 6 7 [8] 9 10   Go Up
« previous next »
 

Related Topics