Palette editor - Feature Requests - CHDK Forum supplierdeeply

Palette editor

  • 19 Replies
  • 12456 Views
Palette editor
« on: 13 / July / 2012, 15:24:14 »
Advertisements
I think it should be possible to edit the color palette used by CHDK and the Canon OS. This will not only enable more colors to be used in CHDK (as in some cameras, such as the SX230HS, almost half of the palette is just unused white color slots) but also enable the user to customize the colors used by the camera's menus.


Re: Palette editor
« Reply #1 on: 13 / July / 2012, 18:18:10 »
Yes, would be good. But nobody has idea how to do so.

AFAIK Reyalp has done some palette customizations on two or three cameras, but the whole thing was very compicated and completely not portable.

As for now we can only poke some bytes to appropriate memory addresses to use colors. When you push 8 bit value to the display buffer address you'll get a pixel having some color. But the way the value is interpreted is unclear. Canon firmware uses same values for different colors in different modes and on different cameras.

The problem is that the piece of Canon firmware, which translates the 8-bit value to the color displayed on the screen is still unhacked.

PS. Some colors seem to be never used by Canon firmware. For example usually you can find R, G and B colors in palette, while camera never uses them. What does it stand for? Maybe Canon developers wanted to give CHDK developers a way to display histogram :D
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

Re: Palette editor
« Reply #2 on: 13 / July / 2012, 18:18:29 »
I think it should be possible to edit the color palette used by CHDK and the Canon OS. This will not only enable more colors to be used in CHDK (as in some cameras, such as the SX230HS, almost half of the palette is just unused white color slots) but also enable the user to customize the colors used by the camera's menus.
This has been done for a few cameras on a custom basis by philmoz.  IIRC,  he was able to remap the pointers to the Canon palettes to an area in RAM where he created a custom pallette. 

However, a general solution that works for all cameras has not been identified. You are certainly  welcome to try.

One complication you should be aware of is that Canon cameras use different palettes at different times depending on what the camera UI is doing.  Take a look at the CHDK pallette screen at different times when the camera is in shooting, playback or any of the menu modes for an  example of this.
Ported :   A1200    SD940   G10    Powershot N    G16

Re: Palette editor
« Reply #3 on: 13 / July / 2012, 19:03:24 »
Really? I would have imagined it was as simple to port as anything else with an address that varies between cameras, like the LEDs.


Re: Palette editor
« Reply #4 on: 13 / July / 2012, 19:07:12 »
Really? I would have imagined it was as simple to port as anything else with an address that varies between cameras, like the LEDs.
The issue isn't the address.  Its that the code that accesses the palettes does it differently in different generations of cameras.

But I would be happy to be proven wrong if you want to dig into this and post the results.

Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Palette editor
« Reply #5 on: 13 / July / 2012, 19:43:53 »
This has been done for a few cameras on a custom basis by philmoz.  IIRC,  he was able to remap the pointers to the Canon palettes to an area in RAM where he created a custom pallette. 

Not quite.

On the cameras I did there are multiple palette definitions in the firmware (in some cases up to 16 different palettes).
When the camera changes mode the appropriate firmware data is copied to a RAM buffer, again there are multiple of these.

My 'hack' overwrites the active RAM buffer with CHDK color values (32 bit ARGB AYUV) in fixed locations; but it is only done for some palette modes - record, playback etc. In other modes the CHDK colors will be whatever the firmware has set them to.
This is done at the start of the spytask loop, every 20ms or so.

To use my hack you have to:
- find the RAM buffer address for the palette data and the active palette
- find the mode numbers for the active palette for the modes you want to overwrite
- find a block of 13 colors that are not used in the Canon firmware for each mode

For simplicity my solution assumes you can find a common block of colors to overwrite.

Phil.
« Last Edit: 14 / July / 2012, 19:34:08 by philmoz »
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: Palette editor
« Reply #6 on: 14 / July / 2012, 06:49:34 »
Phil, forgive me, I wrote it was done by reyalp ;)
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: Palette editor
« Reply #7 on: 14 / July / 2012, 06:59:47 »
On DSLRs, a portable way to modify the palette is to write it at C0F14400 and C0F14800.

Sample code: https://bitbucket.org/hudson/magic-lantern/src/tip/src/tweaks.c#cl-2090


Re: Palette editor
« Reply #8 on: 14 / July / 2012, 11:22:17 »
As I can see on DLSR it's YUV model?

y, u and v are 8-bit?

EngDrvOut = kind of poke?

do you need to poke values on both 0xC0F14400 and 0xC0F14800? Yeah, I know they'd be probably different on P&S.

@Phil

How did you find the addresses?
« Last Edit: 14 / July / 2012, 11:30:32 by outslider »
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

*

Offline srsa_4c

  • ******
  • 4451
Re: Palette editor
« Reply #9 on: 14 / July / 2012, 17:11:53 »
As I can see on DLSR it's YUV model?
y, u and v are 8-bit?
It's also YUV here (we're running on the same DIGIC), yes, 8 bit/component.
Quote
EngDrvOut = kind of poke?
Yes, the function writes a 32bit value into a DIGIC register (0xc0xxxxxx), and also saves that value into a RAM location.
Quote
do you need to poke values on both 0xC0F14400 and 0xC0F14800? Yeah, I know they'd be probably different on P&S.
Probably not, same DIGIC.

 

Related Topics