[Camera][Flame] Rear Camera on Flame not capable of fast enough shutter speed

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
4 years ago
6 months ago

People

(Reporter: Synper311, Unassigned)

Tracking

({verifyme})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [POVB])

Attachments

(6 attachments)

(Reporter)

Description

4 years ago
Created attachment 8549114 [details]
IMG_0010.jpg

The attached shot is from Flame Rear Camera (v1.88 base), v3.0 nightly

The camera was aimed at my car (red one), and tapped to focus/meter off that car.

What I got was a massively overblown mess. This happens every time I try and take a photograph in this kind of brightness.

Camera reported EXIF:
Exposure Time: 1/29760s
ISO: ISO-100
(Reporter)

Comment 1

4 years ago
Created attachment 8549117 [details]
IMG_0011.jpg

Image from the Flame Front Camera

Camera Reported EXIF:
Exposure Time: 1/2147483647s
ISO: ISO-28525

The ISO on this sounds wrong, but the shot is metered close enough to correct for me to not be too bothered, and the resulting image is usable, unlike the back camera.
(Reporter)

Comment 2

4 years ago
Created attachment 8549119 [details]
150114_001.jpg

Shot from Samsung Evergreen (SGH-a667) Dumbphone

Camera Reported EXIF:
Aperture: F/2.8
Exposure Time: 1/1578s
ISO: ISO-50

This camera meters quickly and accurately and gives me a usable image, even in very bright situations.
(Reporter)

Updated

4 years ago
Flags: needinfo?(mhabicher)
Wesly, can you ask our partners about this issue?
Flags: needinfo?(mhabicher) → needinfo?(wehuang)
Summary: Bug: Rear Camera on Flame not capable of fast enough shutter speed → [Camera][Flame] Rear Camera on Flame not capable of fast enough shutter speed
Wesly, in particular, point out to them that the EXIF metadata in comment 1 looks insane.
Duplicate of this bug: 1129117

Comment 6

4 years ago
(In reply to Mike Habicher [:mikeh] from comment #3)
> Wesly, can you ask our partners about this issue?

Sorry for late, do you mean the exposure control/EXIF data is something handled by low level (base image), so not related to our v3 nightly above?

@Youlong: would you check if this is related to low level camera implementation, and share your comment about this issue? Thank you.
Flags: needinfo?(wehuang) → needinfo?(youlong.jiang)

Comment 7

4 years ago
(In reply to Mike Habicher [:mikeh] from comment #3)
> Wesly, can you ask our partners about this issue?

Sorry for late, Mike!

@Youlong: 

would you help check this one? My understanding is usually it's low level SW to control exposure and EXIF, maybe you this scenario is not covered in your test case? (object in snow day so lot of while/light area in picture)

Comment 8

4 years ago
pls ignore comment#6.
(Reporter)

Comment 9

4 years ago
Created attachment 8573703 [details]
Flame_0404.jpg

Whatever fixes we make, we need to keep this current behavior as a filter in the Gallery's Edit function.

The Flame can turn out some cool images with its metering and color so messed up in bright situations.

Comment 10

4 years ago
(In reply to Wesly Huang from comment #8)
> pls ignore comment#6.

hi wesly -

yep. we've simulated the env to reproduce this problem and caught the bad phenomenon. from preliminary analysis, it may be caused by qcom exposure algorithm. we need more time to confirm with qcom, and would feedback if we get some update.

tks.
Flags: needinfo?(youlong.jiang)
Status: UNCONFIRMED → NEW
Component: Gaia::Camera → Vendcom
Ever confirmed: true
Whiteboard: [POVB]

Comment 11

4 years ago
(In reply to youlong.jiang from comment #10)
> (In reply to Wesly Huang from comment #8)
> > pls ignore comment#6.
> 
> hi wesly -
> 
> yep. we've simulated the env to reproduce this problem and caught the bad
> phenomenon. from preliminary analysis, it may be caused by qcom exposure
> algorithm. we need more time to confirm with qcom, and would feedback if we
> get some update.
> 
> tks.

hi wesly -

we would deliver a patch for this problem, that is reset exposure register to fix this issue. then I think we would release tmp image to you to verify this problem.

tks.

Comment 12

3 years ago
Created attachment 8584322 [details]
pached lib

Comment 13

3 years ago
Dears -

sorry for the delay feedback.

pls refer to attach lib patched for this problem. if any problem pls contact me directly.

tks.
See Also: → bug 1056956
Duplicate of this bug: 1056956
Duplicate of this bug: 1082829
Let's test the exposure metering once this bug is in Resolved Fixed state.
Keywords: verifyme
To manually flash the library:
> adb remount
> adb push libmmcamera_skuf_ov5648_p5v23c.so /system/vendor/lib
> adb reboot

Youlong: As I mentioned in the other duplicate bugs, this has been working wonderfully for me. Outdoor pictures are great on Flame with it.

Wesley: In order to resolve this properly, we will need an updated base image our QA can vet and we can eventually release to replace 18D.
Flags: needinfo?(wehuang)

Comment 18

3 years ago
(In reply to Andrew Osmond [:aosmond] from comment #17)
> To manually flash the library:
> > adb remount
> > adb push libmmcamera_skuf_ov5648_p5v23c.so /system/vendor/lib
> > adb reboot
> 
> Youlong: As I mentioned in the other duplicate bugs, this has been working
> wonderfully for me. Outdoor pictures are great on Flame with it.
> 
> Wesley: In order to resolve this properly, we will need an updated base
> image our QA can vet and we can eventually release to replace 18D.

Andrew:

That's great to hear!

Considering v18D is the last planned official SW release from T2M, maybe we should find a way to have this fix in our pvt or nightly build instead so QA, dev, and people who are still actively using Flame can get the fix?
Flags: needinfo?(wehuang)
(In reply to Wesly Huang from comment #18)
> (In reply to Andrew Osmond [:aosmond] from comment #17)
> > To manually flash the library:
> > > adb remount
> > > adb push libmmcamera_skuf_ov5648_p5v23c.so /system/vendor/lib
> > > adb reboot
> > 
> > Youlong: As I mentioned in the other duplicate bugs, this has been working
> > wonderfully for me. Outdoor pictures are great on Flame with it.
> > 
> > Wesley: In order to resolve this properly, we will need an updated base
> > image our QA can vet and we can eventually release to replace 18D.
> 
> Andrew:
> 
> That's great to hear!
> 
> Considering v18D is the last planned official SW release from T2M, maybe we
> should find a way to have this fix in our pvt or nightly build instead so
> QA, dev, and people who are still actively using Flame can get the fix?

Youlong: Based on the above, we can probably repackage the base image 18D with the new library or otherwise include it our private/nightly build images (not sure what the procedure is for out-of-band vendor libraries). Beyond the change in functionality, is the library attached safe to release? I.e. does it need to be rebuilt to leave out debugging info, etc or are we fine as is to redistribute it? Thanks.
Flags: needinfo?(youlong.jiang)
(Reporter)

Comment 20

3 years ago
Wait, so the Flame is being dropped from support already?

What is the next developer device I need to get?

Testing out the library now on my Flame...

Comment 21

3 years ago
I was waiting a long time for it, great to be able to take photos in good weather ;o)  So i confirm, that pushing that one lib really helps.
Created attachment 8610965 [details]
Screen Shot 2015-05-26 at 7.07.26 PM.png

I think I need it brighter in order to retest. ( 10:46 isn't accurate; it should be 7:46, I just hadn't switched it from EST )  Will retest tomorrow or under brighter conditions.
Flags: needinfo?(youlong.jiang)

Comment 23

6 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.