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)
Firefox OS Graveyard
Gaia::Camera
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.
Comment 2•11 years ago
|
||
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.
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?
![]() |
||
Updated•11 years ago
|
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)
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
Comment 9•11 years ago
|
||
Hi Vincent,
Can you help on this? Check attachment in comment 8.
Flags: needinfo?(vliu)
Comment 10•11 years ago
|
||
Observed also on 20131025042341 Moz build over vendor B004 Firmware
Comment 11•11 years ago
|
||
Doesn't happen on Leo.
Comment 12•11 years ago
|
||
Needinfo "whsu" to remind myself to replicate this bug
Flags: needinfo?(whsu)
Comment 13•11 years ago
|
||
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)
Comment 14•11 years ago
|
||
Comment 15•11 years ago
|
||
(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)
Reporter | ||
Comment 16•11 years ago
|
||
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!
Comment 17•11 years ago
|
||
(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.
Reporter | ||
Comment 18•11 years ago
|
||
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.
Comment 19•11 years ago
|
||
Maybe the exposure compensation value is getting corrupted?
Comment 20•11 years ago
|
||
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)
Comment 21•11 years ago
|
||
putting hd+ on this to get traction. We should have this resolved.
Vincent, any one from Qualcomm we should involve here?
blocking-b2g: - → hd+
Comment 23•11 years ago
|
||
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.
Comment 24•11 years ago
|
||
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)
Reporter | ||
Comment 25•11 years ago
|
||
(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)
Reporter | ||
Comment 27•11 years ago
|
||
Diego: I have submit a qualcomm SR 01273124 , you can check it!
Comment 28•11 years ago
|
||
(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
Comment 29•11 years ago
|
||
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)
Updated•11 years ago
|
Whiteboard: [SR 01273124]
Updated•11 years ago
|
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.
Description
•