chdk bootup logo mod

[fishpepper]

Hi!

I was wondering why chdk isnt showing the nice logo while booting up.
So i hacked this:


What i did:
- take chdk logo
- crop in gimp
- reduce to 8 (?) colors/palette
- save as c header file in gimp
- search for matching colors using the palette viewer in chdk
- change values in gui_logo.h to the chdk palette values
- small addon in draw_splash

See the attached diff 

[lukg]

Nice!! Chdk deserves a boot logo! Want to see it in all major release!!

[waldo]

I agree.  A nice improvement.  I also think the text in the blue box could be improved.  Maybe larger white text on a red background.  And I don't think the camera type and firmware version is needed - you will never get CHDK to boot if you do not already know this information.

Also, does this work correctly if turned on in playback mode?  I think it uses a different palette.

[fishpepper]

Thanks

Playback: oh this was playback mode. But in record the grey turns into orange...

Changing 0x3E to 0x1F as colors for the dark grey fixes this. See the attached new file.

Is there any info how the palette works ? I got the colors by try n error looking at the palette and trying to imagine how it would look like for the logo.
It would also be possible to do the logo with some similar colors but with some transparency (could like nice as well i think).

[PhyrePhoX]

added in 0.3.0 of the juciphox branch. thanks!
think i'm gonna add this in the branch as well, though not today.

[bbriand]

This is great.  It is along the lines of something I was wondering.  Is it possible for the camera to display the logo with an alpha masked or semi transparent?  If so could the logo be made to stay on the screen indefinitely and then we could use it as a poor mans contrast adjustment?  Like a gray tone for contrast or a red tone to preserve night vision.

Bill

[mx3]

nice idea.

I was wondering why chdk isnt showing the nice logo while booting up.

because logo requires additional bytes in .bin file.
"main" developers are fighting over every byte to keep file size low.

There were situations several times when memory heap manual adjustment was required for new file to boot.

[PhyrePhoX]

Well we still dont know the technical/hardware boundaries that canon laid out for us,so as long as there are no sideeffects,why not increasing memisosize?
And if we get sideeffects soon,there are alot of possibilities to shrink the bins by optimizing existing code or the elf will help,certainly.

[reyalp]

Well we still dont know the technical/hardware boundaries that canon laid out for us,so as long as there are no sideeffects,why not increasing memisosize?
And if we get sideeffects soon,there are alot of possibilities to shrink the bins by optimizing existing code or the elf will help,certainly.

Less memory available for other stuff.

Sure, we can make up for it by saving in other areas (and there is quite a lot of room for this), but I would personally prefer stuff that is purely cosmetic like this be optional. In this case, loading the logo from another file should be possible, right ?

[fishpepper]

If memorysize is an issue it should be no problem to shrink the logo to a fraction of its size
using run length encoding.
I did not invest any time in saving space for the logo yet. But as it uses only 8 colors and 150x84px
there is a lot of space for improvements. Currently I "waste" 8bit for every pixel (!)
This could be reduced to 3Bit/Pixel (=8 colors) and RLE would make it much smaller.

[fishpepper]

ok a quick test shows:
- logo as it is: 3150 x 32 bit
- logo as 3bit/pixel: 1182 x 32 bit
- logo as rle: 827 x 32 bit

[DataGhost]

You could use a lookup table to map the used colors into 2 or 3 bits, maybe add a little bit of logic to handle long pieces of the same color (lines) and maybe you can even compress it afterwards... or let the compression handle the last two parts. Keep in mind, though, any decompression algorithm also requires code.

As I see it, it's white, black, red and grey (except for the grey-ish inner ring)? That'll fit into 2 bits, which is also a lot easier to process than 3 bits.

[fishpepper]

Hi!

Ok i did the modifications for RLE encoding the picture

I included my quickndirty perl program that converts the image from gimp to the
RLE compressed image as c header. Requirements for converting any logo to this:
- input image in header file format (gimp)
- 8 colors  (palette values needs to be entered in perl script)
- 150px wide (could be changed in gui.c)
-> convert it into header with the perl file in the attached tgz

Here is the new gui.c code (also in tgz):

Code: Diff

1. Index: core/gui.c
2. ===================================================================
3. --- core/gui.c  (revision 469)
4. +++ core/gui.c  (working copy)
5. @@ -29,6 +29,7 @@
6.  #include "script.h"
7.  #include "motion_detector.h"
8.  #include "raw.h"
9. +#include "gui_logo.h"
10.  
11.  //-------------------------------------------------------------------
12.  
13. @@ -2179,11 +2180,35 @@
14.      }
15.      w=w*FONT_WIDTH+10;
16.  
17. -    x = (screen_width-w)>>1; y = (screen_height-h)>>1;
18. +    x = (screen_width-w)>>1; y = ((screen_height-h)>>1) + 20;
19.      draw_filled_round_rect(x, y, x+w, y+h, cl);
20.      for (i=0; i<sizeof(text)/sizeof(text[0]); ++i) {
21.          draw_string(x+((w-strlen(text[i])*FONT_WIDTH)>>1), y+i*FONT_HEIGHT+4, text[i], cl);
22.      }
23. +
24. +    int pos;
25. +    int mx=0;
26. +    int my=0;
27. +    int offset_x = (screen_width-150)>>1;
28. +    int offset_y = ((screen_height-84)>>1) - 42;
29. +    const color color_lookup[8] = {0xFF, 0x2E, 0x22, 0x3D, 0x1F,  0x21, 0x00, 0x11};
30. +
31. +    for(pos=0; pos<HEADER_DATA_LEN; pos++){
32. +        char data = header_data[pos];
33. +        color c = color_lookup[(data>>5) & 0x07];
34. +        for(i=0; i<(data&0x1F)+1; i++){
35. +            if (c!=0x00){
36. +                draw_pixel(offset_x+mx,offset_y+my,c);
37. +            }
38. +            if (mx==149){
39. +                mx=0;
40. +                my++;
41. +            }else{
42. +                mx++;
43. +            }
44. +
45. +        }
46. +    }
47.  }
48.  
49.  //-------------------------------------------------------------------
50.  
51.  

This way i could shrink the image from 12600 bytes (it was completely unoptimized)
down to 2457Bytes (=only 615 x 32 bit !)

The code to decode it is also very small (could be optimized for runtime i guess but not necessary)

Btw saving the image uncompressed as 8 colors/px would result in 4725Bytes

I think RLE is the best solution for the image. And wasting 615 words (32 bit each) should be no problem

[PhyrePhoX]

added your patch to the branch. decreased binary size like you predicted. now if use an image from the filesystem it of course would reduce size again, but then again i wouldnt know how to do that