Palette editor - page 2 - Feature Requests - CHDK Forum
« previous next »
Pages: 1 [2]   Go Down

Palette editor

  • 19 Replies
  • 14570 Views
*

Offline outslider

  • *****
  • 762
Re: Palette editor
« Reply #10 on: 14 / July / 2012, 18:25:16 »
Advertisements
Ok. So based on this:

Quote from: a1ex 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


this:

Quote from: srsa_4c on 14 / July / 2012, 17:11:53
Quote from: outslider on 14 / July / 2012, 11:22:17
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.

this:

http://chdk.setepontos.com/index.php?topic=7697.0

and this:

http://magiclantern.wikia.com/wiki/Register_Map/60D

I did this:
Code: (lua) [Select]

--[[
@title palette tests
--]]



base1 = 0xc0f14400
base2 = 0xc0f14800


paletteY={}
paletteU={}
paletteV={}
paletteOp={}

for p=0, 255 do
    paletteY[p]=math.random(1,255)
    paletteU[p]=math.random(1,255)
    paletteV[p]=math.random(1,255)
    paletteOp[p]=math.random(1,255)
end


repeat

    for i=0, 255 do
        --print(i)
        poke(base1+4*i,     paletteOp[i]) -- opacity
        poke(base1+4*i+1,   paletteY[i]) -- y
        poke(base1+4*i+2,   paletteU[i]) -- u
        poke(base1+4*i+3,   paletteV[i]) -- v
       
        poke(base2+4*i,     paletteOp[i]) -- opacity
        poke(base2+4*i+1,   paletteY[i]) -- y
        poke(base2+4*i+2,   paletteU[i]) -- u
        poke(base2+4*i+3,   paletteV[i]) -- v
       

    end
    sleep(100)
until 2==3


-------------
-------------
[code=lua]



This simple script tries to put random color palette in memory. And it does. This way the palette can be very easy changed in portable way.

For more 'usable' purpouses the color replacement should be added somewhere in CHDK source code and data should be overwritten every task round (note: if repeat-until loop is removed the Canon firmware replace custom palette with usual Canon palette).

As you can see above script causes palette to become red-green based, but playing more with YUV values and this strange 'opacity?' we probably achive any color.

Playing with the palette seems to be worth the effort. Universal colors for CHDK! On sx130 there is more than 20 unused colors (depending on mode). Nevertheless in Canon menu mode most of the palette is used due to fancy gradients in menu...
« Last Edit: 14 / July / 2012, 18:41:39 by outslider »
Logged
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick
*

Offline outslider

  • *****
  • 762
Re: Palette editor
« Reply #11 on: 15 / July / 2012, 08:33:26 »
Above code has bug - I understood poke wrong. Below code places good random values into pallette:

Code: (lua) [Select]
--[[
@title palette tests

@param s start
@default s 0
@range s 0 255

@param e end
@default e 255
@range e 0 255
--]]



base1 = 0xc0f14400
base2 = 0xc0f14800


paletteY={}
paletteU={}
paletteV={}
paletteOp={}

for p=0, 255 do
    paletteY[p]=math.random(1,255)
    paletteU[p]=math.random(1,255)
    paletteV[p]=math.random(1,255)
end


repeat

    for i=0, 255 do
        --print(i)
       
        if i>s and i<e then
            value = paletteV[i]+256*paletteU[i]+65536*paletteY[i]
            poke(base1+4*i,     value)
        end

    end
    sleep(100)
until 2==3


-------------
-------------
Logged
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick
*

Offline srsa_4c

  • ******
  • 4451
Re: Palette editor
« Reply #12 on: 15 / July / 2012, 12:35:28 »
Just a note. This particular method of setting the palette seems to be only supported on DIGIC4 or higher.
Logged
*

Offline outslider

  • *****
  • 762
Re: Palette editor
« Reply #13 on: 15 / July / 2012, 12:43:20 »
However, it can be still better than we have now ;) I suggest to move discussion to the thread:

http://chdk.setepontos.com/index.php?topic=8314.new#new

Maybe something usefull will be born here...
Logged
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Palette editor
« Reply #14 on: 22 / March / 2013, 22:03:29 »
Quote from: philmoz on 13 / July / 2012, 19:43:53
Quote from: waterwingz on 13 / July / 2012, 18:18:29
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.

@philmoz : Old post but new problem so I think is the best place to ask this.

I've been working on the screen colors for sx50hs port.  The colors specified in active_palette_buffer() that every other camera implementing this function uses turn out to be semi-transparent on the sx50hs.   While some might find this attractive,  it make things like CHDK menus hard to read.   

So my question is how you arrived at the hex color values you used in that function?   I tried adding debugs to "peek" color values from the unmodified palette buffers and that works.  But the sx50 does not have a lot of nice bright colors (other than standard Canon orange,white and black) so random peeks are not going to get me nice reds, blues or greens.

Also, for the record,  the valid active_palette_buffer values for the sx50hs are 0,5,6 for shooting, playback,menu respectively.
 


Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Palette editor
« Reply #15 on: 22 / March / 2013, 22:22:26 »
Quote from: waterwingz on 22 / March / 2013, 22:03:29
Quote from: philmoz on 13 / July / 2012, 19:43:53
Quote from: waterwingz on 13 / July / 2012, 18:18:29
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.

@philmoz : Old post but new problem so I think is the best place to ask this.

I've been working on the screen colors for sx50hs port.  The colors specified in active_palette_buffer() that every other camera implementing this function uses turn out to be semi-transparent on the sx50hs.   While some might find this attractive,  it make things like CHDK menus hard to read.   

So my question is how you arrived at the hex color values you used in that function?   I tried adding debugs to "peek" color values from the unmodified palette buffers and that works.  But the sx50 does not have a lot of nice bright colors (other than standard Canon orange,white and black) so random peeks are not going to get me nice reds, blues or greens.

Also, for the record,  the valid active_palette_buffer values for the sx50hs are 0,5,6 for shooting, playback,menu respectively.
 

Sounds like the 'A' transparency component of the AYUV color is wrong.
On my cameras the palette only uses A values of 0, 1, 2 & 3 - 0 is fully transparent and 3 is no transparency.

Canon have probably changed value range for transparency.

All the palette values in my hack have 3 as the top most byte - you could try changing this to see what happens.
Alternatively dump the palette memory and look at the A component of the built in colors to see what values are used.

Edit: If the transparency values have changed then the live view in chdkptp will also need to be changed to work with the new values.

Phil.
« Last Edit: 22 / March / 2013, 22:24:03 by philmoz »
Logged
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)
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Palette editor
« Reply #16 on: 22 / March / 2013, 22:31:43 »
Quote from: philmoz on 22 / March / 2013, 22:22:26
Sounds like the 'A' transparency component of the AYUV color is wrong.
On my cameras the palette only uses A values of 0, 1, 2 & 3 - 0 is fully transparent and 3 is no transparency. Canon have probably changed value range for transparency. All the palette values in my hack have 3 as the top most byte - you could try changing this to see what happens.
I guess I can search for this but its Friday here at the end zone of 24 hour global time so I'll just ask.  What's the bit level layout of AYUV ?  8 bits for each of A, Y, U, & V ?

Quote
Alternatively dump the palette memory and look at the A component of the built in colors to see what values are used.
Well,  doing a memory peek on the Canon orange value I get :  0x3FA2D033 .  So A=3F,  Y=A2,  U=D0 and V=33 ?


« Last Edit: 22 / March / 2013, 22:34:19 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Palette editor
« Reply #17 on: 22 / March / 2013, 22:37:57 »
Quote from: waterwingz on 22 / March / 2013, 22:31:43
Quote from: philmoz on 22 / March / 2013, 22:22:26
Sounds like the 'A' transparency component of the AYUV color is wrong.
On my cameras the palette only uses A values of 0, 1, 2 & 3 - 0 is fully transparent and 3 is no transparency. Canon have probably changed value range for transparency. All the palette values in my hack have 3 as the top most byte - you could try changing this to see what happens.
I guess I can search for this but its Friday here at the end zone of 24 hour global time so I'll just ask.  What's the bit level layout of AYUV ?  8 bits for each of A, Y, U, & V ?

Quote
Alternatively dump the palette memory and look at the A component of the built in colors to see what values are used.
Well,  doing a memory peek on the Canon orange value I get :  0x3FA2D033 .  So A=3F,  Y=A2,  U=D0 and V=33 ?


Yes, 4 bytes, 1 byte for each component.

Looking at the palette definitions in the firmware shows it uses the values 0, 1f, 2f and 3f instead of 0, 1, 2 & 3.

Phil.
Logged
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)
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Palette editor
« Reply #18 on: 22 / March / 2013, 22:39:59 »
Quote from: philmoz on 22 / March / 2013, 22:37:57
Looking at the palette definitions in the firmware shows it uses the values 0, 1f, 2f and 3f instead of 0, 1, 2 & 3.
Just rebuilt using 3f (random guess).  I'll test and report back ..

Update :  that nailed it - thank (once again) philmoz !!
« Last Edit: 22 / March / 2013, 22:59:01 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Palette editor
« Reply #19 on: 09 / June / 2013, 14:07:30 »
Lacking a better place to post this,  I thought I'd share the results of philmoz's latest update - adding a custom palette capability for DryOS cameras.  It takes a little work to update the lib.c file for a camera but once its done you no longer have to deal with menu colors that change between shooting and playback mode.  You also get bright clean colors that might not have been available in the standard Canon palette.  And the colors used by Lua screen writing commands are much better too.

For example,  the IXUS120_SD940 menus used to look like this in playback mode :


and like this in shooting mode :


That was the best trade-off I could find with the colors available.

Now the menu looks like this in both shooting and playback mode.  Colors are a matter of personal taste and I happen to like these.  However, you can customize yours, they will stay locked in shooting or playback mode,  and you get choices of strong colors that might not be offered in the standard Canon palettes.


As always, YMMV.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: 1 [2]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal