Universal color palette for CHDK

Hi!

The idea came recently here:

http://chdk.setepontos.com/index.php?topic=8306.msg87778#msg87778

and some nice progress has been done there. However to not bump that thread I decided to start new thread for development ov universal CHDK palette.

Replacement of two sets of addresses starting at C0F14400 and C0F14800 provides possibility to replace any color from palette with YUV values. The example script is posted in mentioned thread.

See:

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

Currently I play with converting RGB value to YUV but with no success. Y is unsigned 8-bit value where values of YUV model are 0-1 (0-255)

Problems are with U and V values, which are also unsigned ints but values -1 to 0 are probably 128-255 and 0 to 1 are 0-127.

I tried to implement the code from online converter:

http://www.mikekohn.net/file_formats/yuv_rgb_converter.php

which bases on:

http://softpixel.com/~cwright/programming/colorspace/yuv/

but no success - colors are wrong. I don't know a lot about YUV model and need help with convertion.

Nevertheless the whole thing works - we can replace unused palette colors for any colors we need.

Here's a script in which I tried to use RGB values. Any suggestions?

--[[
@title palette tests

@param r R
@default r 0

@param g G
@default g 0

@param b B
@default b 0
--]]

set_console_layout(0,0,40,10)

base1 = 0xc0f14400
base2 = 0xc0f14800

function rgb_to_y(rv,gv,bv)
   
    yv = (299*rv + 587*gv + 114*bv)/1000
    return(yv)
end

function rgb_to_u(rv,gv,bv)
   
    uv = (-169*rv - 331*gv + 500*bv)/1000 + 128
   
    return(uv)
end

function rgb_to_v(rv,gv,bv)
   
    vv = (500*rv - 419*gv - 81*bv)/1000 + 128
   
    return(vv)
end


y=rgb_to_y(r,g,b)
u=rgb_to_u(r,g,b)
v=rgb_to_v(r,g,b)

print("r "..r.." g "..g.." b "..b)
print("y "..y.." u "..u.." v "..v)


value=v+256*u+65536*y



repeat
    poke(base1+4,value)
    poke(base2+4,value)
   
    draw_rect_filled( 0, 0, 150, 150, 1, 1, 1)
   
    sleep(100)
until 2==3


The picture posted below is taken from SX13IS with palette modified with script:

--[[
@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)
    paletteOp[p]=math.random(1,255)
end


repeat

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

    end
    sleep(100)
until 2==3


-------------
-------------


Interestingly, a good start!

Have you looked at the pallet after changes in other modes, is there any change or Canon still uses his pallets without any changes?

Interestingly, a good start!

Have you looked at the pallet after changes in other modes, is there any change or Canon still uses his pallets without any changes?

Unfortunately Canon firmware tries to overwrite the custom palette very often, that's why there's a repeat-until loop. But that's not big deal - if this will be incorporated to the CHDK the palette can be written to the memory every time the CHDK controls tasks (every 10ms).

Nevertheless, the palette can be changed in any mode. Doesn't matter. You could make your own color profile for Canon firmware menu;)

Ok, I got RGB now. With help of that site: http://www.pcmag.com/encyclopedia_term/0,1237,t=YUVRGB+conversion+formulas&i=55166,00.asp and a little bit experimenting I can draw any RGB color. Sample script attached (set parameters rgb and start).

--[[
@title palette tests

@param r R
@default r 0

@param g G
@default g 0

@param b B
@default b 0
--]]

set_console_layout(0,0,40,10)

base1 = 0xc0f14400
base2 = 0xc0f14800


function rgb_to_y(rv,gv,bv)
    yv = (299*rv + 587*gv + 114*bv) / 1000
    return(yv)
end

function rgb_to_u(rv,gv,bv)
    uv = (-147*rv - 289*gv + 436*bv) / 1000
    return(uv)
end

function rgb_to_v(rv,gv,bv)
    vv = (615*rv - 515*gv - 100*bv) / 1000
    return(vv)
end

function unsign(v)
    --    0 to 127   becomes   0-127
    -- -128 to  -1   becomes   128-255
    if v<0 then v=v+256 end
    return(v)
end

y = rgb_to_y(r,g,b)
u = rgb_to_u(r,g,b)
v = rgb_to_v(r,g,b)

us= unsign(u)
vs= unsign(v)

print("r:"..r.." g: "..g..  " b: "..b)
print("y:"..y.." u: "..u..  " v: "..v)
print("y:"..y.." us:"..us.. " vs:"..vs)


value=vs+256*us+65536*y

repeat
    poke(base1+4,value)
    poke(base2+4,value)
   
    draw_rect_filled( 0, 0, 150, 150, 1, 1, 1)
   
    sleep(100)
until 2==3


Keep in mind that different generation cameras (or perhaps just different models with different display hardware ?) have different palette systems.

Unfortunately Canon firmware tries to overwrite the custom palette very often, that's why there's a repeat-until loop. But that's not big deal - if this will be incorporated to the CHDK the palette can be written to the memory every time the CHDK controls tasks (every 10ms).

Actually, this is likely to lead to nasty flickering as CHDK and the Canon firmware fight over the palette, unless it is synchronized in a way that causes the CHDK one to always be present before the screen is actually updated.

Keep in mind that different generation cameras (or perhaps just different models with different display hardware ?) have different palette systems.

Sure. So unused palette places can be only used unfortunatelly. But this still gives you some possibilities you haven't before. Some cameras have no particular colors (from source code I remember that one camera has no any blue color for histo) - this way that could be fixed - just take a few useless colors:)

BTW - note the registers were taken directly from Magic Lantern site for E60 cam. They share exactly the same registers.

Quote

Unfortunately Canon firmware tries to overwrite the custom palette very often, that's why there's a repeat-until loop. But that's not big deal - if this will be incorporated to the CHDK the palette can be written to the memory every time the CHDK controls tasks (every 10ms).

Actually, this is likely to lead to nasty flickering as CHDK and the Canon firmware fight over the palette, unless it is synchronized in a way that causes the CHDK one to always be present before the screen is actually updated.

It's not so bad as I thought first - on the script above the loop runs every 100ms and no flickering is visible. Camera seems to rewrite the palette from time to time. I can observe this for example immediately after script turns off. Or when Canon menu is accesed while script is running you can see one flicker.

Sure. So unused palette places can be only used unfortunatelly.

Not different palette colors, different palette systems. E.g. digic II cameras using 16 AUYV values twice to make up the 8 bit palette.

Finding the unused colors on 100+ cameras is a different story...