New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow webcam sleep duration to be set in config #91
base: main
Are you sure you want to change the base?
Conversation
Thanks for the PR! You are totally right that the blinking LED is a concern (and was since the beginning...). There probably is a battery life aspect to it too, in addition to the LED annoyance (because If you don't mind, I'd like to ask you a few questions, simply because I don't know many users of
Many thanks in advance 馃檪 |
Sure!
I started with 10000ms but I found the delay to be a bit annoying so I switched to 5000ms. I also tried 3000ms which performed pretty much the same as 2000ms
Since I opened this PR. 馃槂 I only started using the app full time after I got the changes working.
Sometimes it can be a bit finicky (eg. If I move and the camera points directly at a white wall, it will move from dim to normal) but it seems to be happening less and less so I suspect that more training might help?
I tried I'm kinda getting used to the LED now, so I am going to keep using Regards, |
Thanks for the answers! Please share an update as you keep using The current value of 2s is not any special value produced by some golden rule, it was basically @cyrinux trying out different values and using the app for days and weeks, to see what feels best, in terms of LED annoyance vs reaction on environment change. There's no correct answer, but I'm very curious to collect feedbacks from actual users of |
Wow, great job! This PR will give me the opportunity to completely ditch the bulky @maximbaz you asked for feedback, for the last 2 month I have been using clight with this timeouts (sec):
The first two values are day/night, what the last one is not so important. I think in the case of |
That is a great feedback, many thanks for sharing! Could you elaborate on what makes it useful to have
The one reason why calibrating often could be important: because it can mess up the training data. Here's one example to illustrate: Imagine it is night time, you are sitting in a well-illuminated room, wluma keeps your screen bright, exactly as you like it. It's time to turn off the lights, you are suddenly sitting with your laptop in the darkness. wluma is already trained well, it knows you want a lower brightness, but it will only react once the new "ALS" value shows up. If your timeout is set for a few seconds, it is okay to wait those few seconds for wluma to finally react, you eyes have probably not adapted to darkness yet anyway. Now, if there is 5 minutes to wait, you might desperately want to reduce the brightness by hand. If you just do it (as opposed to e.g. restarting wluma), you will register a new training datapoint: "I want low brightness value during bright surroundings" (because wluma still thinks it's bright around!). From now on, when you are in bright conditions, wluma will incorrectly be dimming your screen. |
Some feedback: I have been using wluma with I basically never change the brightness manually any more and I'm kind of used to the flashing LED now. I'm going to try the Regarding the ability to set different sleep durations for AC and battery, Im going to try find a way to measure the power impact of different sleep durations and if I find any difference I would like to try add this. I do love to optimise 馃槀 @maximbaz do you think there would be any benefit in combining I use I might be misunderstanding how I am also curious about whether implementing gamma control is an option, it would be nice to just use I really really like this app, I've been looking for something like it for a long time so thank you so much for all your hard work! |
Just out of curiosity, how do you plan on using |
I can't envision fully yet what you have in mind, or we might be understanding To give you an intuition behind It's basically to say "at 12:00 it's usually bright around me, at 17:00 it begins to be dim, and at 21:00 I turn off the lights, and I want wluma to react accordingly", so you configure those thresholds to let wluma think that it's bright between 12-17, dim between 17-21 and dark in the rest of the day.
I always want for people to have a great experience out of the box, so in this particular case, I'm still not 100% decided because:
I've been thinking about it so many times 馃槄 But every time I abandon the idea, as it's not as intuitive for me yet how that could work, color temperature probably shouldn't change with screen contents, some people like you and me accept a smooth curve based on sunrise/sunset time, @name-snrl probably uses |
I've a smaller timeout during the daytime because light levels change more frequently during the day than at night.
Hm... Yeah, that reasonable. But, I think we could solve this by forcing a light level check immediately after manually changing the brightness, but before |
It's definitely better but not ideal, the training likely should not have been needed in that case (if only wluma knew the real ALS values, it would have predicted the best values anyway), and there is a downside to overfitting the model with a lot of training points around similar values (it becomes very "jumpy" when it has too much data around "similar" environments). The LED is a privacy indicator, and with |
Here are the features I need:
I used to use only |
Yeah, I'm trying to turn wluma into clight. Maybe I should just stay with the combination of |
It's not that I'm against this idea in any way, I'm trying to better understand the pains and motivations behind how people use this. For example, is LED a real deal breaker, or rather an annoyance that you get used to in a weeks time? Is LED perhaps irrelevant at all, but instead it is undesirable that screen brightness changes too frequently, as opposed to only every 5 minutes? Is it that it's just very hard to capture your internal algorithm of how to pick an ideal brightness level, for whatever reasons, and that's why you would rather have "obvious automated corrections" and a control to fine-tune things whenever you like? 馃檪 |
we'll find out in a week :D
no, it's not a problem |
Okay I read the code and I realized it does not work how I thought it did 馃槅 Honestly I agree about this PR being kinda pointless, I think upping the sleep duration to 3-4 seconds might be a good idea, but honestly, there isn't much difference. I found out it is possible to disable the LED on some webcams. I can't remember where I read about it but I used the following to list my webcams controls: v4l2-ctl -d /dev/video0 --all I think it needs to have the I have been trying out |
Ahh I see. Regarding number 3, I am attempting to add this in. @maximbaz I'll open a new issue for this 馃憤 |
My laptop has a webcam activity LED and I got annoyed with it flashing every 2 seconds.
This allows setting the delay between steps instead of using the
WAITING_SLEEP_MS
constant. If it is not set or a value <MIN_WAITING_SLEEP_MS
is passed,WAITING_SLEEP_MS
is used as a default.I used 1000ms for
MIN_WAITING_SLEEP_MS
, not sure if its even needed but I assume no one wants to use less than that...An example:
I added tests for no custom value, an invalid custom value and a valid custom value in which I am passing
0
as thevideo
parameter in theWebcam
constructor, let me know if this needs to change.This is my first time working with Rust, so any feedback/improvements would be appreciated 馃槃