Comments (29)
Hi, thanks for this feature request!
As you can see here Clightd is already attempting to disable some camera features (eg: auto white balance).
Reading here, it seems like V4L2_CID_AUTOGAIN should be set for both automatic gain and exposure control. Clightd already set it to false where available.
May be we need to set V4L2_CID_CHROMA_AGC too?
EDIT: given that test is quite simple (just copy/paste a "memset..... state.quit = 0; }" block and change ctrl.id to V4L2_CID_CHROMA_AGC), are you willing to check if it works for you? Thanks!
from clightd.
With Clightd disabling auto exposure, and resetting absolute exposure to defaults, there doesn't appear to be any way to compensate for the incredibly low default exposure value on my camera (I get an ambient of 0.086 in a room with low incandescent illumination - the camera captures an almost black image).
I suspect that exposure needs to be configurable somehow, if Clightd is going to overwrite it.
from clightd.
No problem!
It is more complicated because unfortunately every webcam has its own imaging settings, and thus one has to adapt to them!
Thanks for testing this out btw :)
from clightd.
"sis" is Capture method's signature in dbus; it means Capture will take an extra "string" parameter with desired parameters.
Is this something that would be written into the clight.conf?
Yes, there would be an additional "capture_settings" in clight.conf that will be passed to Clightd when calling Capture.
I'd really like to avoid adding a conf file to clightd itself!
from clightd.
Calling with empty string as parameters yields the same results as before (sets to automatic aperture)
busctl call org.clightd.clightd /org/clightd/clightd/Sensor org.clightd.clightd.Sensor Capture "sis" "" 5 ""
from clightd.
Great!
Btw this will soon appear on libmodule5 branch, that will become master branch as soon as libmodule 5.0.0 is released (and yes, i made quite a nice mess this time with inter-dependencies between libmodule and clight/clightd, because of the port of clight to libmodule together with libmodule API break...)
from clightd.
I will try that as soon as possible! 😉 However, it seems to me that this issue is not exactly caused by the auto-exposure itself; rather, it should be the result of some cached settings persisting after using auto-exposure (by apps other than clight). I guess that if clight reset a constant exposure before any new captures, this problem could be solved. But I have no idea if that's possible. 😆
from clightd.
I guess that if clight reset a constant exposure before any new captures, this problem could be solved
That would make sense :) But then again, Clight would change some settings (that eventually get cached). What happens if you then use a webcam application, eg: skype, that does not reset its own default values?
We'd have clight that makes another application captures ugly.
Thus, I'd prefer to avoid this solution as much as possible!
from clightd.
I guess that if clight reset a constant exposure before any new captures, this problem could be solved. But I have no idea if that's possible.
Yeah I agree, this is indeed a clumsy solution. 😆
from clightd.
I've noticed that (at least on my laptop) auto-exposure tends to counteract the light that clight picks up from the screen itself
from clightd.
I've noticed that (at least on my laptop) auto-exposure tends to counteract the light that clight picks up from the screen itself
If i understand correctly, this is a positive fact, right?
Do you mean it should be enabled by clightd?
from clightd.
On the second thought this should really be a new issue given that what's relevant to this one is just a minor workaround
from clightd.
Moved issue to Clightd.
I'm currently having a look at this; i could reproduce it and i already fixed it disabling auto exposure.
But it seems that by doing so, my camera gets too dark (always around 0.25 in my room, during the afternoon).
from clightd.
Latest couple of commits should address this issue (commit: 33d0ac4).
@bryango
Let me know if this works fine for you!
from clightd.
Hi!
Thanks for your feedback. I was having the same issue indeed (i thought it could be an issue with my driver).
I will probably fallback to enabling automatic exposure as it worked better, until i find a better solution.
from clightd.
I am now letting exposure be automatically managed by cameras. This should fiy @pdf issue while still fix this issue (that was just referring to "reset a fixed state for Clightd captures").
Let me know if any other issue arises!
from clightd.
It's certainly a lot better for my camera now. It would be nice to have some sort of simple scaling factor for the measurement result though, as my camera measurements still end up on the low side.
from clightd.
What do you mean with simple scaling factor? Are you using Clightd standalone or in conjunction with Clight?
If latter, Clight does support "backlight curves" where you can specify 11 points to create your very own ambient_brightness -> backlight curve: https://github.com/FedeDP/Clight/wiki/Config#polynomial-fit.
from clightd.
Ah, I see... a little more complicated, but I'll try working with that. Sorry for the noise.
from clightd.
I consider this issue closed: now clightd will properly reset to a well-known state before attempting a capture.
Default state means that any imaging-changing option will be set to webcam default value, and exposure will be set to "automatic aperture".
from clightd.
exposure will be set to "automatic aperture"
Hi. This breaks usage with my laptop integrated webcam. The camera raises exposure until the average is add a certain level. Clightd uses the average of the camera and therefore it is always around 0.4 ambient brightness.
Until now I just changed automatic aperture
to manual
and it worked fine. Now the settings are being reset to automatic aperture
leads to having the 0.4 ambient brightness.
Can we make the exposure setting configurable somehow? I'm sure this is not required for every device and I agree a default should be set that work with most hardware. But sometimes we have special hardware (mine is a very common Dell Latitude) that needs tweakable settings.
What do you think?
from clightd.
Hi! Thanks for reporting here your issue!
I think it is not a bad idea to let users someway customize camera settings.
I am just wondering whether to implement a conf file for Clightd or adding a new parameter to "Capture" method interface to pass camera settings through dbus.
I like the latter approach as it gives clients the freedom to set camera settings, while the former would lead to Clightd forcing camera settings for any Capture
call.
The Clighd conf file approach is much easier though.
I will think about it; if you have any input feel free to contribute :)
EDIT: i am thinking about something like this:
Capture "sis" "/dev/video0" 5 "Exposure=automatic,Foo=Bar,..."
The only downside is that these are Sensor-specific (webcam) settings, that are useless for ALS devices.
from clightd.
Wow, your response times are incredible. Thank you for your high motivation on this!
Your posted example looks quite flexible, even if I don't know what sis
is. Is this something that would be written into the clight.conf? It would fit in there because most of the other settings do indirectly relate to the used hardware (the ambient light -> brightness mapping, for example) so adding hardware settings there feels correct.
from clightd.
For now, the interface is like this:
busctl call org.clightd.clightd /org/clightd/clightd/Sensor org.clightd.clightd.Sensor Capture "sis" "" 5 "10094849=1,10094850=200"
Where last string parameter means "set V4L2_CID_EXPOSURE_AUTO to V4L2_EXPOSURE_MANUAL and V4L2_CID_EXPOSURE_ABSOLUTE to 200".
You can find these values in <linux/v4l2-controls.h
>.
I know this is not super user-friendly but this is the best way to be able to receive any v4l2 option without manually parsing each string/forcing users to only use some strings, eg: "Exposure=manual,ExposureValue=200": it becomes much more bloated and i'd have to eventually keep up with new defines added in v4l2-controls.h.
Instead, directly using defined values in v4l2-controls.h gives more power and flexibility, while being (hopefully) simple enough.
Note that settings string is useless for ALS sensors.
Finally, clight.conf will expose a new option string, eg:
sensor_settings="10094849=1,10094850=200";
What do you think?
from clightd.
Looks great. As long as we point the users to the definitions in <linux/v4l2-controls.h>
to find out the correct constants, understanding and using these configurations should be quite easy.
Sure, it would be even more readable if we could use the constants' names instead of their value but that would mean we need access to <linux/v4l2-controls.h>
and parse it somehow. Probably not worth implementing it for the small userbase that needs to configure it. But we could think about it, as soon as more issues come up with people not understanding the configurations.
Or even creating a database with calibrated settings for specific devices but I'm getting ahead of myself :D
As soon as you are ready you can send over a patch or git ref and I'll test it with my Dell Latitude integrated webcam (0c45:6715).
from clightd.
Looks great. As long as we point the users to the definitions in <linux/v4l2-controls.h> to find out the correct constants, understanding and using these configurations should be quite easy.
Yes, obviously :)
Sure, it would be even more readable if we could use the constants' names instead of their value but that would mean we need access to <linux/v4l2-controls.h> and parse it somehow.
Yes, it would; it would add a huge overhead (ie: parsing v4l2-controls and storing a string for each define. And then match user string with one of the above).
I think it is really too much complex.
Probably not worth implementing it for the small userbase that needs to configure it.
Agree with you!
As soon as you are ready you can send over a patch or git ref and I'll test it with my Dell Latitude integrated webcam (0c45:6715).
Attached patch (clightd side) should work! You can test with:
busctl call org.clightd.clightd /org/clightd/clightd/Sensor org.clightd.clightd.Sensor Capture "sis" "" 5 "FOO=BAR,X=Y"
from clightd.
> busctl call org.clightd.clightd /org/clightd/clightd/Sensor org.clightd.clightd.Sensor Capture "sis" "" 5 "10094849=1,10094850=250"
sad "/dev/video0" 5 0.430295 0.430371 0.430431 0.430528 0.430435
Even though it makes my video device "sad", it works perfectly fine.
from clightd.
Even though it makes my video device "sad", it works perfectly fine.
🤣
And when called with no parameters, still gives same results as before, right?
from clightd.
The work is now in master. It does require libmodule 5.0.0 though (released but unavailable yet on AUR to avoid breaking current clight/clightd installations).
from clightd.
Related Issues (20)
- [FEATURE REQ] suncalc+geo based illuminance sensor HOT 2
- GLib.Variants Invalid GVariant format string for `d(du)` HOT 2
- [FEAT REQ] Uninstall Make rule HOT 3
- Configure specific methods (ACPI/DDC/Emulated) of brightness control for different DRM nodes/monitors HOT 1
- [BUG] screen functionality broke fcitx5 candidate window HOT 8
- Wayland DPMS & acpid.service issues HOT 1
- [FEATURE REQ] Support for NV12 sensor format HOT 15
- Can't set external monitor. HOT 5
- [BUG] High cpu usage HOT 9
- [BUG] Build Errors on Fedora after recent updates to Backlight.c & Backlight2.c HOT 7
- Device or resource busy HOT 18
- iio device I/O error HOT 3
- External monitor no detected HOT 6
- Failed to add object vtable on path HOT 4
- Need libusb-1.0-0-dev in Ubuntu HOT 1
- ALS not working HOT 35
- Not able to detect ALS on ThinkPad X1 Yoga Gen 5 HOT 11
- Brightness level fluctuates since update to 5.7 HOT 3
- Cmake, libmodule not found HOT 3
- [FEATURE REQ] Wlroots DPMS support HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from clightd.