#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


 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