#11297 NORM 11.3.0: Scratch: Camera quality in xo-1.5 is worst than in os874
Zarro Boogs per Child
bugtracker at laptop.org
Fri Oct 14 17:09:23 EDT 2011
#11297: Scratch: Camera quality in xo-1.5 is worst than in os874
--------------------------------+-------------------------------------------
Reporter: godiard | Owner: saadia
Type: defect | Status: new
Priority: normal | Milestone: 11.3.0
Component: kernel | Version: 1.5-C2
Resolution: | Keywords:
Next_action: diagnose | Verified: 0
Deployment_affected: | Blockedby:
Blocking: |
--------------------------------+-------------------------------------------
Changes (by dsd):
* owner: => saadia
* component: scratch-activity => kernel
Comment:
Scratch requests a variety of formats from the camera and has its own
internal format conversion routines. With libv4l-0.8.3, all of these
requests failed until we hit YUYV, which is what our camera is good at,
and then Scratch converted it to ARGB in the camera plugin.
With libv4l-0.8.4, libv4l's format conversion routines improved greatly,
so that when Scratch first requests RGB24 which is not supported by our
camera, libv4l's conversion kicks in and says "yes we support it" and
switches the camera to RGB565 mode (which we do support), and post-
processes all the data to convert it to RGB24.
Scratch also sets the resolution to 320x240, which is half the dimensions
of the single native resolution supported by this hardware configuration.
via-camera therefore applies hardware scaling to the image to reduce it to
these dimensions but it appears we had never tested this scaling with RGB.
It works fine with YUYV but with RGB you get lots of green noise. The
hardware documentation is very limited here, it does not describe how this
scaling works or how it knows which pixel format it is dealing with. I
guess it does not support scaling of RGB images and treats them as YUYV.
So, test case to reproduce the issue is:
{{{
gst-launch v4l2src ! video/x-raw-rgb,bpp=16,width=320,height=240 !
ffmpegcolorspace ! xvimagesink
}}}
Whereas 640x480 works.
I mailed Jon Corbet to see if he knows anything, if not I guess we will
either disable hardware scaling or disable RGB support at the driver
level. I just tested the latter solution, it works fine as libv4l falls
back to YUYV on the camera and converts it to RGB24 internally, and the
Scratch image then appears fine.
--
Ticket URL: <http://dev.laptop.org/ticket/11297#comment:6>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs
mailing list