From: Albert Cahalan <albert@users.sf.net>
To: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Cc: rlrevell@joe-job.com, clemtaylor@comcast.net, qg@biodome.org,
rogers@isi.edu
Subject: Re: reverse engineering pwcx
Date: 28 Aug 2004 12:17:19 -0400 [thread overview]
Message-ID: <1093709838.434.6797.camel@cube> (raw)
> 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.
next reply other threads:[~2004-08-28 16:25 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-28 16:17 Albert Cahalan [this message]
2004-08-28 16:25 ` reverse engineering pwcx Lee Revell
2004-08-28 16:56 ` Albert Cahalan
2004-08-28 17:11 ` Lee Revell
2004-08-28 18:05 ` Vojtech Pavlik
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=1093709838.434.6797.camel@cube \
--to=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