Closed
Bug 844921
Opened 12 years ago
Closed 11 years ago
Camera - expose supported picture sizes in camera app
Categories
(Firefox OS Graveyard :: Gaia::Camera, defect)
Tracking
(blocking-b2g:-)
RESOLVED
FIXED
blocking-b2g | - |
People
(Reporter: mikeh, Assigned: wilsonpage)
References
Details
No description provided.
Comment 1•12 years ago
|
||
Requesting blocking for leo, as without then based on this comment we will have a downstream gaia fork: https://bugzilla.mozilla.org/show_bug.cgi?id=838512#c2
blocking-b2g: --- → leo?
Reporter | ||
Comment 2•12 years ago
|
||
CCing dale since he'd like be the one tweaking the camera app.
djf, one challenge will be making sure that we have the memory available to post-process 5MP images, which is part of the reason we limited captures to 2MP in the first place, even on hardware that supports higher resolutions. Any thoughts on how to approach this?
Comment 3•12 years ago
|
||
Even with 512MB RAM?
Reporter | ||
Comment 4•12 years ago
|
||
(In reply to Michael Vines [:m1] [:evilmachines] from comment #3)
>
> Even with 512MB RAM?
No, but we ran into memory issues with images >2MP on platforms with only 256MB.
Comment 5•12 years ago
|
||
Good, we're targeting 512MB for leo
Comment 6•12 years ago
|
||
I have not tested the memory required for editing and saving larger files. We should be sure we can do that comfortably for any resolution we support. The edit UI works on a screen-sized image until you actually click the check box to save your edit. Only then does send the full image through WebGL and through canvas.getBlob().
The memory issues that prompted the current 2 megapixle restrictions were related to just displaying the images in the gallery. The app needs to keep three images decoded at a time (current next and previous). And, gecko does not always free image memory promptly. So we were finding that rapidly flicking through the images could cause an OOM.
This issue has been resolved by displaying the embedded preview image (when it is available) instead of the fullsize image and only decoding the full image when the user actually wants to zoom in.
With that change, it is probably safe to lift the 2mp restriction. I don't advocate changing the default resolution, however. I'm not sure that anyone actually wants bigger images on entry level phones with tiny fixed-focus cameras.
Comment 7•12 years ago
|
||
Is this bug about adding new UX to the camera to allow the user to select an image size? If so, we need to get the UX team involved.
Or is it about adding a build-time configuration option so that our partners can easily configure the fixed image size?
As we want to use 5MP resolution for Camera capture, Please provide us one of the following options:
1. Support for Multi resolution 2MP and 5MP, so that we will use 5MP option for our device.
2. Change current implementation to support 5MP resolution just for Leo.
Please give your reply As soon as possible.
Comment 9•12 years ago
|
||
Not blocking on original report, is a new feature that is not a P1 for 1.1.
blocking-b2g: leo? → -
Comment 10•12 years ago
|
||
(In reply to leo.bugzilla.gaia from comment #8)
> As we want to use 5MP resolution for Camera capture, Please provide us one
> of the following options:
> 1. Support for Multi resolution 2MP and 5MP, so that we will use 5MP option
> for our device.
> 2. Change current implementation to support 5MP resolution just for Leo.
>
> Please give your reply As soon as possible.
Please file a separate bug for that.
Updated•11 years ago
|
Comment 11•11 years ago
|
||
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → wilsonpage
Assignee | ||
Comment 12•11 years ago
|
||
Closing. This has landed as part of the 1.4 camera.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•