Observatorio de la Ballona

The equipment has been moved and the time came to take real data to make a good image. On September 20, 2008, my brother-in-law Art Fernandez and I got the AP-900, NP-101, and ST-10 combo all set up and took some nice data of M33.

Setting up the AP900 requires good polar alignment. On a one-night set-up, the first align alignment needed to be visual. On the first iteration, I aligned on the wrong star — I picked a bright star but not the named star to which we were aligning. The lesson is to start with the 44mm Panoptic, whose field of view is large enough to prevent mistakes. On the last alignment, the alignment star crossed the meridian during the alignment. The mount tried to slew backwards to get back home.

We then put on all the CCD equipment and balanced the mount. I tried aligning (using sync) on Jupiter, but results were poor. I finally got good alignment on a bright star and then using a search pattern from the believed location. Kind of like a sea search for a wreck.

My first idea for a “don’t stay up too late” target was the Cocoon Nebula. But by the time we got going, it was too high in the sky, so we moved to M33. So now come the follies.

FocusMax wasn’t talking to Maxim DL 5, so I had to find the newest version. If you need it go to the Yahoo! Focus Max group. Then I tried to use the Pyxis, but I could not talk to it. I learned later that the delivered software won’t work with a Keyspan USB to serial adapter. So no Pyxis. In rotating the camera, the mount moved against the clutches. Alignment lost.

Found a star, re-aligned. On our way. Except that Maxim DL 5 was obstreperous on the autoguiding calibration. It kept jumping from star to star between alignment frames. There definitely could be some algorithm enhancement there.

On focusing, acquire star in FocusMax didn’t work. It turns out that the error was that I did not allow syncs in TheSky. I control the scope from TheSky as the hub, but internal settings prevented it from working. On October 26, with help from CloudyNights, I fixed the problem.

The mount guided beautifully on 10 second exposures. I know I can push it further than that.

It got very cold, down to 43 degrees F. And in September. I blame Global Warming.

Take down was a lot of work.

And I have to mention the skunk. At about midnight, the definite smell of a skunk came down across us. Enough that it lingered in protected areas until morning. But thankfully, it was at least a quarter mile away.

Here is the resulting image.

In an excellent post on discussion thread in the Bad Astronomy / Universe Today forum, Mike (of IceInSpace) noted that the ToUcam Pro would compress data to achieve over 10 frames per second over its standard USB 1.1. This would degrade the quality of anything over this frame rate from the camera.

I happened to have discovered the fps control on my ToUcam over the weekend and took 2 avis of the Plato crater, one at 30 fps and the other at 10fps. This provides an excellent test case for this finding.

I have attached two jpgs, one from processing each of the AVIs in Registax. Both were processed in the same way:

1. aligned with a single 256k box centered on the middle of the crater
2. A reference shot of 50 frames was created and sharpened in wavelets
3. The stack was limited to 60% and optimize
4. The top 200 frames were selected and stacked
5. The image was sharpened with wavelets 9.2/26.0/13.2
6. Saved as TIFFs from Registax, JPGs and PNGs from Photshop, quality=80

No other adjustments were made to the images. The PNG images are below.

At 10 frames per second:

At 30 frames per second:

My first take is that the 30fps image has less noise. Seeing was not good, and that could be a major factor, since the improvements from faster frames could have overtaken the noise introduced from the compression in the camera.

TIFFs are available at the Observatorio de la Ballona FTP site.

I’ve posted a couple of new images - Saturn and M1. I think the M1 is quite nice. On Saturn, I got carried away with noise reduction. See them at the gallery.

Over the weekend I took several hours of data of NGC 2903 (The Perils of Changing Your Method ). I have taken several passed at processing the image.

I started by creating baseline combined, aligned, and stretched L/R/G/B images using MaximDL for reduction, CCDStack for combination, and PixInsight for stretching. These images have served as my baseline for all processing attempts. In that first processing session, I did a quick and dirty (so I thought) combined color image. I did minimal noise reduction, and sharpened only with a hi-pass filter in Photoshop. I figured I’d get a chance to see how it looked in color. It was an OK image.

My frustration has come from my subsequent attempts at finishing the image. In my second version, I did extensive work in PixInsight to sharpen the details of the galaxy. But the finished image didn’t look as nice on the printed page as my quick and dirty version. The outer arms were too dark, and i lost nebulosity surrounding the galaxy.

Last night I tried to split the difference — keep the outer areas lighter while still enhancing the inner detail. I failed completely. It lacked the sharpness in the center, had good detail in the outer arms, but the mid-area nebulosity was lost.

So the two times I spend more effort on the image, I just make it worse. Aaargh.

A problem with any astronomical set-up is the time it takes to get it right.

So here I am with what appears (to an unaided eye) to be good seeing and Saturn is up, but I don’t want to take apart the CCD set-up to use the Web Cam.

I faced the same thing a year ago when I took the refractor off of the mount and put the SCT back. It was months before I got the whole set-up working again. And the refractor set-up worked well. It was not suited to galaxy pictures, and Winter is the season of galaxies.

I got NGC 2903 on Saturday, Moon somewhat bright, seeing pretty good. The test image is nice. I’ll post it when it’s done.

Last night was clear — I planned and executed an imaging run.

I used CCDNavigator. The user interface caused me a fair amount of hearburn. It tries too hard to make the schedule work, so users who aren’t doing automated observing face edits that aren’t required for their use.

The software influenced my approach. A typical approach, emobodied in the software, is to use a stair step approach for taking your images. You start with the lower resolution color, and work up to the high resolution luminance. I have always evenly balanced my LRGB sub-images. I can’t say that I have a theory for doing so, and last night I accepted the approach indicated in the software. There is good reason to do so. When an object is lower in the sky, it is better to get low resolution data. I have not been binning my color, decided to tonight, so this was the approach.

So you take RGB away from the meridian crossing, and L just around it.

Overall it went well. Results will be posted later. However, a minor anomoly caused a problem. Normally I image with subimages taken L/R/G/B etc. With the RGB planned for early, I “grouped by slot”. and took shots RRRRRR/GGGGGG/BBBBB/LLLLLLL. The problem ocurred because the sky was too bright for the initial red exposures. They were all wasted. If I had done a patter of R/G/B/R/G/B…LLLLLL…R/G/B/R/G/B I would not have had the problem.

Live and learn.

I should have written about this two weeks ago.

When we finally got out to Aguanga after the last pipe failure, everything seemed fine. The new outside pipe was nicely insulated, the pump came on with no problem, everything OK. NOT. My wife came out of the house yelling to turn off the water because water was coming down through the ceiling in the bathroom. Water was quickly turned off, but the ceiling in the bathroom fell in moments later anyway.

Inspection in the attic revealed an inch-long burst in a 3/4 inch pipe that feeds a hose bib outside the house. Thankfully it must have burst after the outside pipe broke, and so did only leaked for the brief period we had the water on.

I headed to Anza to buy pipe clamps, and called the plumber. On the return from Anza (having purchased all three sizes of pipe clamps available) I noticed a truck ahead of me stopped at the side of the road within our community. I thought that it looked like plumber, and as I had not had a return call yet, I pulled up next to the truck to see if he could help. It was our plumber, who was dialing my number at that very moment.

Within the half hour the pipe was clamped, we had moved most of the damp insulation out, and were enjoying a cold beer. There is plywood over the whole in the bathroom ceiling, the heat is set at 50° so things won’t freeze, and we await final repairs. I sure hope this is the end of frozen pipes for a while.

Back on December 17th, a cold storm came through and we had some snow. My daughter was delighted, although disappointed when it did not last until morning.

So we did get snow. You could see it falling.

Mandy liked the snow (not!).

It filled the yard

Covered the riding mower (not really a tractor)

And covered the grill

And when we went north of Anza the next day, we did see real snow and threw it at each other.

In a recent article in Scientific American, there is a major statistical blunder. In the article, A Great leap in Graphics (subscription required), the author discussed the time it would take to render the images in their recent movie Cars. Sciam wrote “Even with Pixar’s fast network of 3,000 state-of-the-art computers, each second of film took days to render.”

This is absurd on its face. The film is 116 minutes long. If it took “days” and you assume that is merely more than one, that would be 13,920 days or over 38 years. I don’t think it took that long to make the movie.

Days of CPU time (with the reported 3,000 computers) I would buy. But not days per second of elapsed time.

It finally happened. After basking in the idea that my local disk space was unlimited, I finally hit the wall.

It started with the computer in the observatory. I was taking AVIs of Jupiter, and it was taking a long time to allocate disk space and then started giving warnings about lack of space. This is a relatively small (80 GB, small by today’s standards, anyway) drive. I started to move older data to the second drive on that machine, a 40 GB drive. Problem solved, I thought.

Not so fast. After a few minutes, I got a warning that the second drive was short on space. The move aborted, I was OK with about 10% free on the working drive. Over full by my standards.

Then things went from bad to worse. Or the problem got broader, anyway. I noticed that my main drive on my main desktop machine, a 160 GB drive, was down to 7 GB. Given that I was moving around 800 MB AVIs, that is full for all practical purposes.

Today I cleaned things up. The Observatory computer is still fairly full, but not critical. I compressed 60 GB of AVIs and freed up about 35 GB. Some AVIs compressed by 96% (small object in a dark sky, no doubt). I did a directory command and sent it to a text file via “>”, created a macro to change the file name into the commands I needed, and it ran for several hours. I am now at 56 GB free, a little over 30%. I have breathing room, but I think the next computer will need a terabyte, and I should get another external drive!