Bug 507748
Summary: | Auto white balance issues | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Robert Hancock <hancockrwd> | ||||
Component: | libv4l | Assignee: | Hans de Goede <hdegoede> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 11 | CC: | hdegoede | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | 1.3-2.fc10 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2009-09-19 00:09:35 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Robert Hancock
2009-06-24 01:45:00 UTC
Thanks for the report, this is a bit strange, but non the less the divide by 0 is a bug. Here is a new version which should have this fixed, and which only allows slow changes to the whitebalance, which should filter out the "unexplained white balance fluctuations": http://koji.fedoraproject.org/koji/taskinfo?taskID=1433390 I believe the root cause for these lives outside libv4l (either a driver bug, or maybe motion is doing something to the buffers while we're using them), but this should fix things anyways. Can you please give this new version a try? I haven't seen any crashes yet with the new version. However, the white balance behavior doesn't really seem improved. I'm still seeing the white balance fluctuating back and forth, sometimes wildly. The behavior is a little bit odd in other ways, too: if I start v4l2ucp and hit the "update" button for white balance while auto white balance is enabled, the displayed value doesn't seem to change even though the white balance seems to be changing based on the image. (For the exposure setting, the displayed value does update when the library is making adjustments.) Also, even if I disable auto white balance and adjust the white balance manually all the way to minimum or maximum (1 or 127), I don't get such significant color shifts as I'm seeing with auto white balance enabled, which seems odd.. (In reply to comment #2) > I haven't seen any crashes yet with the new version. However, the white balance > behavior doesn't really seem improved. I'm still seeing the white balance > fluctuating back and forth, sometimes wildly. > I'm thinking this is a motion bug actually, I just saw a similar report on the uvc mailing list, in a case where libv4l doesn't come into play. I'll forward the mail. > The behavior is a little bit odd in other ways, too: if I start v4l2ucp and hit > the "update" button for white balance while auto white balance is enabled, the > displayed value doesn't seem to change even though the white balance seems to > be changing based on the image. Ah, yes I must admit this is confusing, the auto whitebalance option enables a software algorithm, which modifies the image in software, there are 2 reasons for this: 1) Some webcams don't have a hardware whitebalance adjustment 2) We do not know exactly what sort of color gain correction factors the whitebalance hardware control does, so we cannot use as we do not know at which value to put it. > (For the exposure setting, the displayed value > does update when the library is making adjustments.) > Ack, the autogain software processing will change the hardware controls (doing gain in software makes no sense) instead of manipulating the image as the whitebalance code does. > Also, even if I disable auto white balance and adjust the white balance > manually all the way to minimum or maximum (1 or 127), I don't get such > significant color shifts as I'm seeing with auto white balance enabled, which > seems odd.. See above. Regards, Hans Ah, that explains why the color can fluctuate more, if it's not actually modifying the hardware white balance settings. That report you forwarded doesn't seem like quite the same issue though.. they seem to be complaining about statically wrong white balance, whereas in my case the auto white balance usually seems to find a reasonable setting, but sometimes tends to bounce around, sometimes really severely.. Here's Motion's output on startup, if it's any use: [0] Processing thread 0 - config file /etc/motion/motion.conf [0] Motion 3.2.11 Started [0] ffmpeg LIBAVCODEC_BUILD 3412992 LIBAVFORMAT_BUILD 3415808 [0] Thread 1 is from /etc/motion/motion.conf [1] Thread 1 started [0] motion-httpd/3.2.11 running, accepting connections [0] motion-httpd: waiting for data on port TCP 8080 [1] cap.driver: "spca561" [1] cap.card: "Camera" [1] cap.bus_info: "usb-0000:00:02.1-4.2" [1] cap.capabilities=0x05000001 [1] - VIDEO_CAPTURE [1] - READWRITE [1] - STREAMING [1] v4l2_select_input: name = "spca561", type 0x00000002, status 00000000 [1] - CAMERA [1] Supported palettes: [1] 0: RGB3 (RGB3) [1] 1: BGR3 (BGR3) [1] 2: YU12 (YU12) [1] Selected palette YU12 [1] index_format 8 Test palette YU12 (352x288) [1] Using palette YU12 (352x288) bytesperlines 352 sizeimage 152064 colorspace 00000008 [1] found control 0x00980910, "Gamma (software)", range 500,3000 [1] "Gamma (software)", default 1000, current 1000 [1] found control 0x00980911, "Exposure", range 1,3195 [1] "Exposure", default 200, current 3195 [1] found control 0x00980912, "Auto Gain (software)", range 0,1 [1] "Auto Gain (software)", default 1, current 1 [1] found control 0x00980913, "Gain", range 0,36 [1] "Gain", default 36, current 36 [1] mmap information: [1] frames=4 [1] 0 length=16777216 [1] 1 length=16777216 [1] 2 length=16777216 [1] 3 length=16777216 [1] Using V4L2 Created attachment 349667 [details]
Video that illustrates the kind of white balance fluctuations I'm seeing
A short video clip from Motion that shows what I'm talking about.. especially the significant brief white balance shift at about 5 seconds in. The brief blips earlier in the video are happening pretty regularly.
Robert, The camera which you are using is not only using auto whitebalance, but also autogain, after gain / exposure changes it may take a (short) time for the whitebalance algorithm to compensate. Try disabling the autogain control, then this should go away. Regards, Hans Unfortunately disabling autogain isn't really an option for me, it's actually more important than the auto white balance as the camera experiences significant light level fluctuations being aimed outside. Any chance of getting the two options to play nicer together, if that is indeed the cause? That seems a bit odd to me, the white balance fluctuations seem a bit extreme to be caused by the usual exposure changes which are pretty minute.. v4l2ucp-1.3-2.fc11,libv4l-0.6.0-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/v4l2ucp-1.3-2.fc11,libv4l-0.6.0-1.fc11 v4l2ucp-1.3-2.fc11, libv4l-0.6.0-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update v4l2ucp libv4l'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7594 v4l2ucp-1.3-2.fc11, libv4l-0.6.0-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update v4l2ucp libv4l'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7594 v4l2ucp-1.3-2.fc11,libv4l-0.6.1-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/v4l2ucp-1.3-2.fc11,libv4l-0.6.1-1.fc11 v4l2ucp-1.3-2.fc10,libv4l-0.6.1-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/v4l2ucp-1.3-2.fc10,libv4l-0.6.1-1.fc10 v4l2ucp-1.3-2.fc10, libv4l-0.6.1-1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update v4l2ucp libv4l'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-9209 v4l2ucp-1.3-2.fc11, libv4l-0.6.1-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update v4l2ucp libv4l'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9215 v4l2ucp-1.3-2.fc11, libv4l-0.6.1-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. v4l2ucp-1.3-2.fc10, libv4l-0.6.1-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. It doesn't seem like the last updates really address the auto white balance problem I was seeing - the auto white balance still seems to go nuts with motion sometimes, causing wild color shifts sometimes (against a frozen image, strangely enough). |