Closed Bug 929843 Opened 11 years ago Closed 11 years ago

[B2G][Helix][Camera][dingyu]The photo is much darker than preview after taking a video recording

Categories

(Firefox OS Graveyard :: Gaia::Camera, defect, P1)

defect

Tracking

(blocking-b2g:hd+)

RESOLVED DUPLICATE of bug 926999
blocking-b2g hd+

People

(Reporter: lecky.wanglei, Unassigned)

Details

(Whiteboard: [SR 01273124])

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1 Steps to reproduce: 1.open the camera and change to the video mode 2.start and stop a video recording 3.change the camera to the snapshot mode 4.take a snapshot Actual results: After taking a video recording, then change the camera to the snapshot mode and take a photo, the poho is much darker than preview Expected results: the picture's brightless is the same as the preview
Severity: normal → critical
blocking-b2g: --- → hd?
Flags: needinfo?(wchang)
Priority: -- → P1
I also do the test that change the camera to the video mode without a video recording and then change the camera back to the snapshot mode, the photo is normal. By the way, The back camera can reproduce it 100%, and the front camera I cann't reproduce it. I have check the issue with qualcomm, the qualcomm said that "We found out that the issue is with FFOS APP (Gaia & Gecko) . To confirm it we tried the same use case on Android which is having the same version of ICS at the base (Same HAL & Camera components) and the issue is not reproducible on android ." and I also find a similar case https://bugzilla.mozilla.org/show_bug.cgi?id=926999.
I dont see this problem when I just tested. QAWANTED on this, please nominate this if you see the problem. cc'ing Vincent to follow.
blocking-b2g: hd? → -
Flags: needinfo?(wchang)
Keywords: qawanted
Hi Wayne: You can test our hd device, It's reproduce probability is 100%, if you test back camera!
Video doesn't seem to be working for me in the build I have. Lecky, it's not a white balance issue? I noticed that lots of white can cause an issue with what the camera/video picks up. Also can you attach a screenshot (power on + home) and the image that was taken so we can do a comparison?
Flags: needinfo?(lecky.wanglei)
Naoki, I don't think it's a white balance issue. The photo is just much darker than the preview, the awb has no problem. I will attach the screenshot and the photo. Can you can confirm the case https://bugzilla.mozilla.org/show_bug.cgi?id=926999 is the same problem.
Flags: needinfo?(lecky.wanglei)
Attached file Pic.rar
HI Naoki: I have do another test that: (1) Dark environment: Without a vido step: Flash mode auto: flash open, the picture is Normal Flash mode on : flash open, the picture is Normal Flash mode off: flash off, the picture is darker than noraml With a vido step: Flash mode auto : flash open, the picture is Normal Flash mode on: flash open, the picture is Normal Flash mode off: flash off, the picture is almost all black (2) Normal environment: Without a vido step: Flash mode auto: flash off, the picture is Normal Flash mode on : flash open, the picture is Normal Flash mode off: flash off, the picture is Normal With a vido step: Flash mode auto : flash open, the picture is darker than noraml Flash mode on: flash open, the picture is Normal Flash mode off: flash close, the picture is darker than noraml Maybe it's helpful
Attached video WP_20130306_001.mp4
Hi Vincent, Can you help on this? Check attachment in comment 8.
Flags: needinfo?(vliu)
Observed also on 20131025042341 Moz build over vendor B004 Firmware
Doesn't happen on Leo.
Needinfo "whsu" to remind myself to replicate this bug
Flags: needinfo?(whsu)
Hi, all, I can reproduce this bug on latest commercial build and Mozilla build. I found a interesting behavior. If you record a video then take a picture under the blazing sun, the picture will be overexposure and vice versa... Something went wrong with the judgement of white balance. :) Attaching the screenshot. * Test Build: + commercial build: - Gaia: 1389e7b8f76c6b77b979799fafc3862f7c27028d - Gecko: NA - BuildID 20131026030111 - Version 18.0 + Mozilla build: - Gaia: 366cb29c3ca9a25efcb95ed35d4395e613e099a5 - Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/369468c97d16 - BuildID 20131028042204 - Version 18.0
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(whsu)
(In reply to lecky from comment #7) > HI Naoki: > I have do another test that: > (1) Dark environment: Without a vido step: Flash mode auto: flash open, > the picture is Normal > Flash mode on : flash open, > the picture is Normal > Flash mode off: flash off, > the picture is darker than noraml > With a vido step: Flash mode auto : flash > open, the picture is Normal > Flash mode on: flash open, > the picture is Normal > Flash mode off: flash off, > the picture is almost all black > > (2) Normal environment: Without a vido step: Flash mode auto: flash off, > the picture is Normal > Flash mode on : flash > open, the picture is Normal > Flash mode off: flash off, > the picture is Normal > With a vido step: Flash mode auto : flash > open, the picture is darker than noraml > Flash mode on: flash open, > the picture is Normal > Flash mode off: flash > close, the picture is darker than noraml > > Maybe it's helpful As I know, the capability of camera control in Gecko are all defined in http://mxr.mozilla.org/mozilla-central/source/dom/camera/nsIDOMCameraManager.idl#40 Even so, not all properties are used. For example, flashMode is one of these properties gaia implemented. Going through the code in Gecko/Gaia and I can't find any camera configuration to cause the issue happens. I think partner should check camera parameters in camera driver to find out the root cause.
Flags: needinfo?(vliu)
I think it not the camera driver cause this issue. Because it not our device have this problem. In bug https://bugzilla.mozilla.org/show_bug.cgi?id=926999 have this problem, and in Comment 1, the qualcomm engineer have test in their device, it also have the problem!
(In reply to lecky from comment #16) > I think it not the camera driver cause this issue. Because it not our device > have this problem. > In bug https://bugzilla.mozilla.org/show_bug.cgi?id=926999 have this problem, > and in Comment 1, the qualcomm engineer have test in their device, it also > have the problem! Bug 926999 mentioned about the issue explained below. "Black preview is observed during snapshots." It wants to say "block preview" is observed during snapshots. When I tried to reproduce this issue, there is no any black preview during snapshots. In the test you did in Comment 15, the only difference is different flash mode. Checking the code in Gecko/Gaia, it only sets flashMode and nothing else. Besides it, I don't see any configurations can let the picture can have the ambiguously difference between |normal| and |darker than noraml|. Please feel free to point me out if I missed any in Gecko/Gaia. Thanks (In reply to lecky from comment #5) > Naoki, I don't think it's a white balance issue. The photo is just much > darker than the preview, the awb has no problem. I will attach the > screenshot and the photo. Can you explain how you did for awb case? Thanks.
Vincent, Actually, I can see the preview become darker in a short time after the picture is taking, then the preview become normal. As for when the flash is on, the picture is normal. I have provide reference log to qualcomm for more analyze, I will updata the result as soon as I get the result. When the camera is in preview mode, the awb will work. but if I press the capture button, the camera will toggle to the snapshot mode, the qualcomm VFE will record the final balance states of the preview. In snapshot mode, the qualcomm VFE will not do awb, the VFE will use the final white balance states of the preview as the withe balance of snapshot.By the way, comparing the picture with video recording and without video recording, there is no distinct color deviation. The only difference is the brightness of the picture. So I don't think it's a white balance issue. At first, I think it maybe some problem of the AEC by qualcomm. But qualcomm analyze that they have not find any trouble in VFE and do a test in their device, They feel it maybe some trouble in UI.
Maybe the exposure compensation value is getting corrupted?
Let's keep in mind this doesnt happen on leo, the other v1.1 device I tested. Vincent, would it help if you compare the sequences from Leo and Helix and see if Gecko/Gaia is doing anything differently between the two devices?
Flags: needinfo?(vliu)
putting hd+ on this to get traction. We should have this resolved. Vincent, any one from Qualcomm we should involve here?
blocking-b2g: - → hd+
Maybe :diego can help us to clarify this issue.
Flags: needinfo?(vliu)
It might be possible to add a call to CameraParameters.dump() in gecko to see if any of the camera configuration has changed before vs. after. If someone tries this, there was some mention (in this or another bug) about some of the camera settings being proprietary--if so, please open a new bug flagged Confidential and append the results there.
I believe this issue was seen earlier on this device and it was fixed with a proprietary update. Can the reporter please refer to SR01270937, please?
Flags: needinfo?(lecky.wanglei)
(In reply to Diego Wilson [:diego] from comment #24) > I believe this issue was seen earlier on this device and it was fixed with a > proprietary update. Can the reporter please refer to SR01270937, please? Diego, the SR is submit by me. The reproduce step is the same. Before the SR is fixed, the picture become blue and dark. The reason is as follows: Once I press the capture button after a video recording, will call awb_load_chromatix to load the chromatix effect files, the snapshot awb will use the default TL84 parameter instead of the white balance parameter of the preview before the capturing button is taking. Recently the bug is fixed, that why I don't think the darker issue is not the problem of the white balance Qualcommm engineer is also thought the darker issue is the similar reason as the blue issue before. but they checkout their aec code and think that the aec have no problem.
Flags: needinfo?(lecky.wanglei)
setting ni for comment 25
Flags: needinfo?(dwilson)
Diego: I have submit a qualcomm SR 01273124 , you can check it!
(In reply to Wayne Chang [:wchang] from comment #2) > I dont see this problem when I just tested. > QAWANTED on this, please nominate this if you see the problem. > > cc'ing Vincent to follow. I can reproduce this bug. Removing "QAwanted".
Keywords: qawanted
Yes, this does seem like a proprietary issue. Let's wait to see if they can figure it out on that side. I'll let you know if there's any update there.
Flags: needinfo?(dwilson)
Whiteboard: [SR 01273124]
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: