reverse engineering pwcx
Quoted 3 lines
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.
Quoted 10 lines · Albert Cahalan
Quoted 3 lines
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
Quoted 14 lines · Lee Revell
Quoted 6 lines · Albert Cahalan
[somebody]
Quoted 3 lines
The LavaRnd guys examined the pixels on the actual CCD chip. It's 160x120. The 'decompression' is just interpolation.
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 17 lines · Albert Cahalan
Quoted 16 lines · Lee Revell
Quoted 6 lines · Albert Cahalan
[somebody]
Quoted 3 lines
The LavaRnd guys examined the pixels on the actual CCD chip. It's 160x120. The 'decompression' is just interpolation.
Quoted 6 lines
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.
Quoted 9 lines
Quoted 3 lines
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
Quoted 22 lines · Lee Revell
Quoted 21 lines · Albert Cahalan
Quoted 19 lines · Lee Revell
Quoted 6 lines · Albert Cahalan
[somebody]
Quoted 3 lines
The LavaRnd guys examined the pixels on the actual CCD chip. It's 160x120. The 'decompression' is just interpolation.
Quoted 6 lines
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?
Quoted 8 lines
Quoted 5 lines
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.
Quoted 4 lines
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.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 5 lines · Lee Revell
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.
Quoted 8 lines
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 1 line
-------------------------------------------------------------------------- Joel Jaeggli Unix Consulting [email protected] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Quoted 10 lines · Joel Jaeggli
Quoted 4 lines · Lee Revell
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
Quoted 5 lines
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
Quoted 11 lines · Lee Revell
Quoted 10 lines · Joel Jaeggli
Quoted 4 lines · Lee Revell
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
Quoted 7 lines
Quoted 5 lines
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
Quoted 8 lines · Albert Cahalan
Quoted 3 lines
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:
Quoted 8 lines
RG
GB
RGRGR
GBGBG
RGRGR
GBGBGDon'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
Quoted 3 lines · Helge Hafting
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,
Signature · 5 lines
Paul Jakma [email protected] [email protected] 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
Quoted 9 lines · Paul Jakma
Quoted 3 lines · Helge Hafting
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:
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.
Quoted 11 lines · Albert Cahalan
Quoted 9 lines · Paul Jakma
Quoted 3 lines · Helge Hafting
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:
Quoted 8 lines
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