Closed Bug 1083450 Opened 5 years ago Closed 2 years ago

[Tarako] can we do anything to improve photo quality on low-end Tarako hardware?

Categories

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

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: djf, Unassigned)

References

Details

Attachments

(17 files)

320.12 KB, image/jpeg
Details
539.39 KB, image/jpeg
Details
93.25 KB, image/jpeg
Details
581.64 KB, image/jpeg
Details
563.89 KB, image/jpeg
Details
505.60 KB, image/jpeg
Details
1.52 MB, image/jpeg
Details
397.02 KB, image/jpeg
Details
446.43 KB, image/jpeg
Details
388.81 KB, image/jpeg
Details
515.54 KB, image/jpeg
Details
20.42 KB, image/jpeg
Details
22.30 KB, image/jpeg
Details
22.35 KB, image/jpeg
Details
29.69 KB, image/jpeg
Details
30.97 KB, image/jpeg
Details
26.42 KB, image/jpeg
Details
I'm filing this bug in response to this review of the Cloud FX: http://arstechnica.com/gadgets/2014/10/testing-a-35-firefox-os-phone-how-bad-could-it-be/3/

I suspect this is purely a hardware issue that we won't be able to do anything about, but I'm filing this to investigate. During the 1.3T cycle, the camera app devs were busy refactoring the app and focusing on high-end camera features for the Madai project, so we've never really paid much attention to this hardware.
One of the complaints in the review was that the camera could not even take a useable photo of a page of text. The first two attachments show the photo from the review and my attempt to replicate that photo. My photo is much better than that in the review, and the text isn't sharp but it is readable. So in this case, the photo in the review is bad, or the camera quality of the Cloud FX is worse than our Tarako prototypes.

In my photo the quarter is smaller, but more details are visible than in the review photo.

In my photo, the text is 8.2% the height of a quarter and in the review photo it is 6.7% of the height of a quarter (fine print!) so this is not a completely fair comparison. But the letters are about 20px high in both images, and they are clearly sharper in my image.
So, I heard that the protective plastic layer was hard to remove from the lens on these devices, and even hard to see (for the record, I used one of the devices without noticing it...). I wonder if that was not also the case in this review...
On difference I notice between the first two attached images is that the one from the review has a 640x480 embedded preview image and the one from my prototype Tarako has a preview of 320x240.  This change in preview size was a late change made to improve photo preview speed in the Gallery app.  I think if I flashed an updated base image on my phone I'd get the bigger preview size as well. I think mikeh had a Tarako that uses 640x480 previews as well.
(In reply to Fabrice Desré [:fabrice] from comment #4)
> So, I heard that the protective plastic layer was hard to remove from the
> lens on these devices, and even hard to see (for the record, I used one of
> the devices without noticing it...). I wonder if that was not also the case
> in this review...

Wow. That might explain the watercolor nature of the photos that the review complains about! I don't suppose you still have a device with the plastic on, or photos that show before and after removing the plastic, do you?
Flags: needinfo?(fabrice)
(In reply to David Flanagan [:djf] from comment #6)
> (In reply to Fabrice Desré [:fabrice] from comment #4)
> > So, I heard that the protective plastic layer was hard to remove from the
> > lens on these devices, and even hard to see (for the record, I used one of
> > the devices without noticing it...). I wonder if that was not also the case
> > in this review...
> 
> Wow. That might explain the watercolor nature of the photos that the review
> complains about! I don't suppose you still have a device with the plastic
> on, or photos that show before and after removing the plastic, do you?

Let me try to see if we still have some unboxed ones.
Flags: needinfo?(fabrice)
One of the complaints in the review was about poor performance in low-light.  I can replicate that, though I'm not sure it is quite as bad as the review suggests. The attachment before this one is the same scene and lighting as this one. But this is Android on Galaxy Nexus and the previous one is Tarako.
Looks like we can actually get brighter pictures by setting sceneMode to night in low-light conditions. Maybe we can use the ambient light sensor to decide when to set the scene mode...
In all of my tests, setting sceneMode to night gives better or the same results as sceneMode=auto. In bright sun it might be different, I suppose.

I've tried the other scene modes (portrait, landscape and action) and don't see any difference for any of them. But I've only tested on inanimate objects in an artificially lit office on a very cloudy day.

I've tried setExposureCompensation() with values -3 to 3, and it has no effect at all.

setting whiteBalanceMode has dramatic effects on the color of the photos. In my testing, under artificial light and under heavy overcast, a whiteBalance of 'auto' is as good or better than all the other settings.
In these photos from the review, the image is 1600x1200 and saved with JPEG quality 95. The thumbnail is 640x480 and saved with quality 70.

Using the program 'exiftool' and the 'convert' program from ImageMagick, I can extract the thumbnail and then convert it to png and resize it to 1600x1200 like this:

$ exiftool −b −ThumbnailImage original.jpg > thumbnail.jpg
$ convert -resize 1600x1200 thumbnail.jpg bigthumbnail.png 

If I do that and then visually compare original.jpg to bigthumbnail.png I see that there is really very little difference between the two, and I wonder if that difference could be explained by the quality setting instead of the original image size.  Could it be that somehow the Tarako driver is actually taking a 640x480 image and rescaling it to 1600x1200? If it saved the full-size image at 70 like it saves the thumbnail, would we find that the two images were basically identical?
(In reply to David Flanagan [:djf] from comment #15)

> I've tried setExposureCompensation() with values -3 to 3, and it has no
> effect at all.

setExposureCompensation() is broken on Tarako. It was fixed by bug 1018820 which only landed on 2.0.

I twiddled this value at a lower-level on my Tarako, and have found that it has no effect when taking very dark pictures -- presumably because the exposure is already as wide-open as it can go.
I wondered at first when I saw the Cloud FX review whether the reviewers were taking photos and then emailing them to themselves, since this causes the Tarako to rotate and (because of low memory) downsample the image. If they did this they'd end up with 800x600 photos. But I have since then found the (attached above) images from the review website. They are full size and contain the original EXIF metadata, so they do indeed seem to be the raw images from the camera.
In the earlier-attached flower photo from the review, that diagonal edges of the pink leaves/flower petals look quite jaggy, almost like the camera hardware took a small image and scaled it up to 1600x1200.

The image I'm attaching here is a white piece of paper on a black background (thanks for the idea, Mike) and does not seem to show any jaggies along the diagonal.
(In reply to Fabrice Desré [:fabrice] from comment #7)

> Let me try to see if we still have some unboxed ones.

Did you ever find a new Cloud FX with plastic still on the lens?
Flags: needinfo?(fabrice)
If you look at those photos at full size, there are lots of jagged edges, as if the camera started with a smaller image and magnified it to 1600x1200.  I'll attached 250x250 details to show what I mean.
The photos from the second review have obvious jaggies that look like artifacts from a smaller image being upsampled to 1600x1200.  At least one of the photos from the first review also has jaggies that seem similar. (Other photos from that first review seem too blurry to show any jaggies, for other reasons, I suppose).

When I try to take similar photos with my prototype Tarako device, I do not see jaggies like that. I see a hint of the watercolor effect that the first review complained of, but I don't see evidence of upsampling.

I now think that we need to ask Spreadtrum if the Cloud FX has a worse camera than what was in our Tarako devices.

And if the hardware is the same, we should ask about changes to the driver. If, for example, Spreadtrum changed their driver so that it did real rotation of the images instead of using EXIF orientation, then I expect memory constraints would require them to start with a smaller source image. All of the photos shown in these two Cloud FX reviews were in landscape mode and did not have EXIF orientation. If I could see a raw portrait mode photo from the Cloud FX I could check on this possibility.

There are more sample photos here: http://theaffordable.blogspot.com/2014/09/intex-cloud-fx-more-camera-samples.html  And four more at the very end of this review: http://www.gogi.in/intex-cloud-fx-review.html All of them are in landscape, or are in portrait mode but with EXIF orientation removed.

Bottom line is it looks to me like the Cloud FX has a 800x600 0.5mp camera that is being sold as a 1600x1200 2mp camera.

Let's ask someone with a trained eye to look at the attached images... Peter, could you look at the last 6 attachments (the small details) or at all of the attachments and see if you agree with me that the photos from the posted reviews show images that have been upsampled, while the images from my own Tarako do not?
Flags: needinfo?(pla)
Assignee: nobody → dflanagan
(In reply to David Flanagan [:djf] from comment #21)
> (In reply to Fabrice Desré [:fabrice] from comment #7)
> 
> > Let me try to see if we still have some unboxed ones.
> 
> Did you ever find a new Cloud FX with plastic still on the lens?

No, but I also learned that some devices shipped with a driver mismatched to the onboard sensor :( So not much we could fix on our end there.
Flags: needinfo?(fabrice)
Do you know whether that mismatch could cause the upscaling effects that we see in the photos posted to review sites?

If so, that would explain most of the problem we're seeing here, and indeed it is out of our hands. We could still consider a patch on our end to use sceneMode=night when ambient light is low since that might help in low-light.
Flags: needinfo?(fabrice)
Yes, my understanding is that the driver issue is causing the upscaling effects. But for sure any improvement in low light is welcome!
Flags: needinfo?(fabrice)
If we can't get the driver fixed, we could consider modifying the camera app in gaia so that it takes 800x600 photos instead of 1600x1200. Though without having our hands on the bad phones we can't be certain that those photos wouldn't come out looking upsampled, too.
(In reply to David Flanagan [:djf] from comment #30)
> The photos from the second review have obvious jaggies that look like
> artifacts from a smaller image being upsampled to 1600x1200.  At least one
> of the photos from the first review also has jaggies that seem similar.
> (Other photos from that first review seem too blurry to show any jaggies,
> for other reasons, I suppose).
> 
> When I try to take similar photos with my prototype Tarako device, I do not
> see jaggies like that. I see a hint of the watercolor effect that the first
> review complained of, but I don't see evidence of upsampling.
> 
> I now think that we need to ask Spreadtrum if the Cloud FX has a worse
> camera than what was in our Tarako devices.
> 
> And if the hardware is the same, we should ask about changes to the driver.
> If, for example, Spreadtrum changed their driver so that it did real
> rotation of the images instead of using EXIF orientation, then I expect
> memory constraints would require them to start with a smaller source image.
> All of the photos shown in these two Cloud FX reviews were in landscape mode
> and did not have EXIF orientation. If I could see a raw portrait mode photo
> from the Cloud FX I could check on this possibility.
> 
> There are more sample photos here:
> http://theaffordable.blogspot.com/2014/09/intex-cloud-fx-more-camera-samples.
> html  And four more at the very end of this review:
> http://www.gogi.in/intex-cloud-fx-review.html All of them are in landscape,
> or are in portrait mode but with EXIF orientation removed.
> 
> Bottom line is it looks to me like the Cloud FX has a 800x600 0.5mp camera
> that is being sold as a 1600x1200 2mp camera.
> 
> Let's ask someone with a trained eye to look at the attached images...
> Peter, could you look at the last 6 attachments (the small details) or at
> all of the attachments and see if you agree with me that the photos from the
> posted reviews show images that have been upsampled, while the images from
> my own Tarako do not?

Hi David,

Apologies for the delay - I was away for 2 weeks.

It's hard to give you a definitive answer, but from what I see of your samples:

1) The Tarako prototype's photos look a lot better than the others that you suspect are upsampled
2) The ones that look upsampled are qualitatively _far worse_ than upscaling an image from 800x600 to 1600x1200 in Photoshop (using bilinear or bicubic resampling).  There is a heavy 'watercolour' effect as well as dark outlines or 'halos' around edges that can't be reproduced to anywhere close to that level from simply upscaling.  I suspect it's the quality of the sensor (with the possibility of upscaling as well).

I can show you some samples if you like - let me know.

Peter.
Flags: needinfo?(pla)
Blocks: 1098152
Blocks: 994991
Whiteboard: ux-most-wanted-nov2014
Whiteboard: ux-most-wanted-nov2014 → ux-most-wanted-nov2014, 2x-uxnom
Rob,

I filed this bug specifically in response to the terrible photo quality of the 1.3T tarako devices that shipped in India. Those devices will never be upgraded to 2.x releases, so I'm not sure why this bug is on UX radar.

On the other hand, I think Mike may be working on a similar bug to better handle low light conditions. Mike: is there a bug similar to this one that will go into 2.2?
Flags: needinfo?(rmacdonald)
Flags: needinfo?(mhabicher)
Bug 1052821 exposes meterings modes to JS and changes the default metering mode from "frame-average" to "center-weighted". This means the light meter on Flame will tend to favour the areas being focused on -- either the center of the frame, by default, or wherever the user taps-to-focus.

The app should add a menu to let the user change this mode.
Flags: needinfo?(mhabicher)
Removing ux flags based on David's comments.
Flags: needinfo?(rmacdonald)
Whiteboard: ux-most-wanted-nov2014, 2x-uxnom
I don't think anyone ever figured out how we could update the Tarakos on the market, so there isn't anything I can do here. Unassigning myself.
Assignee: dflanagan → nobody
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.