Re: reverse engineering pwcx

Re: reverse engineering pwcx

[Albert Cahalan]

> The LavaRnd guys examined the pixels on the actual
> CCD chip.  It's 160x120.  The 'decompression' is
> just interpolation.

First of all, it's not a CCD chip. It's CMOS.

Now, here's a Bayer pattern:

RG
GB
RGRGR
GBGBG
RGRGR
GBGBG

Don't put much faith in the 160x120 number. Suppose
that the chip is in a Bayer pattern, with 160x120
of those. Well, how many pixels is that? Who knows.
You'd sort of have 160x120, but with double the
green data. Since green carries most of the luminance
information, producing a larger image is reasonable.

Suppose the pattern is larger. The "Bayer" name in
the code may well be misleading. Each "pixel" that
was counted could be a 4x4 grid with 6 red subpixels,
8 green subpixels, and 2 blue subpixels. What's that?
You count 160x120, because it looks that way, but
it's 640x480 subpixels.

To correctly convert this to pixels while keeping the
maximum amount of image data, I think you need to
use the sinc() function. Problem is, you're getting
pre-mangled data from the camera. So it gets a bit
more complicated.

BTW, what are the legal problems? I didn't click to
agree on some EULA. I didn't sign an NDA. I don't
see how this could be considered a copy-control or
encryption system. Am I missing something? Maybe
this ought to be a 2-person project?

The code does look easy enough to take apart, even
using plain objdump. I think I'd be doing so now if
I had one of the cameras. (What nerd could resist?)
The decompiler is a much cooler option though.
By using both x86_64 and powerpc, recovery of data
types should improve.

Re: reverse engineering pwcx

[Lee Revell]

On Sat, 2004-08-28 at 12:17, Albert Cahalan wrote:
> > The LavaRnd guys examined the pixels on the actual
> > CCD chip.  It's 160x120.  The 'decompression' is
> > just interpolation.
> 
> Don't put much faith in the 160x120 number. Suppose
> that the chip is in a Bayer pattern, with 160x120
> of those. Well, how many pixels is that? Who knows.
> You'd sort of have 160x120, but with double the
> green data. Since green carries most of the luminance
> information, producing a larger image is reasonable.

Right, as someone else pointed out, this is wrong.

How do you account for the Slashdot poster's assertion that it's
physically impossible to cram 640 x 480 worth of data down a USB 1.1
pipe?

Lee

Re: reverse engineering pwcx

[Albert Cahalan]

On Sat, 2004-08-28 at 12:25, Lee Revell wrote:
> On Sat, 2004-08-28 at 12:17, Albert Cahalan wrote:
>> [somebody]

> > > The LavaRnd guys examined the pixels on the actual
> > > CCD chip.  It's 160x120.  The 'decompression' is
> > > just interpolation.
> > 
> > Don't put much faith in the 160x120 number. Suppose
> > that the chip is in a Bayer pattern, with 160x120
> > of those. Well, how many pixels is that? Who knows.
> > You'd sort of have 160x120, but with double the
> > green data. Since green carries most of the luminance
> > information, producing a larger image is reasonable.
> 
> Right, as someone else pointed out, this is wrong.
> 
> How do you account for the Slashdot poster's assertion that it's
> physically impossible to cram 640 x 480 worth of data down a USB 1.1
> pipe?

640x480 uncompressed 24-bit RGB? It doesn't matter.

The suggestion of a 4x4 JPEG-like transform seems
pretty reasonable. I'd like to see that whitepaper.

Re: reverse engineering pwcx

[Lee Revell]

On Sat, 2004-08-28 at 12:56, Albert Cahalan wrote:
> On Sat, 2004-08-28 at 12:25, Lee Revell wrote:
> > On Sat, 2004-08-28 at 12:17, Albert Cahalan wrote:
> >> [somebody]
> 
> > > > The LavaRnd guys examined the pixels on the actual
> > > > CCD chip.  It's 160x120.  The 'decompression' is
> > > > just interpolation.
> > > 
> > > Don't put much faith in the 160x120 number. Suppose
> > > that the chip is in a Bayer pattern, with 160x120
> > > of those. Well, how many pixels is that? Who knows.
> > > You'd sort of have 160x120, but with double the
> > > green data. Since green carries most of the luminance
> > > information, producing a larger image is reasonable.
> > 
> > Right, as someone else pointed out, this is wrong.
> > 
> > How do you account for the Slashdot poster's assertion that it's
> > physically impossible to cram 640 x 480 worth of data down a USB 1.1
> > pipe?
> 
> 640x480 uncompressed 24-bit RGB? It doesn't matter.
> 
> The suggestion of a 4x4 JPEG-like transform seems
> pretty reasonable. I'd like to see that whitepaper.
> 

This still can't be called 'True 640 x 480' by any reasonable standard. 
Philips' marketing claims exactly this.

So far I have not seen any evididence to refute QuantumG's original
assertion that the reason everyone in the know is being so tight-lipped 
is that releasing source code would prove Philips and/or Logitech guilty
of false advertising.

Lee

Re: reverse engineering pwcx

[Vojtech Pavlik]

On Sat, Aug 28, 2004 at 01:11:28PM -0400, Lee Revell wrote:
> On Sat, 2004-08-28 at 12:56, Albert Cahalan wrote:
> > On Sat, 2004-08-28 at 12:25, Lee Revell wrote:
> > > On Sat, 2004-08-28 at 12:17, Albert Cahalan wrote:
> > >> [somebody]
> > 
> > > > > The LavaRnd guys examined the pixels on the actual
> > > > > CCD chip.  It's 160x120.  The 'decompression' is
> > > > > just interpolation.
> > > > 
> > > > Don't put much faith in the 160x120 number. Suppose
> > > > that the chip is in a Bayer pattern, with 160x120
> > > > of those. Well, how many pixels is that? Who knows.
> > > > You'd sort of have 160x120, but with double the
> > > > green data. Since green carries most of the luminance
> > > > information, producing a larger image is reasonable.
> > > 
> > > Right, as someone else pointed out, this is wrong.
> > > 
> > > How do you account for the Slashdot poster's assertion that it's
> > > physically impossible to cram 640 x 480 worth of data down a USB 1.1
> > > pipe?
> > 
> > 640x480 uncompressed 24-bit RGB? It doesn't matter.
> > 
> > The suggestion of a 4x4 JPEG-like transform seems
> > pretty reasonable. I'd like to see that whitepaper.
> > 
> 
> This still can't be called 'True 640 x 480' by any reasonable standard. 
> Philips' marketing claims exactly this.

If the sensor has 640x480 Bayer half-cells (640x480 green subpixels),
then that's considered as 'true 640x480' by the industry. Green
resolution is 640x480, red and blue resolution is 640x240. A full
640x480 RGB image can be reconstructed in good quality.

And that's what I believe the cameras have - it's damn cheap in CMOS
anyways.

Now about the compression - that'll only take place when streaming (and
the lossiness will depend on the selected frame rate). When taking still
images, you should get the full resolution.

That's at least how most USB 1.1 webcams work - I don't have personal
experience with Philips webcams.

> So far I have not seen any evididence to refute QuantumG's original
> assertion that the reason everyone in the know is being so tight-lipped 
> is that releasing source code would prove Philips and/or Logitech guilty
> of false advertising.

I don't think that's the reason. In the early days of webcams, the
compression method was what was differentiating the different webcam
brands.

When all have basically the same sensor, and the same USB 1.1 bandwidth,
the image quality is given by the compression. And designing a
compression algorithm so that it's both efficient and fits into only a
few logic gates (resulting in a cheap chip) is a challenge.

And the webcam companies were competing to deliver the cheapest webcam
with the best image quality. It's obvious they wanted to hide the
algorithm - copying it is rather easy.

Nowadays, there is no point in hiding it - with USB 2.0 allowing for
uncompressed video, with JPEG encoding chips being a commodity, that
competition point has disappeared.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: reverse engineering pwcx

[Joel Jaeggli]

On Sat, 28 Aug 2004, Lee Revell wrote:

> Right, as someone else pointed out, this is wrong.
>
> How do you account for the Slashdot poster's assertion that it's
> physically impossible to cram 640 x 480 worth of data down a USB 1.1
> pipe?

640x480 = 307200 pixels
x 24 bits = 7372800 bits per frame (.9MB)
x 30 fps = 221184000

so that's 221mb/s for uncompressed 640x480. dv with 16bit pcm is 25Mb/s 
typically which is still a bit more than double what you can reasonably 
push through a usb1.1 port. raw you can push about 1.6 fp/s at 640x480 
through usb so your compression ratio needs to be order of 15 to 1 make 
it fit reasonably with room for overhead.

> Lee
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli  	       Unix Consulting 	       joelja@darkwing.uoregon.edu 
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

Re: reverse engineering pwcx

[Lee Revell]

On Sat, 2004-08-28 at 13:53, Joel Jaeggli wrote:
> On Sat, 28 Aug 2004, Lee Revell wrote:
> >
> > How do you account for the Slashdot poster's assertion that it's
> > physically impossible to cram 640 x 480 worth of data down a USB 1.1
> > pipe?
> 
> 640x480 = 307200 pixels
> x 24 bits = 7372800 bits per frame (.9MB)
> x 30 fps = 221184000
> 
> so that's 221mb/s for uncompressed 640x480. dv with 16bit pcm is 25Mb/s 
> typically which is still a bit more than double what you can reasonably 
> push through a usb1.1 port. raw you can push about 1.6 fp/s at 640x480 
> through usb so your compression ratio needs to be order of 15 to 1 make 
> it fit reasonably with room for overhead.

15 to 1 is impossible without lossy compression.  I am not really a
video expert, but I know that it's impossible to losslessly compress
audio more than 50-75%.  Therefore there is no way it's 'True 640 x 480'
as Philips' marketing claims.  Unless you take 'true' to mean
'interpolated by the driver so your userspace program doesn't have to do
it'.  This is a stretch.

Lee

Re: reverse engineering pwcx

[Lee Revell]

On Sat, 2004-08-28 at 14:04, Lee Revell wrote:
> On Sat, 2004-08-28 at 13:53, Joel Jaeggli wrote:
> > On Sat, 28 Aug 2004, Lee Revell wrote:
> > >
> > > How do you account for the Slashdot poster's assertion that it's
> > > physically impossible to cram 640 x 480 worth of data down a USB 1.1
> > > pipe?
> > 
> > 640x480 = 307200 pixels
> > x 24 bits = 7372800 bits per frame (.9MB)
> > x 30 fps = 221184000
> > 
> > so that's 221mb/s for uncompressed 640x480. dv with 16bit pcm is 25Mb/s 
> > typically which is still a bit more than double what you can reasonably 
> > push through a usb1.1 port. raw you can push about 1.6 fp/s at 640x480 
> > through usb so your compression ratio needs to be order of 15 to 1 make 
> > it fit reasonably with room for overhead.
> 
> 15 to 1 is impossible without lossy compression.

Disregard, Vojtech's post clears things up.

Lee

Re: reverse engineering pwcx

[Helge Hafting]

On Sat, Aug 28, 2004 at 12:17:19PM -0400, Albert Cahalan wrote:
> > The LavaRnd guys examined the pixels on the actual
> > CCD chip.  It's 160x120.  The 'decompression' is
> > just interpolation.
> 
> First of all, it's not a CCD chip. It's CMOS.
> 
> Now, here's a Bayer pattern:
> 
> RG
> GB
> RGRGR
> GBGBG
> RGRGR
> GBGBG
> 
> Don't put much faith in the 160x120 number.

There's no need for faith or speculation here.
Put the chip under a microscope and count the pixels,
or rather measure their size and estimate their number.

Helge Hafting

Re: reverse engineering pwcx

[Paul Jakma]

On Sun, 29 Aug 2004, Helge Hafting wrote:

> There's no need for faith or speculation here.
> Put the chip under a microscope and count the pixels,
> or rather measure their size and estimate their number.

The lavarnd guy did and counted 160x120:

 	http://slashdot.org/comments.pl?sid=119578&cid=10091208

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
"You don't go out and kick a mad dog.  If you have a mad dog with rabies, you
take a gun and shoot him."
-- Pat Robertson, TV Evangelist, about Muammar Kadhafy

Re: reverse engineering pwcx

[Albert Cahalan]

On Mon, 2004-08-30 at 03:42, Paul Jakma wrote:
> On Sun, 29 Aug 2004, Helge Hafting wrote:
> 
> > There's no need for faith or speculation here.
> > Put the chip under a microscope and count the pixels,
> > or rather measure their size and estimate their number.
> 
> The lavarnd guy did and counted 160x120:
> 
>  	http://slashdot.org/comments.pl?sid=119578&cid=10091208

Unless he explains a bit better, there's no reason
to assume he counted correctly. There may be a larger
pattern that was counted by mistake. For example,
there may be 160x120 red-sensing sub-pixels. He could
have counted only that.

Also, there is more than one type of sensor that can
be fitted to these webcam chips. They may vary.

Re: reverse engineering pwcx

[dulle]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; CHARSET=X-UNKNOWN; FORMAT=flowed, Size: 1643 bytes --]

On Mon, 30 Aug 2004, Albert Cahalan wrote:

> On Mon, 2004-08-30 at 03:42, Paul Jakma wrote:
>> On Sun, 29 Aug 2004, Helge Hafting wrote:
>>
>>> There's no need for faith or speculation here.
>>> Put the chip under a microscope and count the pixels,
>>> or rather measure their size and estimate their number.
>>
>> The lavarnd guy did and counted 160x120:
>>
>>  	http://slashdot.org/comments.pl?sid=119578&cid=10091208
>
> Unless he explains a bit better, there's no reason
> to assume he counted correctly. There may be a larger
> pattern that was counted by mistake. For example,
> there may be 160x120 red-sensing sub-pixels. He could
> have counted only that.
>
> Also, there is more than one type of sensor that can
> be fitted to these webcam chips. They may vary.

Yes, some have cmos, some have CCDs.

Beside, I am a bit puzzled by the credit that has been
given to that slashdot comment, when a simple search  on
"ccd chip logitech 3000 pro"  provides  a  link  on  the
description of the CCD chip inside that  cam  in  a  few
clicks :

http://www.sony.net/Products/SC-HP/new_tec/ccd/icx098.html

2  more  clicks  on  Sony's  site  give  acces  to   the
datasheets of  the  different  versions  of  the  icx098
(color or b/w).

And that was the hard  way:  if  you  search  "ccd  chip
philips webcam" you have the  reference  on  the  result
page and access to the specs on the first site returned.

http://www.astrosurf.com/benschop/APEquipment.htm

Did I mention icx098 is a 640x480 CCD chip, whatever the
version ?

-- François Meyer
http://dulle.free.fr/alidade/galerie.php?maxim=12

reverse engineering pwcx

[QuantumG]

Having watched the discussion around pwcx since the first posting, I 
thought I would take a look at libpwcx.a.  It consists of 3 .o files 
each containing full symbol information and in total a *very* small 
amount of code.  There is no secret algorithm or complex image 
processing in this code.  Having worked on reverse engineering a complex 
audio processing application (see our paper Using a Decompiler for 
Real-World Source Recovery, to appear WCRE 2004), I expected to see some 
serious floating point calculations or at least something recognisable 
as a FFT or some other known algorithm.  There is none of this in the 
pwcx driver.   I could provide complete decompiled source code for this 
binary, however due to the legal questions I'd rather just say that 
there is really not a lot of effort required here to black box this 
driver and replicate what it is doing.  The biggest job will be 
deciphering the two or three large tables used in the decompression 
operations.

The specific issue of pwcx dealt with I'd really like to ask why 
companies perfer to release binary drivers over open source drivers.  A 
Linux kernel driver is really easy to decompile.  There's a number of 
factors that make this so, especially the large amount of symbols 
generally left in binary drivers, but mainly the fact that kernel 
drivers are by design small contained pieces of code.  Also, they are 
generally written in straight C with the only function pointers being 
well documented interfaces (and the function pointers are not changed 
dynamically).  Compared to say, a win32 application written in C++ with 
all that stdcall/fastcall stuff, a linux kernel module is a joy to 
decompile.  So why bother releasing a binary only driver?  The company 
is not protecting its intellectual property.  If an amature like me, who 
knows nothing about web cams, can understand this driver than surely 
someone at one of Philips' competitors reverse engineered and understood 
this algorithm within weeks of the drivers for this camera hitting the 
market.  I'm sure Philips' knows this so why force Nemosoft to sign an 
NDA?  And more importantly, why not let the community maintain this driver?

Trent Waddington
Decompiler maintainer, http://boomerang.sourceforge.net/

Re: reverse engineering pwcx

[QuantumG]

Craig Milo Rogers wrote:

>	Hmmm... a poster on Slashdot claims that entropy measurements
>imply that the pwcx code is interpolating rather that truly
>decompressing.  Again, that's integer math and table lookups.
>  
>

http://www.amazon.com/exec/obidos/tg/detail/-/B00005R098/102-7619892-0201738?v=glance

claims that the Logitech Quickcam Pro 3000 is a "True 640 x 480 
resolution video capture" which is now clearly false.

It would appear I have found an answer to my question.  The reason 
Philips made Nemosoft sign an NDA was not to hide proprietory 
information from their competitors.  It was to hide the fact that they 
were misrepresenting the resolution of their cameras to their 
customers.  No wonder Nemosoft did not feel right about opening this 
module even after the NDA expired, he would be telling the world their 
dirty little secret.  Of course I'm sure this was common knowledge to 
all those people who work in robotics and always demand an uncompressed 
stream from the camera.

Trent Waddington
Decompiler maintainer, http://boomerang.sourceforge.net/

Re: reverse engineering pwcx

[Craig Milo Rogers]

On 04.08.28, QuantumG wrote:
> Craig Milo Rogers wrote:
> 
> >	Hmmm... a poster on Slashdot claims that entropy measurements
> >imply that the pwcx code is interpolating rather that truly
> >decompressing.  Again, that's integer math and table lookups.
> > 
> >
> 
> http://www.amazon.com/exec/obidos/tg/detail/-/B00005R098/102-7619892-0201738?v=glance
> 
> claims that the Logitech Quickcam Pro 3000 is a "True 640 x 480 
> resolution video capture" which is now clearly false.

	If the "now clearly false" is meant to be a consequence of the
entropy measurements poster I referred to, I wouldn't jump the gun.
On reflection, it's entirely natural for a decompressed stream to
examine less entropy than the corresponding compressed stream!

					Craig Milo Rogers

Re: reverse engineering pwcx

[Lee Revell]

On Fri, 2004-08-27 at 23:35, Craig Milo Rogers wrote:
> On 04.08.28, QuantumG wrote:
> > Craig Milo Rogers wrote:
> > 
> > >	Hmmm... a poster on Slashdot claims that entropy measurements
> > >imply that the pwcx code is interpolating rather that truly
> > >decompressing.  Again, that's integer math and table lookups.
> > > 
> > >
> > 
> > http://www.amazon.com/exec/obidos/tg/detail/-/B00005R098/102-7619892-0201738?v=glance
> > 
> > claims that the Logitech Quickcam Pro 3000 is a "True 640 x 480 
> > resolution video capture" which is now clearly false.
> 
> 	If the "now clearly false" is meant to be a consequence of the
> entropy measurements poster I referred to, I wouldn't jump the gun.
> On reflection, it's entirely natural for a decompressed stream to
> examine less entropy than the corresponding compressed stream!
> 

Please see this slashdot thread:

http://linux.slashdot.org/comments.pl?sid=119578&threshold=3&mode=flat&commentsort=0&op=Change

The LavaRnd guys examined the pixels on the actual CCD chip.  It's
160x120.  The 'decompression' is just interpolation.

Lee

Re: reverse engineering pwcx

[Vojtech Pavlik]

On Fri, Aug 27, 2004 at 11:49:00PM -0400, Lee Revell wrote:
> On Fri, 2004-08-27 at 23:35, Craig Milo Rogers wrote:
> > On 04.08.28, QuantumG wrote:
> > > Craig Milo Rogers wrote:
> > > 
> > > >	Hmmm... a poster on Slashdot claims that entropy measurements
> > > >imply that the pwcx code is interpolating rather that truly
> > > >decompressing.  Again, that's integer math and table lookups.
> > > > 
> > > >
> > > 
> > > http://www.amazon.com/exec/obidos/tg/detail/-/B00005R098/102-7619892-0201738?v=glance
> > > 
> > > claims that the Logitech Quickcam Pro 3000 is a "True 640 x 480 
> > > resolution video capture" which is now clearly false.
> > 
> > 	If the "now clearly false" is meant to be a consequence of the
> > entropy measurements poster I referred to, I wouldn't jump the gun.
> > On reflection, it's entirely natural for a decompressed stream to
> > examine less entropy than the corresponding compressed stream!
> > 
> 
> Please see this slashdot thread:
> 
> http://linux.slashdot.org/comments.pl?sid=119578&threshold=3&mode=flat&commentsort=0&op=Change
> 
> The LavaRnd guys examined the pixels on the actual CCD chip.  It's
> 160x120.  The 'decompression' is just interpolation.

It's hard to believe this. I'd believe it if there was supposed to be a
320x240 chip (or even more probably 384x288 (QCIF)), as those are rather
common and with proper scaling up from the Bayer RGB pattern you can do
a rather good interpolation to 640x480 or 768x576.

But 160x120 sounds pretty ridiculous. It still would be possible to
scale that to 640x480 smoothly, but the image would be obviously blurry
and just awful even with avanced Bayer-based scaling techniques.

If Philips really does that, and succeeds, then I see the reason to
protect those methods, as it would allow the competition with better
sensors to scale to even higher resolutions (heh, my iBot2 webcam would
then be a 2560x1920 camera - that's 5 megapixels!).

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: reverse engineering pwcx

[Chris Meadors]

Vojtech Pavlik wrote:

> But 160x120 sounds pretty ridiculous. It still would be possible to
> scale that to 640x480 smoothly, but the image would be obviously blurry
> and just awful even with avanced Bayer-based scaling techniques.

That sounds about right.  At 640x480 the QuickCam 3000 is an awful 
blurry mess.  Though I think the actual pixel count would be a multiple 
(divisor) of CIF, because in the nCIF resolutions it seems to expose 
more pixels.

Re: reverse engineering pwcx

[QuantumG]

Craig Milo Rogers wrote:

>	If the "now clearly false" is meant to be a consequence of the
>entropy measurements poster I referred to, I wouldn't jump the gun.
>On reflection, it's entirely natural for a decompressed stream to
>examine less entropy than the corresponding compressed stream!
>  
>

First let me apologize to the list.  I get carried away now and then :)

Actually I was refering to the fact that these algorithms are not 
"decompression" in any way shape or form.  These cameras don't capture 
640x480 images, compress them in hardware, transfer the data over a USB 
cable for the driver to then "decompress".  They capture at some lower 
resolution (160x120 has been claimed) and the driver simply interpolates 
the data to produce the claimed resolution.  There is nothing "true" 
about the 640x480 resolution at all.

So yeah, Logitech is making false claims to their customers and seeing 
as they get their chips from Philips I'm thinking they are responsible.

Trent

Re: reverse engineering pwcx

[Vojtech Pavlik]

On Sat, Aug 28, 2004 at 01:14:16PM +1000, QuantumG wrote:

> Craig Milo Rogers wrote:
> 
> >	Hmmm... a poster on Slashdot claims that entropy measurements
> >imply that the pwcx code is interpolating rather that truly
> >decompressing.  Again, that's integer math and table lookups.
> 
> http://www.amazon.com/exec/obidos/tg/detail/-/B00005R098/102-7619892-0201738?v=glance
> 
> claims that the Logitech Quickcam Pro 3000 is a "True 640 x 480 
> resolution video capture" which is now clearly false.
> 
> It would appear I have found an answer to my question.  The reason 
> Philips made Nemosoft sign an NDA was not to hide proprietory 
> information from their competitors.  It was to hide the fact that they 
> were misrepresenting the resolution of their cameras to their 
> customers.  No wonder Nemosoft did not feel right about opening this 
> module even after the NDA expired, he would be telling the world their 
> dirty little secret.  Of course I'm sure this was common knowledge to 
> all those people who work in robotics and always demand an uncompressed 
> stream from the camera.

Well, it's definitely no surprise, you simply can't push the
uncompressed stream through USB1.1.

Us in robotics, we use the iBot2 from Orange Micro, which is an USB2.0
webcam working nicely with Linux at 30fps, 640x480, truecolor,
uncompressed.

So I don't think that Philips would really be able to "hide" this fact
by putting the decompressors into a binary only module - everybody knows
the compression must be lossy to allow for this high a compression
ratio.

Also, it's quite obvious that there is a big tradeoff between image
quality and algorithm complexity - it might be possible do do JPEG
compression in the webcam at full framerate and a reasonably low price,
but simpler algorithms with worse image quality still be well usable and
make the price even lower.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: reverse engineering pwcx

[Clem Taylor]

QuantumG wrote:
> There is no secret algorithm or complex image processing in this
> code.  Having worked on reverse engineering a complex audio
> processing application (see our paper Using a Decompiler for
> Real-World Source Recovery, to appear WCRE 2004), I expected to see
> some serious floating point calculations or at least something
> recognisable as a FFT or some other known algorithm.

I think you need to look a little closer. This type of decompression is 
surely not going to be done with floating point (can you even do 
floating point ops in the kernel?).

This class of camera chip uses a greatly simplified JPEG like 
compression. The compression is a 4x4 DCT (JPEG uses a 8x8 DCT), a 
quantize step and some sort of simple VLC. The algorithm was chosen to 
be easy to implement in an absolutely minimal number of gates. At this 
point true JPEG encode hardware is enough of a commodity that it would 
be silly not to use JPEG in a new design.

I'm pretty sure this class of camera chip uses a 4x4 DCT and some sort 
of VLC. Most of the meat of the decoder would be table lookups to decode 
the symbols and then a small multiply accumulate loop to do the inverse 
DCT and another series of table lookups and multiplies to do the inverse 
quant. Pretty basic stuff at this point.

The white paper I read a while back on this chipset family had been out 
of NDA for a number of years, so I was never sure why the pwcx driver 
wasn't opened up. A competitor wouldn't gain much knowing the exact 
details of the decompression algorithm. If I was a competitor designing 
a new webcam chip, I wouldn't waste my time reverse engineering Philips 
compression scheme, I'd just use JPEG and be done with it.

Has anyone even asked Philips if they would be willing to open up the 
algorithm? Maybe they would have said NO a few years ago, but at this 
point does it matter?

                    --Clem

Re: reverse engineering pwcx

[Wouter Van Hemel]

On Sat, 28 Aug 2004, Clem Taylor wrote:

> [...]

> Has anyone even asked Philips if they would be willing to open up the 
> algorithm? Maybe they would have said NO a few years ago, but at this point 
> does it matter?
>

I tried yesterday by phone and email, so far I have been unable to obtain 
a definite phone number for someone who actually is responsible for the 
drivers; and I have not yet received any answers to my email to their 
customer service. I will try again on Monday, through their Belgian 
division (so as to not piss off the same people too much), as I don't think 
there's much going on in the weekend. Their tech support did ask me about 
the Linux distribution, kernel version and XFree version, so they have at 
least heard about Linux. :)

It would help a great deal if Nemosoft could give me a contact address. 
Nemosoft, if you read this, could you help me out? Or perhaps try to reach 
your contact at Philips yourself with the question if any closed source is 
still a necessity - a lot of people would be grateful for a definite 
answer, I'm sure (not in the least yourself, I guess).

Perhaps there is somebody on this list who works at Philips and can give 
me a reply in private?