A Computer Lab in
been getting some decent results by capturing full-res data with a
Canon 50D, then discarding all the pixels except the red ones in Maxim
DL5, then using Registax 5 to stack 20-100 of those still-massive 16-bit
.TIFF files, then using Photoshop and FocusMagic to fine tune the finished
Looking back over the previous entries, it's easy to
see that incremental improvements in hardware and technique have paid
off nicely. But three fundamental problems remain with my DSLR-based
workflow. First, it takes approximately all afternoon
to go from snap snap snap to an image you might see here. Second,
the 50D needs exposures of about 0.4s to get decent signal when barlowed
to a generous image scale. That's due to three factors: it has an an
infrared cutoff filter that trims too much of the deep red H-a signal
along with nearby IR noise; it has a Bayer filter which means that
three pixels out of four are blinded behind green or blue filters;
and the telescope is operating at something like F30 rather than its
native F10 because I have to use barlow lenses to get a large enough
image on the on the Canon's relatively huge sensor. Third,
with the Canon making such long exposures, and operating in LiveView
mode, too, it cannot make several exposures per second to beat atmospheric
seeing using techniques pioneered by planetary astrophotographers.
I'm using a remote release and a timer to trip one frame every two
seconds. The effective frame rate of 1/2 fps is at least an order of
magnitude slower than the minimum rates used by successful solar /
lunar / planetary imagers. You're not going to beat the seeing with
such leisurely exposures spaced so far apart, not soundly anyway.
There are better, cheaper cameras around that address
all these concerns. A pure monochrome camera would not have a Bayer
matrix; those touted for astronomical use do not have an IR cut-off
filter either. As a result, they are sensitive enough to allow shorter
exposures and they have plenty of pixels because all are in play.
The smaller sensors on these cameras would allow me
to record the same detail in a much smaller solar image. That means
I could use the Lunt at it's native focal length (F10, not F30), and
that alone provides a factor of nine in reduced exposure time. Put
it all together and we have at least a four stop advantage in light
intensity. And that's before considering improved quantum efficiency
and possibly better A/D circuitry.
The smaller chips can be read out faster, so rates of
15-60 frames per second are not unusual (with enough light and enough
computer power to receive them).
Exposures can be much shorter; there can be many more
of them; and the individual exposures will be smaller and more manageable.
Here are the constraints. It can't cost a fortune. It
needs to have a large enough sensor to record a field of view sufficient
to get about a third of the Sun in the frame behind a 600mm EFL focal
length. As a bonus, larger chips are ideal for lunar photos behind
the A-P. It needs to have small pixels because all my instruments are
short-focus, and I want to oversample lunar, solar, and planetary images
for aggressive post-processing. Pixels can be 5 or 6 microns, tops.
As for bit depth, 12-bits would be better than 8-bits based on my experience
with Canon's RAW frames, but I could live with 8-bit pixels since we're
going to be averaging many, many stacked frames anyway. A USB connection is
required (rather than Firewire) because that's what my notebook
computer has, and I'm not planning on buying another of those anytime
The DMK-series of cameras made by my neighbors in Charlotte,
The Imaging Source, are popular and have been used for years by solar
system photographers around the world. If there is a standard, they're
it. But it's an aging standard. They were contenders, but their cameras
with larger chips are not particularly affordable nor particularly
sensitive, and they're limited to 8-bit output. A couple of current
masters (Christopher Go and Anthony
Wesley) use cameras from Point Grey Research. Lumenera cameras are
too pricey to consider seriously. I thought about some high-end webcam-like
variations from Meade, Orion and Celestron, but I really want a larger
array and more precise control than those offer.
8/24/2010: I picked the Point Grey Research
PGR's Chameleon is available as a monochrome camera
with a 1/3-inch CCD comprised of an array of 3.75 micron pixels. It
will output up to 18 frames per second at 1296x980 pixels and offers
ROI (Region Of Interest) capability for subframe capture (at higher
rates?) when appropriate (planets anyone?). The Chameleon uses a USB
2.0 connection. And it's priced near the bottom of the range; less
than half the price of similar-sized Imaging Source cameras and only
about twice that of many glorified webcams. Planetary imaging gurus
Anthony Wesley and Christopher Go both use PGR cameras. They firewire
models (Go uses the Flea3) behind larger telescopes.
The combination lets them grab far more frames per second than
the Chameleon can deliver through the USB port of my netbook behind
a 5-inch refractor. Even so, the Chameleon has big advantages
over what I've used previously (the Canon 50D at one extreme, a Philips
So what's the catch? Not much software in the PC universe
supports Point Grey Research's cameras. There's the "demo program"
included with the camera and precious little else. Or so I gather from
the web. The demo program may suffice. It appears to offer all the
options I know that I want now. The camera ships with a SDK which is
said to allow the control software to be modified using C++. If the
demo code doesn't get the job done, then I want to be able to use the
SDK and provided libraries to be sure it does. That means it's (finally)
time to learn some C++, and that is why this post is titled, "A
computer lab in a box."
8/27/2010: Here's the box:
It's small! And it's light! No,I
mean it's really small and light. No shutter, no mechanical
controls, no Peltier cooling, no mirror, and no viewfinder. It's a
Sony CCD, an A/D converter, supporting electronics, and a USB connection.
Period. I actually think a significant amount of its weight is in the
included tripod adapter which I attached to the camera just to keep
from losing it. How small? This small:
An adapter from Agena Astro Products mates the camera's
C/CS lens mount to a T-ring. 1.25- and 2-inch adapters already on hand
take it from there. There are enough rings and adapters lying around
to put it behind the solar telescope, the A-P, and the 200mm Nikkor
(although that may require a little measuring and a little machining).
It might also make sense just to watch eBay for a used Nikon F / C-mount
The software installed easily under WinXP SP2, although
there are a few rough edges because PGR doesn't cater to end users
so much as to machine vision labs, industry, and other places where
IT support is readily available. Their get-started documentation calls
for users to run "Setup.exe," but it doesn't exist. I selected
a likely candidate and ran that instead. A few questions about an IEEE
port (Firewire) required me to ignore those options since I don't use
one (most PGR cameras use Firewire rather than USB). That said, the
camera was autodetected nicely, the proper driver selected, and FlyCap
displayed a realtime stream with no fuss or drama. The options to capture
an AVI were neither particularly idiosyncratic nor especially handy
(but the more I use the interface, the better I like it). I had to
define the default capture directory and argue with the computer a
little about its availability (FlyCap prompts for a directory but actually
wants you to specify a directory and a filename for capture -- in fairness,
I discovered after the fact that the help system explains that). There
are plenty of options to try and many capture modes with which to experiment.
My initial impression was that the software was offering me little
feedback about what it was doing. In fact, there are cues and telltales
on-screen, but they are easily overlooked. The situation is exacerbated
by my netbook's widescreen mode; some of the controls and status indicators
can are below the bottom of the page. Scroll down. I just need to
play around with it.
8/28/2010. First light.
After practicing on the desktop, I installed the s/w
on the Aspire One netbook, verified that it worked there, then carried
the kit out to the solar telescope. I set the netbook's screen size to
1280x768 which is a little cumbersome (it insures that I can see everything,
but it also means there are two levels of scrolling to deal with; one
for the video adapter, one for the app). There may be a better way
to live with the little screen. The camera was very easy to focus on
the Sun (focus for the eye with an eyepiece in the extender, then remove
the eyepiece and extension and replace them with the camera; proper
focus is not far away). I focused on the limb of the Sun, then on surface
detail using the FeatherTouch focuser. A box to provide a shaded work
area will be very useful. I tweaked the telescope's aim, then captured
two, 30 second AVI's at 15 fps at 8-bit pixel depth. The camera was
set for 15 fps and that's what the little Aspire One computer captured via buffering in memory.
Good deal. Thirty second runs may be excessive, as the results are
half a gigabyte each and take a while to transfer over the home wifi
network to the desktop for processing. It will be worth trying some
ten second runs to see just how much difference it makes. There may
be a dependence between the stillness of the air and the length of run
required for top-shelf results.
Here's Registax 5.1 at work on my first Point Grey Research
And boy, does it work! I've aligned
my very first AVI capture in Registax 5.1 on several points (but not,
as you can see, on the area of dusky filaments in the upper left. This
image was made from the best 10% of 450 frames, aligned, stacked, and
wavelet processed in Registax 5.1. To the finished .TIFF, I applied
FocusMagic in PhotoShop CS4, and I rotated the image for a more "comfortable" view:
Registax's default behavior (select and stack the best
10% from an AVI) was well chosen, at least in this instance. An image
made from the best 5% was better than an image made from the best 50%,
but this image made from the best 10% was better than either. The 50%
test ran for a comparatively long time. When imaging an extended subject like the Sun's intricate surface or the Moon, it would probably be a good
idea to choose more than five alignment points. Here's a colorized
version of today's best result:
I stretched the same frame without mercy to reveal limb
detail. It would probably be much better if I began with 12-bit data
or at least with 8-bit data collected using a more appropriate exposure.
Aligning on the prominences in Registax would make a world of difference.
Still, just to see what's not lost down in the noise, it's not a bad
I don't know what the exact exposure time per frame was. And I don't
know how to find out in retrospect. This effort was just plug it
in, let the camera select gain and exposure, auto-everything, capture
the data for 30 seconds and then bring it inside to work it over.
It's real first light, proof of concept, unrefined stuff. The air
was not particularly steady. Watching the AVI and watching Registax
do its thing, the Sun's image was moving all over the place. It's
hard to believe this much detail could be extracted. This is very promising!
There's webwork to finish by the end of the month, then
clear weather predicted for the middle of this week.
Among other solar experiments to be tried: see what
happens with a single etalon. Try manually controlling gain and exposure
to see how they're related to noise. Try 12-bit captures. Is it possible
to use a telecompressor to get a full-disk image with the Chameleon?
What happens if I increase EFL?