Brightness curve? #603
Replies: 5 comments 4 replies
-
|
Hi |
Beta Was this translation helpful? Give feedback.
-
I absolutely agree on this point. No need to create software "crutches". @jeroenterheerdt, the power supply should always be chosen by a normal manufacturer and with a small margin (at least about 15-20%). Don't skimp on these things. |
Beta Was this translation helpful? Give feedback.
-
|
This could not only be useful for broadening the adoption of hyperhdr but could also be used to cover other scenarios such as light sensitivity or reaction to certain bright colors.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Awawa ***@***.***>
Sent: Wednesday, July 19, 2023 5:40:33 AM
To: awawa-dev/HyperHDR ***@***.***>
Cc: Jeroen ter Heerdt ***@***.***>; Author ***@***.***>
Subject: Re: [awawa-dev/HyperHDR] Brightness curve? (Discussion #603)
Hi
I am definitely against solving hardware problems (too weak power supply) by software. One bug in the main application, accidental reset of user settings or breaking changes in the external&independent led driver and kaboom... just like in the last version of WLED due to changes in the NeopixelBus library.
[obraz]<https://user-images.githubusercontent.com/69086569/254574890-5d740945-da54-45cb-a5e1-8fb948b766bf.png>
—
Reply to this email directly, view it on GitHub<#603 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB6PIPRJEBJXL73QVVIHMKDXQ7IUDANCNFSM6AAAAAA2PKVRLA>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I don't think there is any other possible use for such a function. Note that we can't even do an initial calculation without knowing what physical LED type is used in the setup. For example: when HyperSerialESP32 or HyperSPI is used in HyperHDR it does not mean that we know that the user used ws2812b RGB or sk6812 RGBW and these LEDs have completely different electrical characteristics. And also the brightness (Luminance?) does not reflect the actual power consumption of the LEDs well, because it looks a bit different for each R/G/B channel component, and the use of an additional white channel W, which can also be freely calibrated by the user, makes these calculations impossible. Another aspect is the almost guaranteed blinking. |
Beta Was this translation helpful? Give feedback.
-
|
Wow, and here I am trying to help this open source software along by providing some ideas that could help the masses only to be lectured on picking the right power supply. Great going guys... Not.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Roman Astafev ***@***.***>
Sent: Friday, July 21, 2023 5:40:02 AM
To: awawa-dev/HyperHDR ***@***.***>
Cc: Jeroen ter Heerdt ***@***.***>; Mention ***@***.***>
Subject: Re: [awawa-dev/HyperHDR] Brightness curve? (Discussion #603)
I am definitely against solving hardware problems (too weak power supply)
I absolutely agree on this point. No need to create software "crutches".
This is still the safety of the user and an unreliable power supply can lead to very bad consequences.
Equipment failure or, even worse, heat and possible fire.
@jeroenterheerdt<https://github.com/jeroenterheerdt>, the power supply should always be chosen by a normal manufacturer and with a small margin (at least about 15-20%).
Don't skimp on these things.
—
Reply to this email directly, view it on GitHub<#603 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB6PIPWSY53GGFV6DGFIO3LXRJ2CFANCNFSM6AAAAAA2PKVRLA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
It has absolutely nothing to do with open source. It was explained to you that such a solution poses a risk to the user and is simply not possible to implement at the application level (if it is, rather at the level of the LED driver) |
Beta Was this translation helpful? Give feedback.
-
|
I was really surprised by your response. I read the whole thread and had to scroll back up to see what prompted it...am still looking. 🤷♂️ |
Beta Was this translation helpful? Give feedback.
-
|
whatever. the point is that you scolded a user who was trying to help you improve the software. Think about it like this: people with sensitivity to certain bright light will benefit from an ability to automatically dim the lights for certain colors (bright flashing patterns cause all kinds of problems with people). My suggestion was to add something that would allow the user to define the brightness on a color spectrum, much like the brightness curves in photo editing applications. Yes, it was caused by an original problem with my power supply (since resolved, I have you know), but that's not the point. The point is that the original thought and suggestion was dismissed and a user with a sincere suggestion to improve your software and make it more user friendly to a broader audience was told to 'go away'. Thanks for your awesome work on HyperHDR - I am happy to continue to use it. I was also willing to help with suggestions but since those are not welcomed this is the end of that road for me. |
Beta Was this translation helpful? Give feedback.
-
|
I have presented you factual arguments, I don't know why you take it personally. If you do not agree with the position and that someone's setup can go up in smoke in case of simply mistake using such feature and overload insufficient power supply, then you have the right to do so. We are protected by the MiT license anyway, but it does not mean that we will ignore such a risk, especially that we have been fighting hard for a long time against popular, but incorrect from the point of view of the LED spec, setups without 3.3V to 5V level shifters, in particular direct control of Neopixel LEDs via RPi's GPIO. So our position shouldn't surprise you at all. Trying to turn it into a different use-case, you ignore my next argument and that the dynamic brightness control, without knowing what type of LEDs the user uses, is not able to properly drive them and at most you can try to implement it in particular LED drivers. However, you do have LED drivers that offer such functionality and you can even use it now if you connect with HyperHDR to WLED (just please not WLED 0.14b3 for the reason mentioned in my first reply) using UDP or serial LED driver. So you can't say that such functionality would be something completely new. That's all from my side. Despite our differences of opinion, I hope you will continue to use our software. |
Beta Was this translation helpful? Give feedback.
-
Hyperhdr works fine, except when I have a all or almost white screen. My power supply is probably not powerful enough to handle that white. I can resolve it by turning brightness down but then of course everything is dimmed. So, that got me thinking... Is there a brightness curve? Something like: if all rgb values above 250 (I.e., almost white) turn brightness down to a level that my power supply can handle. If below threshold keep normal brightness. Obviously this is hard cut off that I am using as the example here. I'm thinking in line with what you see in photo editing apps.
I haven't found how to do this using the current options but maybe it's there. I tried changing the white calibration as well as brightness but neither brought the result I was looking for.
Beta Was this translation helpful? Give feedback.
All reactions