Description: Any pictures that are taken are given a small amount of vertical compression immediately afterwards. Repro Steps: 1) Updated to Inari Build ID: 20130429070204 2) Launch the camera app. 3) Take a picture and observe the appearance of the picture taken. Actual: The picture is vertically compressed shortly after it is taken. Expected: The dimensions of the picture is unchanged after it is taken. Environmental Variables: Occurs on the Inari device Build ID: 20130429070204 Kernel Date: Feb 21 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/45aa5ba0ed53 Gaia: cf2d4136f0ebc66039637fdbeb72ed184dfbc0f2 Version #: 18.0 Notes: Repro frequency: 100% Test Suite Name: Firefox OS Daily Smoketest UCID: Daily Smoketest Link to failed test case: https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-id=1325 Q Analysts Test Team Priority: Pri 3 See attached logcat logs for more info.

From the inari logcat: V( 117:0x75) requested preview size 480 x 320 V( 117:0x75) requested picture size 1600 x 1200 V( 117:0x75) requested jpeg thumbnail size 512 x 384 Preview size (and the display size) is 3:2, and picture size is 4:3, which seems to be the size applied to the "postview" frame on the inari. This will result in a postview that is squished along the narrow axis, assuming the long axis remains the same. dale, can we adjust the style of the viewfinder element to make it fill without distorting the aspect ratio?

Yup this has been a long needed change, will have a patch for it shortly

Note: landscape will show the image in the same res in landscape.

preview being shown in a different ratio isn't a blocker.

Doh, as far as I can tell the previous patch never landed (and if I remember there were problems with the hardware honoring the set size) There isnt a thumbnailSizes in camera.capabilities right now at least, although looking through the code 'some' of it must have landed

The rotation setting wasnt currently being used so I took it out, this also fixed https://bugzilla.mozilla.org/show_bug.cgi?id=871904 however there are other bugs visible on the leo device so will file seperately

Comment on attachment 750630 [details] Pointed to GH I haven't had a chance to try the code out yet, but am giving r- because I don't understand the math being used to position the viewfinder object. See my comments on github. I'll finish reviewing when you alter or comment the math.

I partially get the math now, and have updated my github comments.

Comment on attachment 750630 [details] Pointed to GH Updated the viewfinder logic, I think it is a lot clearer right now. Made a few other changes based on the comments, Tested on inari and leo. We will have a slight edge to the right or bottom of the preview in which extra data will be captured in the final picture, but it is small enough I didnt see it worth adding the code to center it (and it is expected that cameras capture a little more than is in the preview)

Comment on attachment 750630 [details] Pointed to GH r+ if you fix the new comments on github. A couple are just nits. One is an error in an else clause that will probably never run. But I've also suggested code you can use to center the viewfinder. I think it is worth doing that because otherwise a full 1/8th of the frame is off the right side.

A nice thing about this patch is that it cures the graphical garbage screen that was always displayed on unagi after taking a picture!

Merged in: https://github.com/mozilla-b2g/gaia/commit/a80a08c71f111344fda673f1a2b6475484f6efa4

Setting target milestone and nominating for leo because the duplicate bug 871904 was a leo qe2 bug. The symptom in 871904 sounds pretty serious on Leo hardware, so I think this fix really needs to be uplifted.

hey, you broke the linter, could you please make a quick follow up to fix it ?

Apologies, followed up and merged in: https://github.com/mozilla-b2g/gaia/pull/9860

new commit master hash is 292f6c2fba2729c81a304c65597ed20efca45d2e thanks dale !

Triage Leo+ per comment 14

I was not able to uplift this bug to v1-train. If this bug has dependencies which are not marked in this bug, please comment on this bug. If this bug depends on patches that aren't approved for v1-train, we need to re-evaluate the approval. Otherwise, if this is just a merge conflict, you might be able to resolve it with: git checkout v1-train git cherry-pick -x -m1 292f6c2fba2729c81a304c65597ed20efca45d2e <RESOLVE MERGE CONFLICTS> git commit

Gaye, there are 2 commits here: 1. a80a08c71f111344fda673f1a2b6475484f6efa4 2. 292f6c2fba2729c81a304c65597ed20efca45d2e

Uplifted 292f6c2fba2729c81a304c65597ed20efca45d2e to: v1-train: b28e941caf486a0fe8d6af1a9cde670c5638de2c

UCID: camera-001 TC link: https://moztrap.mozilla.org/manage/cases/?&pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-id=1325

Still repros on Inari 1.0.1 commercial RIL. Build ID: 20130620070212 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/9c62297d11b0 Gaia: 93241eb6c5d6c110710fad8da3ccd4423312b0c9 Platform Version: 18.0

Still repros on Inari 1.0.1 commercial RIL Build ID: 20130722070204 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/9c62297d11b0 Gaia: 054cdc27404e2daca91d3065d9783681032b2151 Platform Version: 18.0 RIL Version: 01.00.01.019.144

Photos are still compressed on Inari 1.0.1 commercial RIL. Build ID: 20130816043204 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/9c62297d11b0 Gaia: 054cdc27404e2daca91d3065d9783681032b2151 Platform Version: 18.0 RIL Version: 01.00.01.019.144

ckreinbring> this is not fixed in 1.0.1, this is fixed in 1.1 only :)