From: Vojtech Pavlik <vojtech@suse.cz>
To: Lee Revell <rlrevell@joe-job.com>
Cc: Albert Cahalan <albert@users.sf.net>,
linux-kernel mailing list <linux-kernel@vger.kernel.org>,
clemtaylor@comcast.net, qg@biodome.org, rogers@isi.edu
Subject: Re: reverse engineering pwcx
Date: Sat, 28 Aug 2004 20:05:13 +0200 [thread overview]
Message-ID: <20040828180511.GA3916@ucw.cz> (raw)
In-Reply-To: <1093713088.8611.30.camel@krustophenia.net>
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
next prev parent reply other threads:[~2004-08-28 18:05 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-28 16:17 reverse engineering pwcx Albert Cahalan
2004-08-28 16:25 ` Lee Revell
2004-08-28 16:56 ` Albert Cahalan
2004-08-28 17:11 ` Lee Revell
2004-08-28 18:05 ` Vojtech Pavlik [this message]
2004-08-28 17:53 ` Joel Jaeggli
2004-08-28 18:04 ` Lee Revell
2004-08-28 18:08 ` Lee Revell
2004-08-29 21:04 ` Helge Hafting
2004-08-30 7:42 ` Paul Jakma
2004-08-30 12:52 ` Albert Cahalan
2004-08-30 20:23 ` dulle
-- strict thread matches above, loose matches on Subject: below --
2004-08-28 0:52 QuantumG
[not found] ` <20040828012055.GL24018@isi.edu>
[not found] ` <20040828014931.GM24018@isi.edu>
2004-08-28 3:14 ` QuantumG
2004-08-28 3:35 ` Craig Milo Rogers
2004-08-28 3:49 ` Lee Revell
2004-08-28 12:23 ` Vojtech Pavlik
2004-08-28 19:20 ` Chris Meadors
2004-08-28 3:57 ` QuantumG
2004-08-28 12:07 ` Vojtech Pavlik
2004-08-28 6:47 ` Clem Taylor
2004-08-28 12:23 ` Wouter Van Hemel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040828180511.GA3916@ucw.cz \
--to=vojtech@suse.cz \
--cc=albert@users.sf.net \
--cc=clemtaylor@comcast.net \
--cc=linux-kernel@vger.kernel.org \
--cc=qg@biodome.org \
--cc=rlrevell@joe-job.com \
--cc=rogers@isi.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox