maemo.org Bugzilla – Bug 7993
User-facing camera displays many dead pixels and low/no noise reduction
Last modified: 2010-10-03 00:43:07 UTC
You need to
before you can comment on or make changes to this bug.
EXACT STEPS LEADING TO PROBLEM:
1. Use the Mirror app (Extras) to access user-facing camera display
1MP, but clean(ish) output.
There are several dead pixels on the screen and little to no noise reduction of
This bug is an outcome of Bug #5663.
A solution would be maybe to hook into the noise reduction functions originally
intended for the main cam (harnessing functionality like the one in the ipp
Just encountered this bug, while trying to port my application that uses front
cameras to maemo.
This pretty much makes the front camera utterly unusable for pretty much
Some people reported a better camera output using GTalk video conversation.
Sorry, I lost the link to the thread, it is googlable though. Having a google
account I had no chance to check it with somebody for some reason. But I'm
ready to become a 'counterpart' for the videocheck: I'm living GMT+3 time; drop
me a line with your gmail if interested
Internal comment: "This cannot be fixed in the software due to hardware
(In reply to comment #4)
> Internal comment: "This cannot be fixed in the software due to hardware
Interesting, because the camera used to yield better results (aside from the
dark band on the side). Once the dark band was "fixed," the quality of the
output became worse. Sure seems like a software issue to me.
So does this mean no official use of the front-facing camera on the N900 due to
"hardware limitations"? No video conferencing? That's pretty heartbreaking. I
assumed we'd get front-facing video apps eventually. This bug's resolution
sounds like the developers have completely given up on the front-facing cam.
Okay, how about making this at least into a 'generic gstreamer noise/hot pixel
removal element' enhancement ? Can we have Nokia support for that ?
I am really disappointed and feel this is a marketing scam now. The
prototype's front camera worked well. The retail one's don't.
I think a class action suit for a recall may be necessary here.
"We cannot reproduce this unless in very dark (<50 lx) conditions.
Our latest releases were with acceptable quality.
Could you please share any videos or frames in order to observe the reported
(In reply to comment #9)
> "We cannot reproduce this unless in very dark (<50 lx) conditions.
> Our latest releases were with acceptable quality.
> Could you please share any videos or frames in order to observe the reported
What would be the preferred method of capturing a frame from the front-facing
camera (i.e., to provide something that's "official" in regards to producing
the best possible quality)?
Can we take the 50lx figure as an official limit or reference light level ? A
quick check gives me 300-400lx when pointed to the window (sunlit street at
15h) and can easily get below 50lx when pointed away from the window or a
bright light source (which is generally how it's used). I dare not measure the
values when it's not broad daylight :)
(In reply to comment #10)
> What would be the preferred method of capturing a frame from the front-facing
> camera (i.e., to provide something that's "official" in regards to producing
> the best possible quality)?
I've asked this twice now internally and am still waiting for an answer from
"Apologies for the late answer.
You can use the /dev/video1 device which conforms to V4L2 API. Yavta is
AEWB won't be available this way, though.
AEWB is works with gst-launch though, something like this, untested:
gst-launch-0.10 v4l2camsrc device=/dev/video1 num-buffers=10 !
"video/x-raw-yuv, width=640, height=480, framerate=(fraction)3003/100" !
jpegenc ! filesink location=image.jpg