MLUG: Re: [MLUG] Failed Webcam Install + Also Jpeg Encoding
Re: [MLUG] Failed Webcam Install + Also Jpeg Encoding
Email address obfuscation in effect -- please click here to turn it off.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thanks..   Unfortunately, mine is not a QuickCam Messenger, it's a 
QuickCam IM, which isn't even listed on their website (what a kick in 
the pants...  It cost about double what the Messenger did, and they 
don't even have a driver download for it for Windoze.)  Anyways... It 
has a completely different device code that the Messenger, and none of 
the sites I've found list it in their 'supported device codes' section.  
I believe it has a completely different CMOS (true 640x480  .. I don't 
recall what the Messenger is... maybe the same), and a different chip.

This is one of the websites I mentioned (not by name) in my missive.  
Like I said, that site still says 'Compressed format is still unknown'.  
That's not strictly true if you look here

http://www.informatik.uni-oldenburg.de/~delwi/quickcam/

At the bottom there's a section titled "Compression" with the following 
paragraph.

The Logitech Quickcam Web can deliver their images in compressed format. 
The image format is a kind of JPEG, but without headers describing the 
encoding. Instead the encoding is fixed. Every block starts with a bit 
selecting the quantizer scale and 10 bits representing the zeroth 
element of the DCT matrix. After this the huffman codes follow. Here is 
the huffman table 
<http://www.informatik.uni-oldenburg.de/%7Edelwi/quickcam/huffman-table>. 
The last element is marked by the huffman code 0110. Before every fourth 
block (i.e. also before the first) there is a four bit number that has 
to do with the quantizer scale, but it is always 7 in my experiments. 
The file decode-lvc.c 
<http://www.informatik.uni-oldenburg.de/%7Edelwi/quickcam/decode-lvc.c> 
contains the code interpreting the huffman blocks and sending the result 
through an Inverse DCT, do a YUV transformation and return the RGB pixels.
------------------------------------------------------------------------

Other sites on the subject
http://qce-ga.sourceforge.net/
http://wwwbode.cs.tum.edu/~acher/quickcam/quickcam.html

Nimrod Levy wrote:

>This is really interesting because I have a Logitech Quickcam
>Messenger that would only work in Windows (except on one XP machine,
>but that's a different story).  I recently (2 days ago) switched
>entirely from FreeBSD to Arch Linux just so I could compile and a
>driver I found for this camera.
>
>I don't know what kind of camera you have, but this works reasonably
>well on mine.  Not the best quality, but it seems to work with
>gnomemeeting fine.  Microphone too.  I think the top button even shows
>up as an input device.
>
>Here's the URL for the driver.
>http://home.mag.cx/messenger/
>
>--
>Nimrod
>
>On Fri, 11 Feb 2005 14:43:37 -0600, Christian M. Cepel
><EMAIL:PROTECTED> wrote:
>  
>
>>After educating myself a bit last night, I learned that there is no hope
>>of using my Logitech QuickCam IM with *nix.  There are no drivers
>>available, and it's beyond the scope of this hobby for me to sit down
>>and write drivers.
>>
>>There are drivers for lots of other QuickCam cams, but not this newer
>>one that has some special hardware for recording video.
>>
>>In hindsight this was the first thing I should have done, not the
>>last... I guess I just saw 'QuickCam' support and figured....  well... I
>>figured wrongly.
>>
>>Also, I posted a while back wondering why I was getting macropixeling on
>>images that were 100% quality Jpegs.
>>
>>Turns out it's not the software.  It's the chip in the cam.  It's
>>applying huffman encoding and quantizing every 4th or 8th bit before the
>>image data leaves the cam.  The reason for this?  Less bandwidth across
>>the USB cable... Considering that even with this turned on it pretty
>>much sucks down all the available bandwith across the USB buss (You
>>can't have another device on that buss and expect it to function),
>>having it NOT turned on would make video at 640x480 impossible.
>>Unfortunately I don't want video... I want a snapshot every 15 - 30
>>seconds, but alas, it's not a configurable option.
>>
>>I did find one gentleman who had reverse engineered what had previously
>>been an unknown encoding algorithm, and as far as I can tell wrote a
>>driver to prevent the encoding (or is it just to decode it?  I didn't
>>completely understand).
>>
>>Anyways.. I guess I get to take it back to Win2k tonight.
>>--
>>
>>|Christian Marcus Cepel           | And the wrens have returned &
>>EMAIL:PROTECTED icq:12384980 | are nesting; In the hollow of
>>371 Crown Point, Columbia, MO    | that oak where his heart once
>>65203-2202 573.999.2370          | had been; And he lifts up his
>>Computer Support Specialist, Sr. | arms in a blessing; For being
>>University of Missouri-Columbia  | born again. --Rich Mullins|
>>
>>_______________________________________________
>>members mailing list
>>EMAIL:PROTECTED
>>http://mlug.missouri.edu/mailman/listinfo/members
>>
>>    
>>
>_______________________________________________
>members mailing list
>EMAIL:PROTECTED
>http://mlug.missouri.edu/mailman/listinfo/members
>  
>


-- 

|Christian Marcus Cepel           | And the wrens have returned &
EMAIL:PROTECTED icq:12384980 | are nesting; In the hollow of
371 Crown Point, Columbia, MO    | that oak where his heart once
65203-2202 573.999.2370          | had been; And he lifts up his
Computer Support Specialist, Sr. | arms in a blessing; For being
University of Missouri-Columbia  | born again. --Rich Mullins|


_______________________________________________
members mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/members