840615 - Pictures in gallery default view should fill screen

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Gallery, defect)

Description

[Marcia Knous [:marcia]]

Attachment: Sample picture with borders

unagi, while using

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/3f905f0ca9ce
Gaia   ecca2ee860825547d5e1109436b50b74dfe9261e
BuildID 20130212070205
Version 18.0

STR:
1. Take a picture or load a picture already in your gallery
2. Observe attached screenshot

There now seems to be a grey border above and below the picture. I thought previously that the pictures filled the screen with no border but I may be mistaken.

In comparing this with an Android device, they show a border as well but it is black not grey.

Comment 1

[Josh Carpenter [:jcarpenter]]

Gallery photos in default view (not zoomed in) should fill the full screen area. Currently we scale the photo down until all it fits within the screen, but unless the photo's proportions exactly match the screen's, this reveals blank background areas. We should instead fit photos to the screen and then scale up until there is no background visible, making an exception only for images whose proportions do not match the current screen proportions (eg: landscape photo being viewed on portrait screen). We should also make the background black while we're at it, instead of gray.

Marking UX Most Wanted, as this simple trick should dramatically improve the look of the Gallery.

Comment 2

[Josh Carpenter [:jcarpenter]]

David, does that description make sense? I'm happy to go over this if you have some time. We really want this in as part of quality improvement push. It should make a big difference to the look and feel of browsing photos in the gallery. Thanks!

Comment 3

[David Flanagan [:djf]]

Changing the background color is trivial, and I'm happy to do that. The reason it is gray right now, though, is that the edit menu has an option to add a black border. If the border is black and the background is black, then you can't see the border and it seems like the border option is broken.

Filling the screen instead of letterboxing might not be trivial to do... I'd have to play around with it some.  Here are some questions, though:

1) Is your intent that the default would be zoomed in a little bit but that that user could still zoom out to a letterboxed view to see the entire image?

2) There is an issue with borders here, too. If the user edits a portrait mode photo to add a white border (for example) we'll always display the photo so that the top and bottom borders are visible and the side borders are off the edges. This will look much worse than what we have now.

3) I wonder if we can't just make the camera take photos that match the screen aspect ratio. This would have to be done at the camera hardware driver level, I think.  I'm pretty sure that for the otoro and unagi, at least, we can take 3x4 photos and some other ratios, but there was not an option to take an image with a 2x3 aspect ratio. I wonder if that is different on other hardware.  Mike H might be able to tell us.

Comment 4

[David Flanagan [:djf]]

(In reply to Josh Carpenter [:jcarpenter] from comment #2)
> David, does that description make sense? I'm happy to go over this if you
> have some time. We really want this in as part of quality improvement push.
> It should make a big difference to the look and feel of browsing photos in
> the gallery. Thanks!

Josh, 

Yes, the description makes sense, but it is kind of a can of worms. The border issues seem like serious enough issues that I don't want to proceed without further instruction from you.  Also, here's another question. If we start with a zoom level so there is no letterboxing, what do you want double-tap to do? Will double-tapping ever zoom out far enough to reveal the letterboxing?

Mikeh: in case it is not clear, the question I have for you is at the very end of comment 3.

Comment 5

[Mike Habicher [:mikeh] (high bugzilla latency)]

Using Unagi as an example:

I( 1016:0x3f8) pictureSize[ 0 ] = 2592x1944 --> 4:3
I( 1016:0x3f8) pictureSize[ 1 ] = 2048x1536 --> 4:3
I( 1016:0x3f8) pictureSize[ 2 ] = 1920x1080 --> 16:9
I( 1016:0x3f8) pictureSize[ 3 ] = 1600x1200 --> 4:3
I( 1016:0x3f8) pictureSize[ 4 ] = 1280x768  --> 5:3
I( 1016:0x3f8) pictureSize[ 5 ] = 1280x720  --> 16:9
I( 1016:0x3f8) pictureSize[ 6 ] = 1024x768  --> 4:3
I( 1016:0x3f8) pictureSize[ 7 ] = 800x600   --> 4:3
I( 1016:0x3f8) pictureSize[ 8 ] = 800x480   --> 5:3
I( 1016:0x3f8) pictureSize[ 9 ] = 640x480   --> 4:3
I( 1016:0x3f8) pictureSize[ 10 ] = 352x288  --> 11:9
I( 1016:0x3f8) pictureSize[ 11 ] = 320x240  --> 4:3
I( 1016:0x3f8) pictureSize[ 12 ] = 176x144  --> 11:9

There are simply no 3:2 aspect ratios that would match up the taken photos with the display.  I have some other handsets handy and will test them out, but I expect the results will be similar.

Even if we did manage to find one particular piece of kit that has matching screen and camera aspect ratios, we still have to handle the non-matching case for everything else.  I think a black or dim gray background is as good a solution as any.  (I'm less supportive of scaling the image to fit the narrower dimension to the screen.)

Comment 6

[Mike Habicher [:mikeh] (high bugzilla latency)]

Here is data from another (non-Unagi, non-Otoro) piece of kit:

I(  765:0x2fd) pictureSize[ 0 ] = 1600x1200
I(  765:0x2fd) pictureSize[ 1 ] = 1280x768
I(  765:0x2fd) pictureSize[ 2 ] = 1280x720
I(  765:0x2fd) pictureSize[ 3 ] = 1024x768
I(  765:0x2fd) pictureSize[ 4 ] = 800x600
I(  765:0x2fd) pictureSize[ 5 ] = 800x480
I(  765:0x2fd) pictureSize[ 6 ] = 640x480
I(  765:0x2fd) pictureSize[ 7 ] = 352x288
I(  765:0x2fd) pictureSize[ 8 ] = 320x240
I(  765:0x2fd) pictureSize[ 9 ] = 176x144

On this handset, we selected a screen-filling preview size of 480x320 (3:2).

Comment 7

[Josh Carpenter [:jcarpenter]]

Thanks for the feedback, guys. Re: borders, I suspect few people will use them, making it more important that photos look as good as possible by default. That makes black backgrounds and fullscreen images worth some sacrifices to border rendering. I take the point that we'll need to think through these issues, however, and spec the new behavior before implementing.

(In reply to David Flanagan [:djf] from comment #4)
> Also, here's another question. If we
> start with a zoom level so there is no letterboxing, what do you want
> double-tap to do? Will double-tapping ever zoom out far enough to reveal the
> letterboxing?

Double tapping zooms into the image as usual, whereupon the user can drag within the full image, including the areas that were cropped in the default view.

Comment 8

[BMO Automation]

Firefox OS is not being worked on