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
Quote from: outslider on 14 / July / 2012, 11:22:17As 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.QuoteEngDrvOut = kind of poke?Yes, the function writes a 32bit value into a DIGIC register (0xc0xxxxxx), and also saves that value into a RAM location.Quotedo 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.
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.
--[[@title palette tests--]]base1 = 0xc0f14400base2 = 0xc0f14800paletteY={}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)endrepeat 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]
--[[@title palette tests@param s start@default s 0@range s 0 255@param e end@default e 255@range e 0 255--]]base1 = 0xc0f14400base2 = 0xc0f14800paletteY={}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)endrepeat 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--------------------------
Quote from: waterwingz on 13 / July / 2012, 18:18:29This 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 modeFor simplicity my solution assumes you can find a common block of colors to overwrite.Phil.
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.
Quote from: philmoz on 13 / July / 2012, 19:43:53Quote from: waterwingz on 13 / July / 2012, 18:18:29This 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 modeFor 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.
Quote from: philmoz on 22 / March / 2013, 22:22:26Sounds 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 ?QuoteAlternatively 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 ?
Looking at the palette definitions in the firmware shows it uses the values 0, 1f, 2f and 3f instead of 0, 1, 2 & 3.
Started by cosmograph General Discussion and Assistance
Started by KaLi General Help and Assistance on using CHDK stable releases
Started by HarpoMa General Discussion and Assistance
Started by outslider General Discussion and Assistance
Started by pwcal2 Feature Requests
