Ask / Submit

[Request] Improve picture quality of default camera app

asked 2018-06-09 07:59:20 +0300

lachs0r gravatar image

The default camera app is essentially useless. To fix this, I suggest the following:

  • Expose denoiser setting. Or just disable it entirely because its quality is extremely poor. It smears details and absolutely destroys the chroma channels. No, better PSNR does not mean better quality.
  • In fact, disable all image post processing if possible. The basic app should not do any of that, and 99% of the time pictures look better without it. Leave that job to other apps.
  • Expose compression/format settings. The default JPEG compression ruins every picture, which is a shame especially for those who bought an Xperia X for its camera.
  • Remove resolution limit on phones like Xperia X. Apps like MiracuCam correctly detect available camera resolutions, so there’s no reason the default app shouldn’t. It is already possible to get it to recognize higher resolutions by editing /etc/dconf/db/vendor.d/jolla-camera-hw.txt, but none of this should be hardcoded in some platform-specific config file.
edit retag flag offensive close delete

1 Answer

Sort by » oldest newest most voted

answered 2018-06-09 13:31:07 +0300

Andy Branson gravatar image

updated 2018-06-09 13:31:22 +0300


Thanks for your feedback. It would be good to improve the camera experience in Sailfish.

I think the original design decisions here were aimed at providing a basic camera app with which casual users could take quick snaps without having to worry about too many options or features, and I can't see that changing any time soon. I think what's needed here is a second 'advanced' camera app managed by the community that can have all the bells and whistles we want. But that's a fair bit of work, in the meantime maybe we could come up with some tweaks for advanced users, or even add some extra ones.

The Sailfish camera stack is a little bit complicated, as it has to wrap up the underlying Android/AOSP camera drivers for GStreamer (in droidmedia and gst-droid), which serves as a backend for QtMultimedia, which is then used by the QML camera app. There is some functionality that is implemented in the droid/gstreamer side but not exposed in QtMultimedia, and not all of that is exposed in the Camera app either. Out of the whole stack, only the Camera app itself and the blobs in the android underneath are closed source, so there's lots of potential for community enhancements if anyone's interested in having a go. With a new camera app there'd be potential to tweak almost everything, though that will always be within the limits of what the droid camera driver blobs provide.

Your points:

  1. Denoise - this is enabled through a gst-droid 'quirk' which can be found in /etc/gst-droid/gstdroidcamsrcquirks.conf. During hw adaptation development we felt that we got better pictures with this quirk enabled, so I don't think the default will be changed, but feel free to remove the [image-noise-reduction] section to disable it if you prefer. I noticed there's a second denoise algorithm mentioned in the camera params of the Xperia X called 'Temporal denoise' which perhaps we could allow as another quirk or as an alternative mode for the current one.
  2. I don't think we explicitly enable any extra image processing, but if there's anything that's on by default that you think should be switched off then let me know and I'll investigate.
  3. Tweaking compression setting isn't something for the app itself, but it might be a good idea to add as a config setting. I'll have a look at adding that.
  4. Checking the dconf file on the X, I see that the primary camera does have a higher value available: 5984x3392. Good find! It was previously set to the highest live-snapshot size, which is a feature that we don't yet support so I'll bump that up for the next release. I'm not exactly sure why the resolutions are hard-coded like this - I think it might have been partly to optimize camera startup times and also because in the past certain devices declared resolutions that they weren't actually capable of using nicely. In the case of the Xperia we don't make the top 4k video resolution available because we couldn't get good encoding performance out of it. I'd like to move to a more dynamic resolution querying camera if we get chance, but it's a non-trivial change.



edit flag offensive delete publish link more



Thx for the very interesting answer!

wosrediinanatour ( 2018-06-09 13:56:52 +0300 )edit

Thanks for the reply. I see some issues with having a separate advanced camera app when it comes to button actions and the recently added lockscreen integration in particular. Ideally, the default camera app should be community-managed and get all the basics right so that we do not end up with a dozen bolt-on camera apps but rather a dozen apps to manage and edit photos :)

In any case, I can understand not wanting to add too many options, but please do not assume that your average smartphone user has the intelligence and attention span of a gold fish. Know your audience, and don’t attempt to target some imaginary average Joe. Besides, TVs for example are loaded with image processing settings, and most people will just leave them at their defaults, whereas others are very grateful for the option to turn off the silly oversharpening and oversaturation.

lachs0r ( 2018-06-09 14:15:07 +0300 )edit

I don't think it's a question of intelligence, I think most people just aren't that much into photography to want that much out of a phone camera, and many that are have an SLR for taking their photos. It's just a bit niche. But the TV example is a good one:

It'd be great if the default Camera app could be made open source and collaborated on, and I've been pushing for that. Maybe one day it will happen, but a community app is a more realistic possibility in the short term. I think the camera button and the lockscreen role are even doable for a full camera app. But there's another option - we add more config options to the middleware and have a second app to tweak those from beneath without the camera app needing to even know. It wouldn't be much good for things that need to be switched on and off live like filters/hdr etc but there are lots of other options available.

I hadn't heard of that MiracuCam app before, and assumed it was an Android app until I saw the screenshot other post you'd been commenting on. It's really nice! Great work, @peterwoelflingseder ! Those live preview modes are a good example of one of the things exposed in the middleware but not the Jolla app, and I kind of understand that because with the possible exception of greyscale tit's really not mainstream functionality. Is this app open-source? Are there any additional settings available in the Camera HAL that we could expose to Qt to be used by this or other apps?

Andy Branson ( 2018-06-09 15:09:11 +0300 )edit
Login/Signup to Answer

Question tools



Asked: 2018-06-09 07:59:20 +0300

Seen: 391 times

Last updated: Jun 09 '18