Custom Colors : standardizing a semi-transparent grey

ADamb

65
sx200is

Re: Custom Colors : standardizing a semi-transparent grey

« Reply #80 on: 30 / October / 2014, 04:50:50 »

Advertisements

Small changes on sx200is, but these can easily be ported to others:
1. Moved custom color definitions to platform_camera.h (could be platform_palette.h instead)
2. Used memcpy for palette owerwriting.
I think, that custom color definitions could be used globally, there are only 2 variations present.
In my case it gives MEMISOSIZE decrease by 96 bytes.

sx200is_pal_memcpy.patch (3.34 kB - downloaded 20 times.)

Logged

SX200 IS-100C

philmoz

3407

Re: Custom Colors : standardizing a semi-transparent grey

« Reply #81 on: 30 / October / 2014, 05:11:55 »

Quote from: ADamb on 30 / October / 2014, 04:50:50

Small changes on sx200is, but these can easily be ported to others:
1. Moved custom color definitions to platform_camera.h (could be platform_palette.h instead)
2. Used memcpy for palette owerwriting.
I think, that custom color definitions could be used globally, there are only 2 variations present.
In my case it gives MEMISOSIZE decrease by 96 bytes.

Using memcpy forces the palette entries to be sequential, so far in all the implementations this has been the case; but it doesn't have to be. I don't have a problem if you want to implement it this way though.

I'm not sure CHDK_COLOR_ENTRIES belongs in a header file - it is only ever used in lib.c, and doesn't need to be visible anywhere else. I'd probably just put the values directly in the array in lib.c.

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)

ADamb

65
sx200is

Re: Custom Colors : standardizing a semi-transparent grey

« Reply #82 on: 30 / October / 2014, 10:37:34 »

I think it would be good to define colors globally (as far as I know, there are only 2 types of custom colors).

Logged

SX200 IS-100C

waterwingz

12122

Re: Custom Colors : standardizing a semi-transparent grey

« Reply #83 on: 30 / October / 2014, 11:08:06 »

Quote from: ADamb on 30 / October / 2014, 10:37:34

(as far as I know, there are only 2 types of custom colors).

So far. Canon tends to change things on a regular basis. And they don't notify us.

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3407

Re: Custom Colors : standardizing a semi-transparent grey

« Reply #84 on: 30 / October / 2014, 15:31:09 »

Quote from: ADamb on 30 / October / 2014, 10:37:34

I think it would be good to define colors globally (as far as I know, there are only 2 types of custom colors).

That may be true; but it could also change in the future.

Assumptions like this is how we ended up with the CAM_BITMAP_PALETTE mess we are trying to clean up now.

Edit: Another consideration - the reason there are only two sets of custom color values is because they were copied from port to port. They are not necessarily the best values for any given camera; but they work so no-one has seen any need to fine tune them for a particular camera (yet).

Phil.

« Last Edit: 30 / October / 2014, 17:21:05 by philmoz »

Logged

rudi

128
A590IS_101B, SX260HS_100B

Re: Custom Colors : standardizing a semi-transparent grey

« Reply #85 on: 31 / October / 2014, 16:17:14 »

Quote from: srsa_4c on 29 / October / 2014, 20:04:14

A potential improvement (for non-custom-palette ports) would be to use colors according to the current operating mode (play/rec), but this would probably require a lot of editing work and easily cause regressions...

My favorite is a simpler color handling for CHDK. Expand the module color concept to complete CHDK. We don't need the full canon color palette. A palette (currently 19) with platform comparable colors are enough for CHDK.
We set two camera selective tables for PLAY and REC width indexes of canon color palette (already exists). A variable chdk_colors store the address of mode selective CHDK color table. Using return value form get_mode in main task loop (main.c) for that:

Code: [Select]

chdk_colors = get_mode? &CHDK_COLOR_TAB_REC : &CHDK_COLOR_TAB_PLAY;

Define macro for CHDK colors equal to

Code: [Select]

#define CHDK_COLOR_... ( [chdk_colors + 0..18] )

As result CHDK_COLOR_... returns always the right and mode selective canon color index. We don't need anymore a mode selection in draw commands, like

Code: [Select]

is_rec_mode? COLOR_REC : COLOR_PLAYMAKE_COLOR macro should be no problem. User defined colors are not affected.
The OSD color selector need to rewrite for smaller palette.

Logged

waterwingz

12122

Re: Custom Colors : standardizing a semi-transparent grey

« Reply #86 on: 31 / October / 2014, 16:31:34 »

Quote from: rudi on 31 / October / 2014, 16:17:14

My favorite is a simpler color handling for CHDK. Expand the module color concept to complete CHDK. We don't need the full canon color palette. A palette (currently 19) with platform comparable colors are enough for CHDK.
We set two camera selective tables for PLAY and REC width indexes of canon color palette (already exists). A variable chdk_colors store the address of mode selective CHDK color table. Using return value form get_mode in main task loop (main.c) for that:
Code: [Select]
chdk_colors = get_mode? &CHDK_COLOR_TAB_REC : &CHDK_COLOR_TAB_PLAY;Define macro for CHDK colors equal to
Code: [Select]
#define CHDK_COLOR_... ( [chdk_colors + 0..18] )As result CHDK_COLOR_... returns always the right and mode selective canon color index. We don't need anymore a mode selection in draw commands, like
Code: [Select]
is_rec_mode? COLOR_REC : COLOR_PLAYMAKE_COLOR macro should be no problem. User defined colors are not affected.
The OSD color selector need to rewrite for smaller palette.

I actually wrote and tested a patch that does almost exactly this earlier this week. It works pretty well and is backwards compatible - older ports can continue to use #define COLOR_RED 0x2D while newer ones use something like #define COLOR_RED palette[pal_mode][14]. It required getting rid of explicit initialized values for the various color arrays (as those needed use constants) but adding initialzer functions (e.g. init_module_colors()) covered that.

But this quickly got me to realizing that for the A560 I needed to define something like 56 different color values ( play & rec for the standard, icon, histogram etc ) and lost interest at that point.

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3407

Re: Custom Colors : standardizing a semi-transparent grey

« Reply #87 on: 31 / October / 2014, 19:08:24 »

Quote from: philmoz on 30 / October / 2014, 04:12:43

Small update to previous patch.

Moves the CHDK_COLOR_BASE and COLOR_GREY_DK_TRANS values from the platform_camera.h files to the platform_palette.h files.

If there are no issues, I'll add this to SVN over the weekend.

Phil.

Added in revision 3706.

Phil.

Logged

philmoz

3407

Re: Custom Colors : standardizing a semi-transparent grey

« Reply #88 on: 31 / October / 2014, 19:46:25 »

Quote from: rudi on 31 / October / 2014, 16:17:14

Quote from: srsa_4c on 29 / October / 2014, 20:04:14
A potential improvement (for non-custom-palette ports) would be to use colors according to the current operating mode (play/rec), but this would probably require a lot of editing work and easily cause regressions...
My favorite is a simpler color handling for CHDK. Expand the module color concept to complete CHDK. We don't need the full canon color palette. A palette (currently 19) with platform comparable colors are enough for CHDK.
We set two camera selective tables for PLAY and REC width indexes of canon color palette (already exists). A variable chdk_colors store the address of mode selective CHDK color table. Using return value form get_mode in main task loop (main.c) for that:
Code: [Select]
chdk_colors = get_mode? &CHDK_COLOR_TAB_REC : &CHDK_COLOR_TAB_PLAY;Define macro for CHDK colors equal to
Code: [Select]
#define CHDK_COLOR_... ( [chdk_colors + 0..18] )As result CHDK_COLOR_... returns always the right and mode selective canon color index. We don't need anymore a mode selection in draw commands, like
Code: [Select]
is_rec_mode? COLOR_REC : COLOR_PLAYMAKE_COLOR macro should be no problem. User defined colors are not affected.
The OSD color selector need to rewrite for smaller palette.

Thanks rudi.

This is similar to what I've played with in the past; but the tricky part is the user adjustable colors stored in the conf structure (e.g. conf.menu_color). This is where I got stuck previously.

The user adjustable colors are stored as two Canon color values (background & foreground) - once set they no longer get adjusted as the mode changes. They are the output of the MAKE_COLOR macro so are fixed values.

Ideally the user should be able to select colors that adjust for mode on the fly, or fixed Canon colors if they prefer. We need some way of handling this for the conf colors.

Phil.

Logged

rudi

128
A590IS_101B, SX260HS_100B

Re: Custom Colors : standardizing a semi-transparent grey

« Reply #89 on: 01 / November / 2014, 13:51:49 »

Quote from: philmoz on 31 / October / 2014, 19:46:25

The user adjustable colors are stored as two Canon color values (background & foreground) - once set they no longer get adjusted as the mode changes. They are the output of the MAKE_COLOR macro so are fixed values.

Ideally the user should be able to select colors that adjust for mode on the fly, or fixed Canon colors if they prefer. We need some way of handling this for the conf colors.

Phil.

I understand. conf.menu_color need fix values. We use an index of chdk colors for that:

Code: [Select]

#define CHDK_COLOR_... ( 0..18 )

For safety split type color to type color for canon palette colors and for chdk colors. The previous color macros works now only for chdk colors:

Code: [Select]

//index of fg or bg
typedef unsigned char   chdk_color_id;
//mixed fg_index and bg_index
typedef unsigned short  chdk_color;
 
#define MAKE_CHDK_COLOR(bg, fg)  ((chdk_color)((((chdk_color_id)(bg))<<8)|((chdk_color_id)(fg))))
#define FG_COLOR_ID(bgfg)     ((chdk_color_id)(bgfg & 0xFF))
#define BG_COLOR_ID(bgfg)     ((chdk_color_id)(bgfg >> 8))

Building drawing colors required always function make_color() or make_color_bg(). A function should be better for integrate in module part.

Code: [Select]

color function make_color_bf(chdk_color_id bg, chdk_color_id fg) {
 return ([chdk_colors + bg]<<8)|[chdk_colors + fg];
}

color function make_color(chdk_color bgfg) {
 return make_color_bg(BG_COLOR_ID(bgfg), FG_COLOR_ID(bgfg));
}

I use an other concept on rewriting gps part (new: single task and splitting drawings as preparing for module building):

Code: [Select]

//use script_colors[NUM_SCRIPT_COLORS][2] from gui_draw.c
#define GPS_COLOR( x )  ( script_colors [( x )][camera_info.state.mode_rec] )

enum {
    GPS_COLOR_TRANSPARENT,
    GPS_COLOR_BLACK,
    GPS_COLOR_WHITE,
    GPS_COLOR_RED,
    GPS_COLOR_RED_DK,
    GPS_COLOR_RED_LT,
    GPS_COLOR_GREEN,
    GPS_COLOR_GREEN_DK,
    GPS_COLOR_GREEN_LT,
    GPS_COLOR_BLUE,
    GPS_COLOR_BLUE_DK,
    GPS_COLOR_BLUE_LT,
    GPS_COLOR_GREY,
    GPS_COLOR_GREY_DK,
    GPS_COLOR_GREY_LT,
    GPS_COLOR_YELLOW,
    GPS_COLOR_YELLOW_DK,
    GPS_COLOR_YELLOW_LT,
    GPS_COLOR_GRAY_DK_TRANS,
} gps_colors;

using:

Code: [Select]

compass.col2 = MAKE_COLOR(GPS_COLOR(GPS_COLOR_BLACK), GPS_COLOR(GPS_COLOR_BLACK));
questions:
- Why named COLOR_GRAY_DK_TRANS? The now used color value is LT_TRANS.
- Why we not also replace the ICON and HISTO color constants with defined colors?

rudi

Logged