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

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.

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.

Wesly, can you ask our partners about this issue?

Wesly, in particular, point out to them that the EXIF metadata in comment 1 looks insane.

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

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

pls ignore comment#6.

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.

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

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

Dears - sorry for the delay feedback. pls refer to attach lib patched for this problem. if any problem pls contact me directly. tks.

Let's test the exposure metering once this bug is in Resolved Fixed state.

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.

(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?

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

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

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.

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.

Firefox OS is not being worked on