gyachi-webcam showing inverted colors!

Help
NA
2009-08-24
2013-04-23
  • NA

    NA - 2009-08-24

    Everything works, but the image in gyachi-webcam has the red and blue channels swapped!

    As shown in this screen capture:
    http://ever.mine.nu/gyachi-err/gyachi-webcam-error-02.jpg

     
    • Greg Hosler

      Greg Hosler - 2009-08-25

      can you give me a screen shot of the webcam configuration panel ?

      -G

       
    • NA

      NA - 2009-08-25

      Sure: I'm not sure if you mean the camera settings or the panel under main setup, so here are both:

      http://ever.mine.nu/gyachi-err/gyachi-webcam-panel-setup.jpg

      http://ever.mine.nu/gyachi-err/gyachi-webcam-panel-camera_properties.jpg

      And yes, I notice that the hue slider is at 100% ..however, moving it has no effect, however contrast/brightness/gamma sliders effect the image.

      I've tried saving the hue slider at %50, selecting 'save' and than closing and restarting gyachi-webcam, but hue is always back at %100 again for some reason. Although I don't think this is the problem, as the two channels are completely swapped, where as green is accurate.

      Swapping the channels in the Gimp (of the original flawed image posted) gives the following result:
      http://ever.mine.nu/gyachi-err/gyachi-webcam-error-02swap.jpg

       
    • NA

      NA - 2009-08-25

      Also, I should point out that mplayer is able to capture from the camera properly. Could this be an issue with the fact that I'm using 64bit linux? I just recently upgraded from a years-old fedora install, where gyachi worked fine (although it was a much older version of gyachi-1.0.5)

      Also, this current behavior happens both in gyachi-1.1.71 and in gyachi cvs (as of yesterday)

       
      • Greg Hosler

        Greg Hosler - 2009-08-26

        i doubt it's 32/64 bit related.

        does mplayer have a setting that needed to be adjusted, in order to swap the red/blue colours ?

        gyachi used to have such an option. As  cleaned up / redid the cam property interface, i analyzed this, and it seemed no longer necessary. So now I need to figure out how mplayer auto-detects your colors.

        b.t.w. which camera are you using.?

        All the best,

        -Greg

         
    • NA

      NA - 2009-08-27

      It is a logitech quickcam 4000, using the pwc.ko driver.

      No special options to mplayer: I used

      mplayer -tv noaudio:driver=v4l2:device=/dev/video0:width=320:height=240 tv://

      gyachi-webcam delivers error "Fatal: video format not supported by grab device" if I try to set V4L2 in it, but works (albeit with the swapped color channels) in V4L

      Here is the output from mplayer with both drivers, if it's of any diagnostic help:

      mplayer won't play it at all if I specify driver=v4l, giving error:
      Playing tv://.
      TV file format detected.
      Selected driver: v4l
      name: Video 4 Linux input
      author: Alex Beregszaszi
      comment: under development
      =================================================================
      WARNING: YOU ARE USING V4L DEMUXER WITH V4L2 DRIVERS!!!
      As the V4L1 compatibility layer is broken, this may not work.
      If you encounter any problems, use driver=v4l2 instead.
      Bugreports on driver=v4l with v4l2 drivers will be ignored.
      =================================================================
      Selected device: Logitech QuickCam Pro 4000
      Capabilites: capture
      Device type: 1
      Supported sizes: 160x120 => 640x480
      Inputs: 1
        0: Webcam:  (tuner:0, norm:pal)
      Using input 'Webcam'
      tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
      Unknown norm!
      Error: Cannot set norm!
      Selected input hasn't got a tuner!
      FPS not specified in the header or invalid, use the -fps option.
      No stream found.

      If I use driver=v4l2 with mplayer (which works perfectly) the output is:
      Playing tv://.
      TV file format detected.
      Selected driver: v4l2
      name: Video 4 Linux 2 input
      author: Martin Olschewski <olschewski@zpr.uni-koeln.de>
      comment: first try, more to come ;-)
      Selected device: Logitech QuickCam Pro 4000
      Capabilites:  video capture  read/write  streaming
      supported norms: 0 = webcam;
      inputs: 0 = usb;
      Current input: 0
      Current format: YUV420
      v4l2: ioctl set format failed: Invalid argument
      tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
      Selected input hasn't got a tuner!
      v4l2: Cannot get fps
      v4l2: ioctl set mute failed: Invalid argument
      v4l2: ioctl query control failed: Invalid argument
      [gl] using extended formats. Use -vo gl:nomanyfmts if playback fails.
      ==========================================================================
      Opening video decoder: [raw] RAW Uncompressed Video
      VDec: vo config request - 640 x 480 (preferred colorspace: Planar I420)
      Could not find matching colorspace - retrying with -vf scale...
      Opening video filter: [scale]
      VDec: using Planar I420 as output csp (no 0)
      Movie-Aspect is undefined - no prescaling applied.
      [swscaler @ 0x14b45f0]using unscaled yuv420p -> rgb32 special converter
      VO: [gl] 640x480 => 640x480 BGRA
      Selected video codec: [rawi420] vfm: raw (RAW I420)
      ==========================================================================
      Audio: no sound
      Starting playback...

      And I feel compelled to say a big "thank you" for the attention and support!

       
    • NA

      NA - 2009-08-27

      Oh, a minor error above... the output from mplayer I pasted was with width=640:height=480 as opposed to 320,240 which is in the mplayer command string I had posted near the top. Output is identical except for the differing resolution.

      (i.e:
      Selected device: Logitech QuickCam Pro 4000
      Current format: YUV420
        ...
      Opening video decoder: [raw] RAW Uncompressed Video
      VDec: vo config request - 320 x 240 (preferred colorspace: Planar I420)
      Could not find matching colorspace - retrying with -vf scale...
      Opening video filter: [scale]
      VDec: using Planar I420 as output csp (no 0)
      [swscaler @ 0x34025f0]using unscaled yuv420p -> rgb32 special converter
      Selected video codec: [rawi420] vfm: raw (RAW I420)
      )

       
    • NA

      NA - 2009-08-30

      Barring a more long term solution, is there any way I could hack a simple fix into my local source to swap red and blue?

       
    • NA

      NA - 2009-08-30

      For anyone else having this problem... I found a simple workaround hack.
      in webcam/v4l-fmtconv.c, in function yuv420p_to_rgb24
      I switched the assignments. Webcam now works fine with this hack. Although this clearly doesn't solve the underlying bug, as an interim solution it allows me to use my webcam.

       
    • Greg Hosler

      Greg Hosler - 2009-09-06

      There used to be a button on the camera properties configuration page that used to essentially swap the red-green . It kinds seems to me (without knowing more detail about the hardware involved) that either the driver is returning the colors swapped, or gyachi is using the wrong conversion routine (which could be due to a wrong setting returned from the camera status query, or there could be a bug in the v4l2 conversion libraries.)

      I'll need to do some investigations and get back to you on this.

      -Greg

       
    • NA

      NA - 2009-09-07

      Sure, I'd be happy to help i.e. with any testing, etc, on my hardware if it would be of any benefit to others as far as resolving this bug (whether it is a bug in gyachi or in the driver).

      The same pwc.ko driver worked fine with multiple applications on my old system (albeit an older 32 bit kernel, 2.6.18 iirc). All I've tried it with on my new install is mplayer and gyachi, however.

      Oh, and also. Gyachi only works with v4l, -not- v4l2 mode with this webcam. Whereas mplayer only works with v4l2 mode, not v4l!

      I have to build the kernel with v4l1, as the pwc.ko driver, like many others, doesn't seem to be supported in the kernel configuration if you turn on pure v4l2 mode in the kernel config.

      Additionally, my problem was that the blue and red channels were swapped, not red and green, which caused me to look remarkably like a smurf ;)

       
    • NA

      NA - 2009-09-10

      I also installed kopete to try the webcam functionality there. It also works perfectly, so I don't think it's a problem in the pwc.ko driver.

       
    • Greg Hosler

      Greg Hosler - 2009-09-10

      Hi,

      I pointed this thread to Hans de Goede, author of libv4l, and this is his reply:

      I have such a camera as the reporters, and have tested gyachi under rawhide,
      with this camera both in v4l1 and v4l2 mode, all is fine. It could be that
      they are using an older version of libv4l (there were some bugs), or an older
      version of gyachi, or a version of gyachi compiled without libv4l support.

      with everything up2date, it works fine.

      Regards,

      Hans

       
    • NA

      NA - 2009-09-11

      Well, I'm running ubuntu 9.04 (jaunty) with all updates current. (The only difference from default being that I'm running a custom 2.6.29.6 kernel with tuxonice patches).

      I have ubuntu core package libv4l-0 Version: 0.5.8-1 installed (up to date version)

       
    • NA

      NA - 2009-09-11

      AHA! I noted the prior comment about "or a version of gyachi not built with libv4l support".. and checked ./configure --help ..but no mention of enabling libv4l. Then I ran configure normally, and this time read through all of the output of ./configure and noticed the error:

      "checking for LIBV4L... no"

      Thus, I realized I had to install the libv4l-dev package. Webcam now works perfectly (without the kludge I'd previously hacked), and in both v4l and v4l2 modes!

      It never occured to me that I might be missing a library, because there was no obvious error or warning given by configure, and no apparent mention of this silent dependency in any of the documentation that I could find.

      Perhaps you should add this to the FAQ page, or to the INSTALL readme, or have configure print an obvious warning at the bottom of output if it doesn't find libv4l.

      Like I suspect most people, I don't normally read every output printed from configure as it flies past! I only address an issue if there's an error or warning.

      Anyway, thanks for effort on your part to find a solution! It never even occured to me that gyachi would require an external library for webcam to work, as webcam was already working (albeit improperly, and with no build errors or warnings given) without it! Thus I assumed that the functionality was self-contained to gyachi.

       
      • loell

        loell - 2009-09-11

        "Like I suspect most people, I don't normally read every output printed from configure as it flies past! I only address an issue if there's an error or warning.  "

        heheh, most people don't compile from source ;-) 

         
      • Greg Hosler

        Greg Hosler - 2009-09-11

        well... the problem w/ your suggestion of making this an error (vs a warning) is that not alldistros carry libv4l (though by now, most major ones do). So... I setup ./configure to check for the existence of the library, take advantage it it's there, and default to prior behaviour (which is apparently where your problem stems from) if the library is not there.

        As a point of info, looking at the supplied spec file would have clued you in that libv4l-devel was a build requirement (which would solve your problem :-).

        finally, for those that build from source, as a general rule of thumb, if tere is a package dependency at runtime, then the development version of that package is usually needed to be installed during the build process (so that the code has the means to access the runtime library during compile / link time! :-)

        Glad this got solved, and all the best,

        -Greg

         
  • NA

    NA - 2009-09-12

    Yes, of course I knew I would need the header files to build something that can link ;)

    I thought .spec files were just for rpmbuild, which is for fedora/redhat only. And, yes, if I'd read through all of the configure output the first time around, I might have noticed. My only point being that it is an obscure issue. A summary warning at the -bottom- of the ./configure output or something in the documentation would help!

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks