Zebra display can work on all 16:9 TFT Cams but change need to lower mem usage. - DryOS Development - CHDK Forum

Zebra display can work on all 16:9 TFT Cams but change need to lower mem usage.

  • 14 Replies
  • 10975 Views
Advertisements
I get on IX1000 Zebra mode working(in 16:9 shooting mode) when i add the define in camera.h for this Cam

#define CAM_ZEBRA_ASPECT_ADJUST

I see this from IX300 Port.
I do build a strip down port(without textreader, games)and when i use zebra, there are only 1520 bytes free and sometimes the camera power off, for example when press menu key and zebra is in play mode active(i do for more easy testing enable zebra always in code).I think it happen because low on memory.

So i change the code to be able to work without extra buffer.it can work too and i do notice only few diffrence.maybe on slower CAM/CPU flicker is visible.I do some test and it work stable.

Only bad there need changes in a core file for this.So i test the define CAM_ZEBRA_NOBUF, here zebra work too, but then the zebra output is in x size wrong(too small).i use 16:9 shootung mode, on 4:3 modes always postion is wrong

Maybe somebody have a better solution what to do, or maybe can add in the chdk main core a define CAM_ZEBRA_ASPECT_ADJUST_USE_NO_BUFFER, that can set and then no buffer is used for the zebra mode.

here is the code i use for testing


in file core/GUI_OSD.c

static void gui_osd_zebra_free() {
#if !defined (CAM_ZEBRA_NOBUF)
-      free(buf);
+   //free(buf);
#endif
   buf=NULL;
#if ZEBRA_CANONOSD_BORDER_RESTORE
   free(cur_buf_top);

........

static int gui_osd_zebra_init(int show) {
   unsigned i;

  if(show)
  {
    if (!buf)
    {
      timer = 0;
     #if defined (CAM_ZEBRA_NOBUF)
        buffer_size=screen_buffer_size-ZEBRA_HMARGIN0*screen_buffer_width;
        buf=vid_get_bitmap_fb();
     #elif defined (CAM_ZEBRA_ASPECT_ADJUST)
        buffer_size=screen_buffer_size-ZEBRA_HMARGIN0*screen_buffer_width;
-        buf = malloc(buffer_size);
+        //buf = malloc(buffer_size);
        //~ if (!buf) draw_txt_string(0, 14, "Warn: No space to allocate zebra buffer: restart camera", MAKE_COLOR(COLOR_ALT_BG, COLOR_FG));
        if (!buf)
          buf=vid_get_bitmap_fb(); //without new buffer: directly into screen buffer: we got some flickering in OSD and histogram but it's usable
« Last Edit: 19 / December / 2010, 04:41:04 by Bernd R »
Ixus 1000 HS

*

Offline reyalp

  • ******
  • 14126
Explain *why* NOBUF doesn't work on this camera, or better yet fix it. It should do exactly what you are trying to do.
Don't forget what the H stands for.

>Explain *why* NOBUF doesn't work on this camera, or better yet fix it. It should do exactly what you are >trying to do.

I see that there are 2 functions

gui_osd_draw_zebra(int show)

see here the example.this should show a box that is full overexpose.the content fill with Z is zebra and the content that the zebra not show is written with N, but zebra should show too.
non overexpose is -.shoot mode  is 16:9

-----ZZZZNNNN-----
-----ZZZZNNNN-----


My programing skills are not so good, that i can change nobuff mode, it use too much diffrent code.I do get it working and exchange 30-40 times the SD Card

Also its a big problem for me to test often since yesterday.
I have so often insert and remove the sd card, that the weak plastic door of my cam is a little broken.I think its design that the sd card is not often exchange.the battery door is stronger and it is with 2 screws on the plastic fixed

its ok, when the door is close, but i need longer time to put the plastic sd card door on the metal thing, because there is on 1 side a 1 mm * 3mm rectangle in the plastic door broken, so the plastic door fall when i open the door from the metal.

I dont know what happen when the other side break, so i was now extrem carefully and test not much.

sd card door broken, can read more on inet too, i take a look.I always move the Card door very soft, but this is bad design from Canon i think.wy this have no screws as the battery door.

BTW: that i buy the canon was only reason because chdk.

Casio camera have builtin histogram, have configurable key, so can switch ev with left right.and sd card can use from windows as massstorage device.but of course cant reach the features as canon with chdk

But maybe its possible to find a way to transfer the chdk files with the USB cable ?
« Last Edit: 19 / December / 2010, 14:52:08 by Bernd R »
Ixus 1000 HS

*

Offline reyalp

  • ******
  • 14126
Quote
But maybe its possible to find a way to transfer the chdk files with the USB cable ?
Use CHDK PTP. Yes, the battery doors on canons are mostly flimsy and not meant to be opened / closed a lot.

Your description doesn't give me any insight into why NOBUF doesn't work. I don't understand your description at all. Maybe you can post screenshots of each one ?

Trying to code by trial and error without understanding is a problem. If you want to fix things, you need to understand.
Don't forget what the H stands for.

>Trying to code by trial and error without understanding is a problem. If you want to fix things, you need to >understand.

yes, but if nobody else do that, do by trail and error is better than nothing.
for programming without source level debugger you must be a very excelent programmer.
there are not a lot out in the world, so all modern develop system use source level Debugger.

When i can single step the code, i can tell you what go wrong easy or offer a fix, but understand code by just reading is hard for me.

also i am 45 years old, and my english is not soo good.
but as can see on chdk, the few excellent programmers seem have no time, so the way i do, trail and error is slow, but better as nothing i think.

and when expert programmers tell me what to do on the problems, can help to speed up developing too.

EDIT:

thanks,

I now verify again and set the 2 defines in camera.h and it work now in a quick test.

#define CAM_ZEBRA_ASPECT_ADJUST
#define CAM_ZEBRA_NOBUF
« Last Edit: 20 / December / 2010, 06:14:52 by Bernd R »
Ixus 1000 HS

I notice sometimes a crash shoert after chdk init, with that 2 defines, because i have for easy zebra testing always zebra view on.

But i test longer and let you know, if the CAM crash also when only on shoot half zebra is show

thats my testcode

int show = conf.zebra_draw && gui_mode==GUI_MODE_NONE &&
                     kbd_is_key_pressed(KEY_SHOOT_HALF) && mode_photo &&
                     !state_kbd_script_run;
//       sprintf(osd_buf, "1: %d",show);
//draw_txt_string(20, 9, osd_buf, MAKE_COLOR(0xdd,0x6f));
    show = 1;
   if (gui_osd_draw_zebra(show)) {// no zebra when script running, to save mem
      return; // if zebra drawn, we're done
   }

Edit:

The good news is, when zebra is only show when shoot half is press, then no crash happen.


« Last Edit: 20 / December / 2010, 09:56:16 by Bernd R »
Ixus 1000 HS

*

Offline reyalp

  • ******
  • 14126
yes, but if nobody else do that, do by trail and error is better than nothing.
Not if you add more bugs, which is very likely. There's already so much of this in CHDK :(

I appreciate all your effort. I just can't take code that I can't understand, and if the person who wrote it doesn't understand it, then probably I won't understand it either. If I don't have a camera that shows a problem, then I can't verify by testing.

Quote
#define CAM_ZEBRA_ASPECT_ADJUST
#define CAM_ZEBRA_NOBUF
So both together works fine without any code changes ? They are supposed to be used together, actually there should be a #error if you defined only NOBUF ?
Code: [Select]
#if defined (CAM_ZEBRA_NOBUF) && !defined(CAM_ZEBRA_ASPECT_ADJUST)
// old sx20 #ifdefs were roughly equivalent of both
#error "defined (CAM_ZEBRA_NOBUF) && !defined(CAM_ZEBRA_ASPECT_ADJUST). Remove this if you've verified it will work!"
#endif
Don't forget what the H stands for.

@reyalp
>Not if you add more bugs, which is very likely.

when i change something, i test very carefully.

>So both together works fine without any code changes ? They are supposed to be used together, actually >there should be a #error if you defined only NOBUF ?

yes, when i switch both on, it work and need no code changes.

>actually there should be a #error if you defined only NOBUF ?

because i get before a crash on zebra in play mode, i change code so only NOBUF is used and it kompile
here it work, but the size of zebra was not ok.but on a 4:3 camera display zebra should work ok.

>If I don't have a camera that shows a problem, then I can't verify by testing.

I can sponser a cheap CAM (50-100 Eur) that support 16:9 230000 Pixel display, if somebody have the time und wish to make chdk better working on the 16:9 display cams.

I have also the idea in 16:9 mode, to add grid lines , that show the 3:2 area too(because print on all machines is in 3:2 (15*10).but still the grid are not large enough in X size on 16:9 display.

Canon Firmware can only show in 4:3 shoot mode 3:2 area

but best wait for newer cheap models, it seem the IX 1000 is the first canon that set a bit if a key is press and the way the keyboard hack is add, alt mode work not good for this camera.

But now with zebra working in 16:9 shoot mode, and fast ev switch with the wheel(need no alt mode enter) chdk is in this state still very good.

BTW: i find out, when Servo AF is on, then the change of EV with wheel, during shoot half press do not work, if somebody get it not working on other Camera too.
Ixus 1000 HS

I find in the stubs this function.

AllocateUncacheableMemory

Is it possible to allocate ram for zebra buffer with that function and is there a chance that there is more Ram available as the 250 kb that is show in free ram ?

I think the RAM that is show in free ram is normal cacheable RAM
Ixus 1000 HS

*

Offline reyalp

  • ******
  • 14126
I find in the stubs this function.

AllocateUncacheableMemory

Is it possible to allocate ram for zebra buffer with that function and is there a chance that there is more Ram available as the 250 kb that is show in free ram ?

I think the RAM that is show in free ram is normal cacheable RAM
Uncacheable memory comes to the *same* pools as malloc, it just OR's the uncachable bit into the pointer after calling malloc (plus some padding).

See http://chdk.setepontos.com/index.php/topic,1910.msg42829.html#msg42829 and http://chdk.wikia.com/wiki/CHDK_Coding_Guidelines#Memory_APIs_and_CPU_caching

There are other memory pools that could be (ab)used, but again: get basic functionality working, get port merged, *then* add new/experimental features. This port is already going to be hard enough to deal with, without trying to sort out a bunch of new, unique, poorly understood hacks.
Don't forget what the H stands for.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal