Preparing for my first sailing class last week, I took another trip
into point-and-shoot land. The idea was to get something waterproof,
since I assumed it would get splashed on the boat, which certainly
happens when you go rafting.
Based on earlier
reviews, I wanted the Pentax W60. Unfortunately, it was already
discontinued, and nobody knew when the W80 was going to show up. So I
borrowed Ian's Canon D10. Then the W80 turned up in stock at Amazon
three days before I left, so I got one just in time. The point being
that I took both of them to Berkeley with me. Here's how it turned
out.
First look
All right, so the point of this camera is to get some kind of
pictures where otherwise I would have had none at all. I realize the
results are not going to be great, and it's going to have the kind of
gimmicky feature set meant for the most clueless user. In this
respect, the W80 immediately meets–nay,
exceeds–expectations. It's loaded with useless crap like
in-camera aspect ratio selection (which just throws away some of the
captured pixels), and I really don't need two different
"modes" for Kids and Pets. "Smile Detection" has
been chosen as the function of the one and only dedicated button.
Fine. But even given all this, I'm still surprised to find that there
is no Tv or Av mode. At all. Exposure compensation is possible via
clunky menus, but that's all as you get. Ouch.
How does the D10 stack up? I find it just a little more usable,
mostly because exposure compensation is only one beep away, and the
case has one more button. So it hurts a little bit less when Canon
dedicates one of them to that useless direct-print thing that nobody
ever uses, as is their custom. The D10 also restrains itself to a
mere fourteen goofy scene modes, slightly less redundant than the
W80's twenty-four.
Now for some pictures
So, figuring when-in-Rome, I kept both cameras on either
auto-everything or "beach" mode all week. Getting back to
the hotel with the W80 on the first night, I have many pictures like
this:
Here is a nice 40-foot ketch (how about that sailor talk? YARRR!),
but what is going on with this picture? First of all, it has a strong
blue cast, which makes no sense. The only source of light is the sun,
at sea level, hardly difficult conditions. Here's what the scene
actually looks like, after forcing the sails to a neutral white in
Photoshop:
Every camera blows the white balance sometimes, but this
blue-purple cast is pretty consistent, including after I took it out
of "beach mode," which seems to be trying to exaggerate the
blue of the sky and water. The D10 seems to be free of this
problem:
Taking a closer look, things only get worse for Pentax:
Canon D10
Pentax W80
The Canon doesn't blow me away, but it's in the mid-tier point and
shoot ballpark. The Pentax would be in that ballpark too...if this
were ISO 400. But this is ISO 64. 64! Aren't we getting
about a trillion photons per pixel at this speed? Yet there's painful
noise in both chroma (fake magenta and green tints) and luminance
(overall grainy look). And at f/5.5, 1/400s, ISO 64, bright sun, on a
subject that is barely moving, this should be showing us the camera at
its best.
And the problems don't stop there:
Canon D10
Pentax W80
If you need to illustrate chromatic aberration, both cameras will
do, but at least the Canon has to be pushed into blown-highlight
territory. Again, not too bad, considering how the optics must be
compromised to be able to zoom in a sealed package with no exposed
moving parts. But the W80 happily bleeds purple fringes anywhere
there's a light-dark transition. Fortunately those hardly ever happen
in pictures.
Movie mode
If the image quality problems of the W80 were too subtle for you so far, try the movie mode. Watch in amazement as skin tones, brown rails, blue life jackets, and shadows all fade to purple. This isn't even the worst video by far; it's just one that Chrisi already uploaded to youtube so I don't have to.
Too bad, because the W80 claims 720p video at 30fps. There are a whole lot of pixels, they just all suck.
Here's me doing the same drill, as seen by the Canon D10. Fewer pixels, and the contrast isn't great (and I don't do as well at slowing the boat down), but the color looks more or less like it was shot under the Earth sun:
Verdict
I've never said this before, but Pentax has made the W80 so bad
that I don't want it. Assuming they'll take it, it's going back to
Amazon. Some updated reviews are coming out now, and they confirm
that somewhere in the process of smashing those so-very-important two
more megapixels onto the sensor, they made the actual image quality
dramatically worse than the W60.
If I really needed a waterproof camera, I'd have to get a D10. It
did a perfectly serviceable job, and my only complaint is that it's so
big and bulbous, and doesn't fit in a pocket. But the real moral of
the story is that I don't need either of them, at least not for
sailing. If you're going out for a class to do drills, it's hardly
worth bringing any camera, because you're going to be busy all day.
If you're going out to sail like a normal person, just use a normal
camera. The wettest I got either of these was rinsing them under the
faucet at the end of the day just in case they got splashed with salt
water at some point.
Beware that there are huge gaps in my non-scientific test, such as:
I never actually took either one underwater. So you'll want to read
other opinions. But I'm pretty sure you won't find I've got it
completely wrong, unless there is some kind of manufacturing problem
with these early samples.
One of the reasons I put off the
upgrade of my work computer
was that it required me to face the fact that some library named
"pyflac," which I used to write
flacenstein, has
disappeared. Nobody wanted to maintain it, because maintenance is
boring, so instead at least two other people have written new and
completely different libraries from scratch. This is so typical that
it has a name (CADT),
and it drives me up the wall.
So I downloaded some other guy's new python tag library, which is not
really any less hacky or better documented (writing documentation is
boring), but after a few minutes of guessing at how to use it, it
occurred to me that you know what, flacenstein also depends on
cdparanoia, yet that part has always worked just fine and has never
required me to touch it at all.
How is that possible? Because I heeded the advice in the
cdparanoia code and never screwed around with libparanoia or any
library bindings at all. I just fork and run the cdparanoia process
and read its output.
I see this pattern every day in another place. You may have heard
of GFS, which is
the "Google File System," not unlike Amazon S3. It doesn't
actually work like a file system; you can't mount it. You have this
enormous and complicated file-like API that changes all the time. Or,
you have a command line tool that provides most of the file API.
Binding to the file API requires a recompile every couple of weeks, occasional
busywork introduced by changes to the API, and many MB of bloat
dragged around with your binaries. Even when you "only" have to
recompile, this really sucks when you have to ever-so-carefully
distribute the new binary to many thousands of machines. Whereas the
tool flags change much less often, and it stays up to date
for free, because it's Somebody Else's Problem.
So I now advocate os.popen for the win. It screamed
"hack" at me when I had been more freshly educated in
Professional Computer Science. But you know what, it works just fine
and has a number of advantages:
The parent-child process interface is old and well understood and
well defined. I tell the child what I want it to do by giving it
arguments. It tells me how it turned out with its exit code. If it
wants to tell me anything else, it writes to stdout or stderr. All of
this is trivially easy to handle in any programming
language ever written.
It gives me fault isolation in a simple and well defined way. No
matter how badly the child craps itself, the kernel cleans it up and
changes the sheets and politely informs me that my child died on a
signal 11. Ever try to use a swigged-up library that has a habit of
SIGABORTing itself on errors?
The command line interface is stable. Far more than most people's
library interfaces. Guess why—because people use the
command line interface. Changing flags and such is seen as expensive,
because it inflicts usually-pointless pain on the poor ignorant
users. I get the same benefit if my automation pretends to be a poor
ignorant user.
It is dead simple to debug. If any of my programs has trouble, I
print the command it tried to run and die (or whatever is
appropriate). Copy and paste command into shell, find out why it
doesn't work, done.
It is similarly easy to explain and test dependencies. Try
running this, and this, and this, and if it all works, my script will
work for you. Trying to solve this problem for linked code leads to
apt-get or /usr/bin/ports. These things are fine when they are set up
just right, but getting your code set up just right is a ton of work
that I never bother to do. (packaging is boring.)
Fork and exec just isn't very expensive. Look at the hash Apache
made of it when they tried to eliminate fork in apache2, the better
to appeal to the average Windows idiot. It has been 8 years, does
anybody use apache2 yet?
Several years ago, somebody showed me a program called
"Autostitch," which uses some new technology to
automatically assemble one large image from a lot of overlapping small
ones. So I thought I would try this in the desert this year, and
brought back two sets of pictures meant to be stitched into two large
panoramas, one at Aguereberry Point and the other at Eureka
Valley.
I figured that with the passage of several years, the state of the
art would have advanced to the point that I would have half a dozen
stitching programs to choose from. Half an hour of Google searches
later, I was extremely annoyed to find that this is not the case.
There is still almost nothing available except the crappy binary-only
crippled Windows "demo" of Autostitch. How can this be? It
turns out the professors that wrote it have patented the algorithm and
are trying to sell it. Great.
So, with Autostitch off the table, is there still any way to get
this done? The answer turns out to be yes, barely. I will spare you
the many false starts and talk about only the tools that eventually
worked.
Taking the source pictures
You have to be mindful of a few things when you take the pictures
you are going to stitch together. Mostly, you want to eliminate as
much variance across the scene as you can. So, find the place you
want to stand, and set your camera to aperture priority. Assuming
this is in daylight, you probably want f/8 or f/11. Make sure the ISO
setting is fixed, if your camera has an auto-ISO mode.
Now you have locked down two of the three variables that determine
the exposure, and need to find a shutter speed. Sweep the camera
across the scene, and observe the meter. If you see more than about
2½ stops variance, you might as well give up now, because the
end product won't have enough range. Otherwise, pick a shutter speed
that looks like it will cover the most ground. Better to be a little
under than a little over, so a half-stop faster than the midpoint of
the scene is probably about right. Both of my scenes were shot at
about f/9 and 1/1000 at ISO 100.
Switch to fully manual mode and dial in the aperture and shutter
speed you chose. You might want to switch to manual focus, too, or
lock the focus to infinity. Taking landscapes at small apertures, it
doesn't really matter. If you are stitching pictures of closer
subjects, you'll have to balance depth of field as well.
Now start taking pictures like a crazy man. I didn't fuss about
rotating the camera around the nodal point of the lens, because again,
tiny parallax errors don't really matter on distant scenery. Don't
worry about keeping the horizon level or making precise overlaps, that
doesn't matter either. Just make sure there's plenty of overlap, and
be aware that anything moving while you are shooting will make life
difficult later. I usually shoot raw files, but I turned that off for
the panoramas to save time and space.
Generate control points for stitching
The process of assembling the panorama depends on "control
points," which means that you tell the stitcher that point P in
image A is the same as point P' in image B. You need a handful of
control points for every overlapping pair of images, and you can mark
them all by hand, but you probably have better things to do with a
weekend. So you want a tool that can apply the SIFT and RANSAC
algorithms to identify overlaps automatically.
The best we can do for now is
autopano-sift,
written by Sebastian Nowozin, a grad student in Germany. It has only
one glaring flaw, which is that for some unfathomable reason, it was
written in C#. Sigh. So off you go to download the
100MB Mono
runtime before you can run the 23k of code you need. Once you
have gotten it to run, it's easy to use:
# mono autopano.exe eureka.pto IMG*.JPG
Come back in a couple of hours, and eureka.pto is ready to go.
Transform the source images
Next, you need to use a thing called hugin to apply the affine
transformations (translations, rotations, skew) to your source
images. This is a GUI frontend that thinks it can run the autopano
and enblend steps for you too, but I found this awkward and
unreliable, as GUI wrappers that rely on command line tools to do the
heavy lifting usually are. (I would know, having written one called
flacenstein.) So I would recommend
that you only ask hugin to do the transformations, and maybe fool with
the control points if you want.
Open the .pto file in hugin, and run the thing called Optimizer.
This calculates various distortion constants, which I didn't bother to
learn what they were, but hey, if there's a button labeled Optimize,
how can you not push it? Then go to Stitcher. The projection you
probably want is equirectangular. Go ahead and click "Calculate
Optimal Size," but think about what you are going to do with the
finished product before you accept the "optimal" size. I
was using so many source images that the 1:1 output size was about
50,000 pixels wide, which is too many. Printed at 200ppi, that would
be over 20 feet wide. So I saved many hours of rendering time by
limiting it to 20,000x7,000 or so.
Set the output image format to Multiple TIFF, turn on either kind
of compression, and check the "Save cropped images" option.
(If you leave out compression or cropping, it will still work, but you
might fill up your disk. Each output TIFF tends to weigh a few GB.)
Leave the stitching engine set to nona, since it doesn't matter.
Click "Stitch Now," and go entertain yourself for another
hour or two.
Blend the source images together
When you come back, if you didn't fill up your hard disk and crash,
you will find a collection of TIFF images that were generated one from
each source image. If you open one of these for fun, you will see
that it's just the source image, rotated and distorted as necessary
and placed inside a huge blank field. Now you want to lay these all
on top of each other and melt them down into one combined image. For
that you use enblend, which came in the Hugin bundle (also available on its own).
suntop:bin mikey$ cd /Applications/HuginOSX.app/Contents/MacOS
suntop:MacOS mikey$ ./enblend -o eureka.tif stitched*.tif
This also takes a long time, but when enblend finishes, you're
done...almost. More precisely, you're done if you want a TIFF file
and are completely happy with the projection you got. If not, you'll
want to apply the finishing touches in Photoshop. I hate to say it,
but the Gimp is just too painfully
slow on images of this size. Anything that triggered a screen
repaint, such as clicking on a menu, meant a five minute wait.
Photoshop was running laps around it.
All done, here is a finished product:
What to do with it now, is an open question. Kacirek tells me it is
possible to get one massive print, using the people that make the
prints for the gigapixel project. Otherwise, I was going to slice the
finished image into tiles and print them at any standard size,
possibly the 10x10 squares from mpix.
I thought that if the tiles were mounted on foam board and hung at the
right spacing, one might create the appearance of a window. Or at
least, this idea might work if executed by a person of sufficient
artistic ability.
About six months ago, my main camera bag had gotten so big and
heavy that I didn't want to carry it around much. So I took the idea
into my head that I should get a point and shoot camera that's good
enough that I'm willing to use it at those times when I don't want to
carry the 30D around all day, or don't want to draw much attention to
myself.
I have been wanting this crazy
thing forever, but it's still vaporware more than a year after it
was announced. Meanwhile this Leica D-LUX
3 had just come out, with a similar pretty design, plus I
could own something with the magic red dot for "only"
$600..so that's what I did.
Lots of people will tell you these days that point-and-shoot
cameras have gotten so good that there's no real difference with an
SLR. I don't know what those people are doing, because for me, that's
not even close to true. Once I had the Leica out of its beautiful,
Apple-esque packaging, I was instantly frustrated with all the same
things that have always sucked about point and shoot cameras: slow to
turn on, lame motorized zoom and focus, no viewfinder, clunky menus to
change anything, horrible noise at anything over ISO 200.
Not feeling blown away by the Leica, I ended up also buying Gary's
Canon G7 which he had barely ever taken out of the box. The problems
are pretty much the same, so I resigned myself to the fact that there
just isn't a point-and-shoot that I can use like an SLR. But now Gary
is thinking about buying the same Leica, so he asked how its noise
compares to the G7. I didn't really know, so I did this little
experiment. (I threw in the 30D for reference; it's not a fair
comparison because it has a much larger sensor. That's kind of the
point of an SLR.)
Pixelpeeping (aka measurebating)
Leica D-LUX 3
Canon G7
Canon 30D
100
200
400
800
1600
As I well knew, both cameras are pretty rough at ISO 400, and
anything higher is basically unusable unless you punt to
black-and-white and try to pass it off as a grainy film look. I have
been doing this with the Leica and have been reasonably happy with the
results:
But notice the interesting difference in how the two cameras
degrade: The G7 takes on texture like bad TV reception, but the D-LUX
3 takes on weird blocky artifacts that look almost like bad
compression. This suggests that maybe I should be using the G7 if I'm
going to go for the grainy look.
What if you shoot raw?
The Leica's in-camera software is obviously working much harder at
noise reduction, because if you look at its uncorrected raw files, the
noise is awful, much worse than the G7 jpegs. With the thing Bibble
calls "basic Noise Ninja," you get back into the same
ballpark:
D-LUX 3 in-camera JPEG (ISO 800)
raw file passed through Bibble+Noise Ninja
You get quite a different effect, but it's hard to say which one is
better. The fact that Bibble failed to remove the phantom color tints
is troubling, but I cheat around that by going to black and white
anyway, and I really don't like the plasticky artifacts that the
in-camera process gives you instead.
Meanwhile, we can't compare this with the G7 raw output because
there's no such thing. The G5 and G9 have this feature, but,
inexplicably, the G7 does not. There is a
weird firmware hack that restores
it, but it's not straightforward–even once you have a G7 raw
file in your hot little hands, no ordinary program can render it. You
need more weird hacks, after which it might mostly work. I'm
skeptical that this is worth the trouble, so I haven't tried.
Other observations
I don't like the G7's native 4:3 aspect ratio, which looks like
"digital camera" to me. Unlike the Leica's 16:9 format,
which looks new and exotic.
They can both make arbitrarily long full-motion videos. The Leica
can do this in either 4:3 or 16:9, but only the G7 can operate the
zoom while recording.
If you want to look cool, the Leica excels at that. Several
non-photo-geeks who know nothing of Leica have said, "Wow, that
looks like a really nice camera." There is also a
beautiful retro-style leather case that
you can never find in stock. (Yes, it's $130 for a case; you're
dealing with Leica now.) Looking pretty isn't everything, but it
isn't nothing, either. The G7 isn't without its charm, but it's only
going to catch the eyes of other photo geeks. Everybody else is just
going to wonder why your camera is so big.
The G7 has a hot shoe, which is crucial if you are into
wacky lighting. I am
just getting started on that road, but even slapping the
Speedlite with
Omnibounce on top gives you the
ability to light up a room and escape high-ISO hell, which the Leica
will never do. It does make for an oddly proportioned setup,
though.
The G7 has two customizable program settings on the dial. I have
one set to what I call "Portra" and the other to
"Velvia." But, I end up not using these, because I don't
usually want to take risks with weird settings when the result will be
baked into an unfixable jpeg. Bizarrely, the custom programs also
memorize the focal length of the lens, so when you switch modes, you
have to wait while it zooms to some random position.
On the other hand, when the D-LUX 3 is given enough light, there is
a certain softness to the highlights and overexposed areas that looks
Leica-ish to me. This is no doubt an illusion created by decades of
Leica marketing, but I like it anyway. For example:
Non-conclusions
With the exceptions noted above, either of these cameras will do
whatever you want. Whichever one I spend more time with will be the
one that makes better pictures for me. So far, as you can see, that's
been the Leica. I seem to prefer the smaller and prettier one when
I'm not going to take my "real" camera. The G7, being
neither here nor there, tends to get left at home. That may change if
I start bringing my own light.
One last thing: if you are thinking of buying the Leica, you
probably already know that you can get exactly the same hardware
without the magic red dot for $240 less. This is called the
Panasonic DMC-LX2. The Leica version
supposedly has different firmware, but I don't know what the
differences are.
After my desktop machine went OOM again today and had to be
rebooted, I figured I would finally install the current version of the
slimserver, which is the 100M of perl bloatware that drives my various
squeezebox players. I hate to
upgrade this, because I have to port forward my weird hacks each
time.
(Aside: Another reason I haven't touched the slimserver in a year
is that the current versions depend on a local MySQL server for
some idiotic reason. BARF. No. You do not need a SQL engine
to drive what is, in my case, about 1200 CDs, which weighs in at 500K
of data. And even if you think you do, you never heard of sqlite? You had to bundle mysql, the
rip-roaringest piece of half-assed crap that anyone ever mistook for a
database? BARF.)
On the other hand, the new slimserver is a whole lot faster than
the old one. Moving on.
My only local modification teaches the slimserver to understand the
wacky FLAC coverart
blocks which are an extension I made up. My old patch against
6.2.2 doesn't apply anymore, so I had to sort it out again, which
fortunately wasn't too hard. Yeah, I'm just going to paste the patch
right here, because I am lazy. Hope you like reading perl diffs with
your morning coffee.
diff -rcN SlimServer_v6.5.4/Slim/Formats/FLAC.pm
SlimServer_v6.5.4-hacked/Slim/Formats/FLAC.pm
*** SlimServer_v6.5.4/Slim/Formats/FLAC.pm 2007-05-24
18:02:36.000000000 -0700
--- SlimServer_v6.5.4-hacked/Slim/Formats/FLAC.pm 2007-10-06--
--00:07:41.000000000 -0700
***************
*** 65,70 ****
--- 65,75 ----
# as PIC1 + artwork. So the raw data is +4 from the beginning.
my $ESCIENT_ARTWORK = 1163084622;
+ # flac-image also stores cover art in a FLAC application block, but with
+ # a different application id and a 72-byte header--same thing, only
+ # different.
+ my $FLAC_IMAGE = 0x696d6167; # == "imag" in ASCII
+
=head2 getTag( $filename )
Extract and return audio information & any embedded metadata found.
***************
*** 293,300 ****
if (substr($artwork, 0, 4, '') eq 'PIC1') {
$tags->{'ARTWORK'} = $artwork;
}
! }
return $tags;
}
--- 298,318 ----
if (substr($artwork, 0, 4, '') eq 'PIC1') {
$tags->{'ARTWORK'} = $artwork;
}
!
! } elsif ($flac->application($FLAC_IMAGE)) {
!
! # we don't bother to look at the mime-type field except
! # to check that it starts with 'image', because Info.pm is
! # going to apply magic to try to guess the mime-type anyway.
!
! my $artwork = $flac->application($FLAC_IMAGE);
!
! if (substr($artwork, 4, 5) eq 'image') {
! $tags->{'ARTWORK'} = substr($artwork, 72);
! }
+ }
+
return $tags;
}
diff -rcN SlimServer_v6.5.4/Slim/Music/Info.pm
SlimServer_v6.5.4-hacked/Slim/Music/Info.pm
*** SlimServer_v6.5.4/Slim/Music/Info.pm 2007-05-24
18:02:33.000000000 -0700
--- SlimServer_v6.5.4-hacked/Slim/Music/Info.pm 2007-10-06--
--00:22:13.000000000 -0700
***************
*** 944,950 ****
sub isFLAC {
my $pathOrObj = shift;
! return isType($pathOrObj, 'flc', @_);
}
sub isAIFF {
--- 944,952 ----
sub isFLAC {
my $pathOrObj = shift;
! return 1 if isType($pathOrObj, 'flc', @_);
! return 1 if isType($pathOrObj, 'fec', @_);
! return 0;
}
sub isAIFF {
That's all I need to do to the slimserver. I had to update the Weblogger
plugin as well, and fyi, the current version 0.99c has a bug that stops
multipart POST from working. You need to change this one line, or you
will get nothing but "Can't coerce array to hash" errors out
of it:
From the beginning when I started ripping CDs into FLAC files, I
knew that notionally one could recreate an exact copy of the original
CD from the FLAC if one wanted to, modulo hardware limitations,
because the audio data is stored as a single untouched rip, and the
original TOC is stored in the form of the embedded cuesheet. I never
got around to figuring out how to do this, because I didn't have much
reason: I have Squeezeboxes everywhere I listen to music, and they
play the FLAC file.
Now, however, I have got a new car with a CD changer, plus I wanted
to burn a copy of something for Beth. So despite not being able to
find much of anything on Google, I found that this is actually dead
simple:
#!/bin/sh
#
# flac2cd.sh - Recreate a CD from FLAC file $1.
# Written 4 Apr 2007 by M. Dickerson (too trivial for a license,
# don't you think?)
set -e
ME=`basename $0`
AUDIO=`tempfile -p $ME`
CUE=`tempfile -p $ME`
FLAC=$1
metaflac --export-cuesheet-to=- "$FLAC" | sed s!dummy.wav!$AUDIO! > $CUE
flac -f -o $AUDIO -d "$FLAC"
cdrecord -dao --cuefile=$CUE
rm $CUE $AUDIO
Obviously you need your cdrecord defaults set up right if you're
going to use that literally, but that's left as an exercise to the
reader.
So, the reason I didn't figure that out three years ago was that it
was too easy. I was expecting to have to do all kinds of Godawful
cuesheet arithmetic like I did for my assemble-random-tracks-into-CD
script. It's kind of like the time when I couldn't figure out for
half an hour how the hell you burn a CD on OS X, because it turns out,
all you do is put in the blank CD and wait for magical things to
happen.
A couple weeks ago, woot was selling these network
cameras (Hawking Technology HNC210, not that you care, but to help
google find this page). This is something I have always wanted to
play with. The difference between these and a normal web-cam is that
these don't plug into your computer; they run their own HTTP server
and plug in to the network directly. They were $40, and I decided why
buy one when I could have two at twice the price.
As always when your computer world is as weird as mine, there was a
healthy chance that these things would not be usable at all. There's
never any way to know, except to look for some random forum post where
somebody has bought one and tells you how it actually works. (That's
what this is.)
So first thing, throw away the Windows setup CD which is worthless
to you. The manual is helpful, though, because you can figure out
from the screenshots that this thing boots up with a hard coded IP
address of 192.168.2.3. All you need to do to talk to it is to
ifconfig yourself an IP in the same network:
mikey@ember:~$ ifconfig eth0 inet 192.168.2.1 netmask 255.255.255.0
mikey@ember:~$ ping -c 1 192.168.2.3
PING 192.168.2.3 (192.168.2.3) 56(84) bytes of data.
64 bytes from 192.168.2.3 (192.168.2.3): icmp_seq=1 ttl=64
time=0.701 ms
--- 192.168.2.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.701/0.701/0.701/0.000 ms
Ok, now that you can see it, just go to http://192.168.2.3 in a browser and you
should get in (username admin, password 1234). Click Network Settings
and you can set it to whatever you need to make it get along on your
network. In my case, and probably yours, I just wanted to enable
DHCP. Note that as soon as you click the Apply button, the thing is
going to reboot with no warning and come back on a different IP, so it
is going to look like it disappeared in your browser. Not the
greatest user experience; you'll just have to find it again on its new
IP.
If you brick it somehow, there is a hardware reset button on the
device that should put it back on 192.168.2.3. All in all, not an
unreasonable way for this kind of embedded device to work. You might
wish DHCP was the default, but that can be a major pain if you don't
have DHCP, or can't control it in your environment for some
reason.
Using the little built in web interface, you can also see the live
images from the camera if you have a working java plugin. That's not
very useful, so the next question is how to pull images from it. Some
tcpdump, easily confirmed with some google searches, reveals that this
thing is speaking a weird but simple protocol on port 4321: Open a
socket, send the ASCII characters "0110", and get back 2
bytes which are a 16 bit big-endian int, telling you how many bytes to
expect. Immediately after that, you will get the promised number of
bytes, which are a finished JPEG. That's it. If you want
"video," you can say 0110 again and get another JPEG, as
fast as you want. That's all the Java "video" viewer is
doing.
Knowing how to get JPEGs out (a process that completely ignores the
little password check built in to the web interface, by the way), you
can now make it do whatever you want. I found a ruby script by a guy
named Tim Haynes which knows how to
unpack the data, and modified it (ham-fistedly, since I don't know ruby
at all) to work as a CGI. The script is
right here.
All that's left is to hook up the CGI to a web server somewhere. I
used an Apache that I already had locally, and gave it another
VirtualHost that binds a normal-looking URL to my cheesy CGI:
<VirtualHost 192.168.47.2:80>
ServerName cams.singingtree.com
ServerAdmin mikey@singingtree.com
DocumentRoot /var/www/proxy
ScriptAlias /cam1.jpg /var/www/proxy/cam.cgi
ErrorLog /var/log/apache2/webcams.error.log
LogLevel warn
# Logging every GET creates a lot of crap when you are running
# javascript loops that reload the image N times per second..
#CustomLog /var/log/apache2/webcams.access.log combined
</VirtualHost>
That's it. If the whole Rube Goldberg apparatus is working, you
can now put the camera URL in an img tag anywhere you want.
Gentlemen, behold!
This isn't really a hack in the sense that I thought of something
clever to do, but it amuses me nonetheless. One of my many squeezeboxes is in the bedroom,
and it has its own remote control of course, but I can't read the
screen from the bed without putting my glasses on. Obviously I could
move the squeezebox, or the bed, or I could put my glasses on.
But why do that when there is a less obvious solution: I can
forward a port so that the server that controls the squeezeboxes is
reachable from the Internet. Then I can use the Blackberry which is
always close by. So I can now change the volume or play a CD by
sending commands up through T-Mobile, across the internets, to my ISP,
down the DSL, through the NAT router, to the slimserver machine in the
closet, across the ethernet to the squeezebox which is eight feet
away. This works better than you would expect; the total round trip
from me pressing a button to hearing its effect is about half a
second.
Even more important, I now carry this power in my pants wherever I
go, so if I suddenly need to play Cowboy Bebop in my living room while
I am in the airport in Chicago, I can do so. Booya!
For some reason I have been on a mission this week to find a way to
do all the instant messaging in text only. (I started to explain why
but realized that if you don't already know, my reasons are not going
to make sense to you either.) This has mostly been an exercise in
frustration. Here are the things I tried, and why each one of them
sucks, although some suck a lot less than others.
Not considered: gaim, licq
I like gaim just fine,
and have been using it for a long time now, but it only comes in GUI
form of course. licq, best
pronounced lick-q, is something I used to use long ago, along with its
predecessor micq. I abandoned it at one point when it was not keeping
up with icq protocol changes, but I see it has survived and mutated
into GUI form.
naim: ok, but not enough protocol support
naim is an irc/aim program in
the style of an irc client. Its interface is a little baroque, but
manageable. I'm not sure why I need a two-dimensional space of
windows to flip through, using Ins/Del to change between accounts and
Tab to change buddies on the current account.
Unfortunately, as the name "naim" might suggest, it
really only speaks AIM. Even ICQ is unusable, since it displays
buddies by icq number and can't reliably fetch even the nickname to go
with the number. This is probably because it is only using TOC (not
OSCAR), which means that it's always going to be somewhat retarded
compared to e.g. gaim. I used it for a couple of days, but after
about the 20th time that I had to search through my old gaim logs just
to find out who I was talking to, I decided this was foolishness and
dumped it. So long, naim.
centericq: plenty of protocols, blindingly stupid interface
I had high hopes for this one. centericq speaks irc, msn, aim, icq,
yahoo, and jabber. It's not irc-style, though, but rather has its own
curses scheme:
Looks fancy, but look at how much screen space we are wasting
drawing lines and boxes. The top and bottom status lines can be
argued to be carrying information, but four more lines on top of
those are dedicated to line drawing. (The pink line is my screen
session, not centericq's fault.) The curses tree widget wastes even
more space indenting every entry for no reason. (gaim does this too.)
Pro tip, guys: tree displays are all well and good, but you don't
need to indent your first tier of information. I don't need to be
cued that everything in the list is a descendant of the useless
imaginary "root". You're just wasting space.
None of those extraneous status or buddy-list windows is
configurable or resizable, so the end result is that in a program
whose purpose is to deliver messages, we have maybe a third of the
screen available for delivering messages.
Also note that it is impossible to copy and paste the URL from the
screenshot there, unless I have the patience to do it in three parts.
There's an F2 button that is supposed to "show URLs," but it
does not give you a copyable version either. It serves no purpose
whatever, as far as I can tell.
It only gets worse from here. There's no scrollback, so that one
third of the screen is all you get. Unless you want to see the event
history, so you press control-O. Here you can see what you missed, if
you don't mind reading in reverse order. What the hell? And it
displays in that same one-third of the screen, but cuts off each
message at 50 characters rather than wrap the lines. Oh, there's a
full-screen mode if you push F9. Surely it will, you know, fill the
screen with messages so I can read them? Nope, full screen mode
blanks the screen and displays one event at a time. And the
finishing touch, the "Next" and "Prev" functions
here do the exact opposite of what they say, because the messages were
in reverse order to begin with. At this point I started to worry that
I was getting stupider just by looking at this crap, and dumped it.
So long, centericq.
There are also maddening bugs that might be the result of a bad
compile on my part. It dumped core four times in a day of trying to
use it, and it mysteriously drops keystrokes at random. Point at a
buddy list group for example, and press Enter a bunch of times. Group
goes up, group goes down, group goes up, group goes down, nothing,
group goes up, group goes down, nothing.
(I cleverly smudged out the names in the screenshot because some
people I know would flip out if I gave away their s00per s3kr1t im
names. The horror! My im names are right here on this page,
obviously.)
bitlbee: sounds incredibly awkward but works
I put bitlbee off until last
because it sounds like such a kludge, a daemon that translates various
IM messages into irc channels, but they have won me over. The idea
here was to separate the protocol support from the interface, so you
can just go on using whatever irc client you already like. It turns
out to not be as clumsy as I thought; bitlbee force-joins you to a
control channel where you set up your accounts and do whatever you
might want to do to your buddy list. I would rather just remember
"add aim mdickers47" than stumble through curses menus using
whatever weird combination of F-keys and ctrl-keys some dude picked.
And of course irc support is a non-issue since you are already in an
irc client--the others tend to handle irc a little wonkily because
it's pretty different from the newer buddy-oriented systems.
So for now, bitlbee is where it's at. The Unix Philosophy wins
again. Incidentally, if you are someone that happens to have an
account on my machine named redlance, that means you can try it too.
Just log in and start irssi or epic, then connect to localhost.
I finally bought a video projector to take the place of the TV I
never set up. This is something I have always wanted but never
bought, like last year's camera. I didn't want to spend more than
$1500, which is still is a big deal for me, so I spent more than a
little time trying to figure out what I should buy. A couple people
have asked me what I think they should buy too, so here you go,
everything I know about projectors.
DLP or LCD
Fundamentally your choices right now are going to be either DLP or
LCD. DLP projectors shine a light onto a chip that is made up of
millions of tiny mirrors, which can be individually maneuvered to turn
pixels on or off. LCD projectors shine a light through a liquid
crystal panel, whose pixels are switched on or off in the same way as
a laptop screen or any other LCD.
This makes a difference in the image, because the way that DLPs
work means that the color in the image has to be created by rapidly
switching the color of the light beam, which they do with a
"color wheel." The speed and composition of this color
wheel determine how smooth and clear the projected image is, to some
extent, but more importantly, a faster color wheel makes the dreaded
"rainbow artifacts" less likely.
Rainbow artifacts happen because the projected "white" is
actually flickering between red, green, and blue, which means that if
you move your eyes suddenly, bright objects leave a trail of different
colored images. Supposedly not everybody sees these, and supposedly
with a 3x or 4x color wheel "almost nobody" can see them,
but I still find the rainbow effect to be obvious, at least when the
image has a bright object on a dark background. So you will want to
see a DLP projector image yourself, in a reasonably dark environment
(not Fry's), to find out how much this is going to bother you.
LCDs don't use a color wheel, so they produce no rainbow effects.
They do, however, tend to have a more obvious "screen door"
effect. This refers to the dark grid that is usually visible as the
gaps between pixels if you look closely at the projected image. Some
spacing between the pixels is necessary on an LCD, because the control
signals have to be carried through the panel to each pixel
somewhere. The screen door effect can be at least as annoying as the
rainbow effect, more so if you are sitting relatively close to a
relatively large image, as you might like to be for watching a
movie.
The conventional wisdom is that DLPs (all from Texas Instruments)
have better color fidelity and contrast than LCDs, but this is
extremely subjective, and LCD manufacturers (Epson and Canon, mostly)
have made dramatic improvements now that there is competition. DLP is
still the clear choice of home theater snobs, however, which is worth
weighing in if, like me, you work with about three thousand geeks that
are only too happy to explain what you should have bought if you had
known what you were doing.
Data or video
This distinction is less obvious, but all of the projector
manufacturers make models that they intend primarily for data
(Powerpoint presentations), and others that they intend primarily for
video. Basically, if it doesn't have "home cinema" in the
name somewhere, it is probably designed for data. Data projectors
tend to be much brigher, at the expense of color and contrast. An
LCD might achieve greater brightness by not saturating its pixels as
deeply, whereas a DLP will do it by adding an extra transparent
segment to the color wheel. DLP data projectors will usually have a
four segment, 1x or 2x color wheel, which doesn't really matter for
computer images that don't change much, but makes the rainbow
effect worse on moving images.
Another good clue is the aspect ratio: Most projectors create a 4:3
image, which is the same as old fashioned TV and computer screens, but
the ones for home theater use the "widescreen" 16:9. Either
type can display either format; they will just waste the extra pixels
on either side (or top and bottom) when displaying the non-native
shape.
Video projectors might be expected to have better hardware for
processing and upscaling the various input resolutions that you get
from your DVD player, and they say that they do, but again, this is
all hand-wavy and subjective.
Brightness and resolution
If you buy a data projector, it will most likely be 800x600 or
1024x768. Either of these is more than enough for watching TV or most
HDTV signals. Ordinary TV is only 480 scan lines, so if you know that
you don't have any source of HDTV video that you just have to watch at
higher resolution (which I don't), then a 640x480 image will be just
fine.
If you want a 16:9 projector, you will have other weird choices
such as 1024x576. These video modes may also be listed under their
HDTV-names, such as 720p, 576i, etc. Remember that practically all of
them will say that they are "compatible" with all of the
HDTV modes, but what you want to compare is the actual
"native" resolution.
Ironically, higher brightness (lumens) can be the enemy of a nice
saturated video image, as I suggested earlier. Keep in mind that if
you are mostly going to be watching movies indoors, at night, in
reasonably low ambient light, then the wimpiest 500 or 600 lumens is
just fine. Those data projectors come in at 2000 and higher because
they assume you are trying to watch them in a conference room, without
turning any lights off.
I would look for a projector with a "low power" mode,
which will certainly still be bright enough most of the time, but is
supposed to extend the life of the bulb. This might be a big deal,
since the bulbs are unbelievably expensive, usually $250-350 or
more.
What I bought
I looked at a lot of places and made notes in a little file, and
ended up buying the one that I saw on the
Costco web site, which was the one
that got me started on this whole thing in the first place, because it
looked like a good deal. It is a
Mitsubishi
HC900u, which does 1024x576 native with a 4x color wheel. Mounted
up on the wall, it throws an image about 9 feet by 5 feet on the
opposite wall, which is about 12 feet away. It looks quite a bit
better than other projectors I have used, which were usually in
classrooms or offices or other places that we weren't supposed to be
abusing them. Or so I tell myself, since this cost $1200.
I did manage to talk myself into paying more for 576p resolution,
despite having no HDTV video player of any kind, and for the 4x color
wheel, which still does not eliminate rainbow effects. Maybe they
would be much worse with a 2x wheel, I guess. Anyway I'm sure I could
have gotten off much cheaper, but whatever.
Incidentally, although I am perfectly happy with the projector, I
definitely do not recommend that you buy anything online from
costco.com. They didn't manage to ship anything for almost three
weeks, then did not answer the email I sent to their customer service,
using their own stupid online form. You could get away with that crap
in about 1997, but these days, if you can't do at least one thing
better than Amazon, you have no business trying to run an online
store.
You don't have to take my word for it
projectorcentral.com
is the most useful web site that I found. They compile all the
detailed specifications on dozens of projectors, usually with much
more information than the store that is selling it. There are a lot
of reviews, but as usually happens, the one you will find for sale
will be a slightly different model number than what they reviewed, so
you won't know how much of it applies.
Coincidentally, woot has a DLP
projector up right now for $700. I might well have bought it, if it
had come up a few weeks ago.
mikey@singingtree.com
4171622
mike.dickerson@pomona.edu
pomonamikey
78
204db8e4
