Closed
Bug 1212226
Opened 9 years ago
Closed 9 years ago
[Camera] The thumbnail is very blurry on Aries
Categories
(Firefox OS Graveyard :: Gaia::Camera, defect)
Tracking
(blocking-b2g:2.5+)
VERIFIED
FIXED
blocking-b2g | 2.5+ |
People
(Reporter: julienw, Assigned: djf)
References
Details
(Keywords: foxfood)
Attachments
(3 files, 1 obsolete file)
785 bytes,
patch
|
Details | Diff | Splinter Review | |
1.10 KB,
patch
|
Details | Diff | Splinter Review | |
46 bytes,
text/x-github-pull-request
|
aosmond
:
review+
|
Details | Review |
STR: 1. Take a picture with a Sony device. => Notice the bottom left thumbnail is very blurry This is not happening on Flame. I've been told that this is because the thumbnail given by the camera is too small (see bug 1131294) but I don't believe this is the reason. For example we (Vivien and I) tried to just not do any "crop resize rotate" (by returning the input blob from the function in shared/js/media/crop_resize_rotate.js, see attachment) and it makes the thumbnail crisp. Then I definitely think the issue is in the Gaia code and we should fix it for 2.5, because we can't even recognize whatever was taken with this pixel porridge. (Sorry I don't have a screenshot because it seems I can't take one from this screen... It just takes another picture ;) )
This fixes the issue for me. The issue is that the width/height of the metadata are not updated. As a result we end up calculating the sampling based on the width of the original image instead of the width of the thumbnail. On Aries, it ends up having a sample-size of 8 for the thumbnail, before making them bigger again for displaying...
Altering metadata directly has some side effects. Let's clone the metadata before.
Attachment #8670731 -
Attachment is obsolete: true
Updated•9 years ago
|
Flags: needinfo?(dflanagan)
Flags: needinfo?(aosmond)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → dflanagan
Flags: needinfo?(dflanagan)
Comment 3•9 years ago
|
||
Assignee | ||
Comment 4•9 years ago
|
||
Comment on attachment 8671028 [details] [review] [gaia] davidflanagan:bug1212226 > mozilla-b2g:master Andrew, This is basically just Vivien's patch but changed around a bit. Vivien: thanks for figuring this out.
Attachment #8671028 -
Flags: review?(aosmond)
Assignee | ||
Comment 5•9 years ago
|
||
I agree with Julien that this is a blocker. And I'm surprised that no one has reported it before now!
blocking-b2g: 2.5? → 2.5+
Comment 6•9 years ago
|
||
Comment on attachment 8671028 [details] [review] [gaia] davidflanagan:bug1212226 > mozilla-b2g:master LGTM. So if I understand this correctly, our EXIF thumbnails have always been messed up but before it was not as bad because the difference between the thumbnail size and the image size was not as great. At least the gigantic aries image sizes have been useful for once :).
Flags: needinfo?(aosmond)
Attachment #8671028 -
Flags: review?(aosmond) → review+
Assignee | ||
Comment 7•9 years ago
|
||
(In reply to Andrew Osmond [:aosmond] from comment #6) > Comment on attachment 8671028 [details] [review] > [gaia] davidflanagan:bug1212226 > mozilla-b2g:master > > LGTM. So if I understand this correctly, our EXIF thumbnails have always > been messed up but before it was not as bad because the difference between > the thumbnail size and the image size was not as great. At least the > gigantic aries image sizes have been useful for once :). Yes, I think this code has probably been broken for a long time, but we got away with it because there are only a few downsampling choices with #-moz-samplesize. I think that this patch does make the thumbnails slighly sharper on Flame to. But I guess it was only on aries where the contrast is sizes was so big to make the blurriness unmistakeable. My patch broke a unit test, so I'll have to fix that and resubmit.
Assignee | ||
Comment 8•9 years ago
|
||
Landed: https://github.com/mozilla-b2g/gaia/commit/d9125fb0df5bdd19e1f47d2e36be10c8fce8b039
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment 9•9 years ago
|
||
(In reply to David Flanagan [:djf] from comment #5) > I agree with Julien that this is a blocker. And I'm surprised that no one > has reported it before now! This has been reported since a long time ago in bug 1131294 and for some odd reason they decided it's not a blocker. I was going to reply in 1131294 today but found that a fix has been submitted in this bug.
Reporter | ||
Comment 10•9 years ago
|
||
This feels so good having a fix less than 24h after filing the bug. Thanks all !
Comment 11•9 years ago
|
||
(In reply to David Flanagan [:djf] from comment #4) > Vivien: thanks for figuring this out. Thanks for making it a real fix :)
You need to log in
before you can comment on or make changes to this bug.
Description
•