When using quadratic output correction the light dims before fading

[corb3000]

Hi,
Thanks for the great Library, I am using it to add DMX onto Home assistant, incorporating the new Color Mode and using the 16 bit for smooth dimming at low level.

When using any output_correction other than linear. When a Fade starts, it will use the corrected value to start the fade then apply the correction again so the start of the fade is a lot lower value than the previous DMX value.

step to reproduce:

set: output_correction: quadratic
set: light to brightness 128
DMX value sent to Artnet is 64 due to quadratic correction
send fade to 200
the fade will start at an input value of 64 after quadratic correction it sends a DMX value of 18 is sent on Artnet instead of 64
the light will fade up from DMX value 18 to 155

Expected behavior light should fade from DMX value 64 to 155

impact: when fading up or down from a mid brightness the light dims significantly then fades to the correct value.

I have been looking at the code to see if there is an easy way to fix it but I'm still finding my way around it. If I find a solution I will let you know.

[corb3000]

My current thoughts on this:
I think the problem is at:
dmx_channel.py line 101
fade.val_start = self.__val_act_i[i]

self.__val_act_i[i] is the "output corrected" value. (see line 138)
maybe you need to have a separate array in DmxChannel to store the fade.val_current or fade.val_target at the end of the fade. Probably save fade.val_current in process() so it behaves well if the fade is canceled.

What do you think?

[spacemanspiff2007]

using the 16 bit for smooth dimming at low level.

What do you mean? The lib already does smooth dimming regardless of the channel width which represents the capability of the connected device.

What do you think?

I've pushed a new version. Could you test it, please?

[corb3000]

Thanks for that. the dimming is now working correctly.
but I have found a minor issue. with the maths:
the Maximum value should be (256 ^ number of bytes) -1
and not 255 ^ number of bytes

With Quadratic correction, this drives the output to be greater than 65,535 (0xFFFF). Causing the DMX outputs to go back to 0000

The fix I have tested (for Quadratic):

dmx_channel.pi line 13:
_CHANNEL_MAX: int = 256 ** _CHANNEL_SIZE -1

also:

class DmxChannel16Bit(DmxChannel):
_CHANNEL_SIZE: int = 2 # Channel size in byte
_CHANNEL_MAX: int = 256 ** _CHANNEL_SIZE -1

class DmxChannel24Bit(DmxChannel):
_CHANNEL_SIZE: int = 3 # Channel size in byte
_CHANNEL_MAX: int = 256 ** _CHANNEL_SIZE -1

class DmxChannel32Bit(DmxChannel):
_CHANNEL_SIZE: int = 4 # Channel size in byte
_CHANNEL_MAX: int = 256 ** _CHANNEL_SIZE -1

also for safety in output_correction.py:

def quadratic(val: float, max_val: int = 256 * 256 - 1):
return (val ** 2) / max_val

def cubic(val: float, max_val: int = 256 * 256 * 256 - 1):
return (val ** 3) / (max_val * max_val)

def quadruple(val: float, max_val: int = 256 * 256 * 256 * 256 - 1):
return (val ** 4) / (max_val * max_val * max_val)

[spacemanspiff2007]

Thanks for your feedback! I made more changes and pushed them again.
Could you test again?

[corb3000]

That looks good. I tested all the output correction modes and they work correctly.

Thanks.
Will you be pushing it to PYPI soon?

[spacemanspiff2007]

I just wanted to wait for your feedback - I'll push it now.