[FeatureRequest?] Overwrite auto-exposure of webcam

[fededp]

[FeatureRequest?] Overwrite auto-exposure of webcam

[FedeDP]

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!

[pdf]

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.

[FedeDP]

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 :)

[FedeDP]

"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!

[gersilex]

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 ""

[FedeDP]

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...)

[bryango]

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. 😆

[FedeDP]

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!

[bryango]

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. 😆

[mendelmunkis]

I've noticed that (at least on my laptop) auto-exposure tends to counteract the light that clight picks up from the screen itself

[FedeDP]

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?

[mendelmunkis]

On the second thought this should really be a new issue given that what's relevant to this one is just a minor workaround

[FedeDP]

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).

[FedeDP]

Latest couple of commits should address this issue (commit: 33d0ac4).
@bryango
Let me know if this works fine for you!

[FedeDP]

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.

[FedeDP]

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!

[pdf]

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.

[FedeDP]

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.

[pdf]

Ah, I see... a little more complicated, but I'll try working with that. Sorry for the noise.

[FedeDP]

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".

[gersilex]

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?

[FedeDP]

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.

[gersilex]

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.

[FedeDP]

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?

[gersilex]

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).

[FedeDP]

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"

clightd.txt

[gersilex]

> 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.

[FedeDP]

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?

[FedeDP]

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).