Edit brightness

ProffieOS
1

Hi guys,

I was wondering if it would be possible to make or have an “edit brightness menu” similar in function to “volume menu” or that would work globally on all presets at once even if a blade style doesn’t have EFFECT_POWERSAVE in it’s style with 10 increments from 100% to 10%.

I often play with my saber at night and find the blade too bright.

Or does this exists already but I didn’t “unlock” it yet ?
I am using fett263’s prop.

Any help appreciated.
MTFBWY

2

“Edit Brightness” is already available in Edit Mode. It’s a different (and separate) function from EFFECT_POWERSAVE.

EFFECT_POWERSAVE requires each style contain a powersave layer to work and is “temporary” while preset is active.

“Edit Brightness” automatically dims or brightens all blades universally in a preset via the Edit Settings menu in Edit Mode and saves like other editing functions.

Info on Edit Mode here:

3

Since my wife and son both have light sensitive migraines, I’ve been using this feature (and previous work arounds) for a while.

The only problem is color distorition as you drop in brightness, but that is supposed to be compensated for by the color gamma define in OS8 if I’m not mistaken. I haven’t given that a try yet, and would be interested in your observations if you go that route.

I have my brightness and volume set in the mid-range at all times through the Fett263 prop, so I have room to go up or down and don’t hurt or disturb the family :slight_smile:

I’ve actually been thinking about about how Proffie offers these incredible accessibility features, and if and how that should be a point that’s made. Like and “Accessibility Feature” page in the POD or some such.

If you reduce edit mode to just the settings menu only, brightness is still there.

4

You could use the array selector in the sabersense prop file to have two or more blade arrays, all looking at the same preset array, but set to lower brightness levels using dimblade. An example blade array is below.

To change brightness, you would just triple-click POWER and the system will switch to the next blade array but stay on the same font with the same blade style, just at the new brightness level.

You can have as many blade arrays as you like, so you could maybe set one for 100 percent, one for 50 percent, one for 25 percent and one for 10 percent. And you can cycle forwards or backwards through the list by pointing the hilt up or down respectively.

BladeConfig blades[] = {
  { 0,  // Full Brightness.
//  Main Blade:
 	WS281XBladePtr<132, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3>>(),
//  Crystal Chamber:
    WS281XBladePtr<1, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin5>>(),
   CONFIGARRAY(presets) },

  { 1,  // 50 percent brightness.
//  Main Blade:
 	DimBlade(50.0, WS281XBladePtr<132, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3>>(),
//  Crystal Chamber:
    DimBlade(50.0, WS281XBladePtr<1, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin5>>(),
   CONFIGARRAY(presets) },

  { 2,  // 25 percent brightness.
//  Main Blade:
 	DimBlade(25.0, WS281XBladePtr<132, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3>>(),
//  Crystal Chamber:
    DimBlade(25.0, WS281XBladePtr<1, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin5>>(),
   CONFIGARRAY(presets) },

  { 3,  // 10 percent brightness.
//  Main Blade:
 	DimBlade(10.0, WS281XBladePtr<132, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3>>(),
//  Crystal Chamber:
    DimBlade(10.0, WS281XBladePtr<1, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin5>>(),
   CONFIGARRAY(presets) },

};
#endif
5

There should not be any color distortion, as color is reduced linearly. Although eyes don’t perceive colors entirely linearly, so maybe that’s why?

The gamma define only affects the menu itself, it does not change how the dimming is actually done.

1 Like
6

Assuming the neopixel luminance response is linear (or at least proportional to each other channel) with the control values, which is unlikely.

1 Like
7

They are linear, with caveats.

  • They use PWM to vary the brightness, and PWM by itself doesn’t have any of the weird non-linear issues that current control does.
  • They are designed to have a linear response, so 20 is supposed to be twice as bright as 10. (In lumens, not in perceived brightness.)

There are however a host of reasons why the color may change anyways:

  1. low battery - we operate our pixels right at the limit of what works well, and when the voltage is low, some colors drop out faster than others, changing the color. This can also happen with weak cables, or anything else that restricts the available power/voltage.
  2. RGBW phosphor excitation - This is actually a linear effect that happens in some RGBW pixels. Basically, the blue LEDs end up activating the phosphors for the “W” part of the RGBW pixel, which ends up washing out the colors and make it more of a light blue. I think this is still a linear effect, but I’m not actually sure if the phosphor has a linear response or not. (The sRGB-gamma-2.2 curve originates with the phosphors on the inside of the glass in a TV after all.)
  3. Perception - our eyes do not have linear response, so twice as bright in lumens doesn’t actually look twice as bright to us. Also, strong light tends to activate cones of different colors in our eyes, which causes strong light to not look as saturated as dimmer colors.
  4. overflows in the code - This happens a lot in computers, games and photography, so why should ProffieOS be any different? Basically, you start with a color, try to make it even stronger, and as you hit the limit, the color can change. Lets say you start with 100,10,10, which is red. Now multiply that by 1000000 and you get 255,255,255, which is of course white. Another common one you start with an orange color, and the clipping makes it yelllow, which can be very noticable in some cases.
  5. … and probably a few more that I can’t think of right now…
4 Likes
8

That’s good to hear. I can’t say I am interested, at the moment, in a temporary EFFECT_POWERSAVE unless it could be made “permanent” or “remembered” (via SAVE_STATE). I want a set it and forget it until the light changes and then I change it again.

I was using #define MENU_SPEC_TEMPLATE FETT263_MENU_SPEC for learning and testing purposes. Didn’t find edit brightness in it. In fact I had a few issues with it: many sounds were not “spoken”, it was just blank, then I heard (and I am not sure witch but something like) “copy preset” or “delete preset”, I then clicked AUX and heard “exit”, twisted the saber a bit but heard nothing so I clicked AUX again and hear “exit” a second time, the next AUX push changed the preset.

At some point I also heard “error in font directory” on repeat (somewhere between 5-10 times in a row). Now I know what you might say, but my common folder is complete with ProffieOS_V2_Voicepack_Din_Djarin + the older files from ProffieOS_Voicepack_Din_Djarin (V1 voicepack) + more files that I feel should be there rather than in font + some “general” *.bmp for OLED.

The “error in font directory” disappeared when I changed this in your code:
From

void Setup() override {
  RestoreGestureState();
#ifndef MENU_SPEC_TEMPLATE
#ifdef MOUNT_SD_SETTING
  sound_library_v2.init();
#else
  sound_library_.init();
#endif
#endif
  }

to

 void Setup() override {
  RestoreGestureState();
  sound_library_.init();
  sound_library_v2.init();
  }

Also tried:

 void Setup() override {
  RestoreGestureState();
  sound_library_.init();
#ifdef MOUNT_SD_SETTING
  sound_library_v2.init();
#endif
}

but it had no effect on memory usage. MENU_SPEC_TEMPLATE FETT263_MENU_SPEC also uses 3360 bytes more than FETT263_EDIT_MODE_MENU.
I can’t see where MENU_SPEC_TEMPLATE FETT263_MENU_SPEC initialize sound_library_->init(); and/or sound_library_v2->init();

I don’t know if your prop supports MENU_SPEC_TEMPLATE DefaultMenuSpec or MENUS_SPEC_TEMPLATE SettingsOnlyMenuSpec because I didn’t try them with your prop yet?

I do know that prop_base.h has this:

#ifdef MENU_SPEC_TEMPLATE
    MKSPEC<MENU_SPEC_TEMPLATE>::SoundLibrary::init();
#endif

but I don’t know how it applies to your prop since you have “override” in your void Setup().

@profezzorn what does void Setup() override in a prop “overrides”, only asking because I didn’t find any Setup in prop_base.

Back to the subject of Brightness, with FETT263_EDIT_MODE_MENU, it works as I was hoping. Thank you.

I am not noticing any color distortion
I have not tried that color gamma either because I am not sure I understand what it is supposed to do ? Or if I am even going to notice a difference.

Thanks Chris, unfortunately I am already using blade arrays for my multi_prop. I don’t think combining your prop with mine would work without some serious re-work in my prop. Plus I like the idea of having 10 level of brightness available but having 10 blade arrays just dedicated to brightness would probably take valuable preset space.

Thank you all for your replies. Sorry it took me so long to respond. I had to do a few tests to make sure my answers where as accurate as possible.

I can’t understand what MENU_SPEC_TEMPLATE FETT263_MENU_SPEC brings more than FETT263_EDIT_MODE_MENU ? As described above, I don’t think MENU_SPEC_TEMPLATE FETT263_MENU_SPEC works as it is supposed to, specially the voice prompts that don’t play when expected. Voice prompts works perfectly with FETT263_EDIT_MODE_MENU.

1 Like
9

This is an OS8 addition, so it still needs a good amount of testing. I would post in the Beta thread. We’ll need @profezzorn to help as the MENU_SPEC_TEMPLATE is a different system from Edit Mode, I only barely understood it enough to add to my prop (with a lot of help), I did a cursory test but it still needs a deeper dive from users so this is probably a good start.

EFFECT_POWERSAVE was an OS5 feature, it was a first attempt at controlling brightness. The Edit Brightness is a much better approach. While EFFECT_POWERSAVE works it’s a bit obsolete, I still support in the library but Edit Brightness would be the way to go moving forward IMO.

10

Good to know. I will remove all EFFECT_POWERSAVE from my few presets that have it. Yes I agree Edit Brightness is the way to go. It works perfectly.

I do believe that your FETT263_MENU_SPEC doesn’t just needs testing but also needs some work. I will stick to FETT263_EDIT_MODE_MENU for now. But I don’t mind testing when a new update comes.

11

Beta testing is what will allow this to happen :wink:

12

Does your common folder have a voicepack.ini file with version=2 in it?

13

Yes it does.