Bug: Quickcam Express + Motion -> Bad picture

This was originally raised as a support question but after BugReport2005x03x30x011107 was resolved I am 99% sure it will also have resolved this one because the reporter tells that the camera uses the RGB24 palette.

Question

I have a Logitech Quickcam Express connected to the USB port of my PC. The picture is perfect using vidcap (vidcat -d /dev/video0 -f jpeg -o pic.jpg). Then I tried Motion with several parameters but couldn't achieve to get a correct picture. It seems the RGB 8:8:8 is incorrectly decoded, I get the following picture :

With Vidcat, you can see the picture is correct :

.

I tried to activate the subsampling of the Quickcam using qcset subsample=y. Motion didn't work anymore with this option (but subsampling works with Vidcat) so I turned it off. I also tried Pal, NTSC mode without success. I tried to change settings on the camera side using the qcset util but nothing seemed to help. Here are the settings of the camera. I think the problems are related to the "RGB888 packed into 24bit words" field.

Name          : Logitech QuickCam USB
Type          : capture subcapture
Channels      : 1
Audio devices : 0
Maxsize       : 360,296
Minsize       : 32,32

Overlay coords: 0,0
Capture size  : 360,296
Chromakey     : 0
Flags         :

Channel       : 0
Name          : Camera
Tuners        : 0
Flags         :
Type          : camera
Norm          : 47104

Brightness    : 4000
Hue           : 32768
Color         : 32768
Contrast      : 4000
Whiteness     : 32768
Depth         : 24
Palette       : RGB888 packed into 24bit words.

destynova cam1 # lsmod
Module                  Size  Used by
quickcam               73360  -
videodev                6912  -

Version of qc-usb : 0.6.2
Kernel 2.6.10 (Gentoo)
Pentium III Coppermine - 128Mb, Matrox G200

Note

qc-usb readme says that one should use "qcset compatible=3" with Motion. This doesn't work in my case. The most strange thing is that the picture was sometimes correctly decoded, other frames were wrong (moreover, a pink border of about 10 pixels is visible at the bottom)

Environment

Motion version:	3.1.18
ffmpeg version:
Libraries:	curl, xmlrpc, ffmpeg, mysql, postgresql
Server OS:

-- TWikiGuest - 28 Feb 2005

Answer

I do not have the answer. The problem is new to me.

I have asked the Motion Mailing List to give a hand with this one.

I notice that the bad picture and the good picture have different sizes. Did you try 320x240 in Motion?

-- KennethLavrsen - 10 Mar 2005

Answer

> >> I notice that the bad picture and the good picture have different sizes. Did you try 320x240 in Motion?

I tried with this size too, I also get a bad picture. I noticed another weird behaviour, the hue of a bad "dithered" picture changes from time to time. As you can see, the first time I posted the problem, I had some kind of pink/magenta hue. Now when I tried again, I got a blue hue (I didn't notice another hue though). I checked what could produce such strange results. If I turn on the compression in the qc driver, I get an orange/red hue. But if I turn off the compression, the hue doesn't turn back to blue, it remains the same. Maybe all these problems are not related to Motion but the quickcam driver as it is also seems quite bugged, but again, I never had such problems with Vidcat. The way the capture is done is for sure different and incompatible with the qc-usb driver. After playing a while with qcset, I even had another kind of picture..With further investigations, I noticed that the "quality" settings in the QuickCam driver had an impact on the kind of hue/dithering that would appear in the picture.

With "qcset quality=good", I get the following picture :

With "qcset quality=best" :

(motion -a 3 -s 352x288)

I post here the internal registers of the camera with "quality = good" settings, if this may somehow help...

titan testcam # qcset -r
Sensor registers:
    00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00: 08 08 0F 0F 00 00 63 63 00 00 20 20 12 12 01 01
10: 9B 9B 0A 0A 03 03 03 03 4A 4A 5A 5A 65 65 08 08
20: 08 08 08 08 08 08 07 07 00 00 47 47 04 04 08 08
30: 04 04 00 00 10 10 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

STV registers:
      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
 400: 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 420: AA 00 02 00 02
1400: 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1420: AA 00 02 00 02
1440: 00 00 00 20 02 00
1500: 1D B5 A8 95 07 00
15C0: 00 4F 03 01 04 00 00 00 0F 00
1680: 0A
1700: 00
B000: 00

-- Kevin Drapel - 12 Mar 2005

Fix Record.

In video.c the line

if ((loop & 1) == 1)

must be changed to

if ((loop & 1) == 0)

It was a bug introduced in v 3.1.10 when the rgb2yuv420p function was optimized.

The fix will be in 3.1.20_snap5 and 3.2.1_snap12

-- KennethLavrsen - 04 Apr 2005