Seems like there are two choice to implement this:
- Blindly add COLOR_TRANS_GREY to the custom color array and wait for anybody with one of the 47 custom palette enabled cameras to notice any whacky Canon colors. Not a big risk - no crashes, just funny colors. We fix anything found by either moving the patched array or changing it to #define COLOR_TRANS_GREY COLOR_GREY_LT (which the other 60+ cameras will be using anyway).
- Add the extra custom color only to cameras that can be tested. The rest just get #define COLOR_TRANS_GREY COLOR_GREY_LT
Once this is implemented, OSD text can use a semi-transparent background in both playback & shooting modes. And script can safely use the tranparent background too. MIght be nice to use it for the console background too.
Is this meant to replace the background color for text based OSD elements?
If so then defaulting to COLOR_GREY_LT will not work - the current OSD defaults are WHITE on DARK GREY.
WHITE on LIGHT GREY will look strange
Also, I think this needs to be a transparent medium to dark grey for cameras that will support it, to still allow for reasonable contrast for the white text against a light image.
For an initial implementation I'm thinking:
- add a new entry in 'load_chdk_palette' on a case by case basis (not big bang)
- define COLOR_GREY_DK_TRANS in the relevant platform_camera.h file as (CHDK_COLOR_BASE+13)
- if COLOR_GREY_DK_TRANS is not defined in palette.h after all the palette definitions set it to COLOR_GREY_DK
- add the necessary COLOR_ICON_xxx entries in palette.h and add it to script_colors
- update drawings.lua
This is a bit messy as it creates palette entries in the platform_camera.h file, not centralised in palette.h.
If we end up adding it to all cameras with custom palettes then this can be cleaned up.
Phil.