Friday, March 22, 2013

PanSTARRS comet and Aurora Borealis

I saw a picture of the comet PanSTARRS (C/2011 L4) taken in Turku Finland at March 16th 2013 and decided that to go out and search it myself the next day. So Sunday the 17th I went to Kuuvuori (Moon mountain in english) in Turku with some other stargazers who were there yesterday. I was at the spot at 18:50 and started to set up my equipment.

At about 19:50 we found it on my dobson. Hmm... I better check the time because this seems quite late. 19:52 says the EXIF timestamp of my first photo of it. Maybe it was a bit earlier... Anyways here it is.


Whoa! Or not much to see... Depends on how much you respect the astronomy itself. That photo is actually not the first. All the photos through my dobson were more or less blurred. This was taken with 75-300mm zoom lens at max zoom. Maybe I should have shot a video through the dobson, like I do with planets.

Couple minutes after really seeing the comet something happened. I saw "clouds" on recently clear sky, or at least I thought I did. The "clouds" turned green and the show started. All the previous Aurora Borealis I've seen had been faint and required a bit of imagination to see. This one did not. The sky was flashing green and purple so fast my camera couldn't catch it. I saw arches, rays, something that reminded me of a scifi movie "warp speed".

Warp speed
For a while northern lights filled the whole sky. I decided to enjoy the view rather than fiddle with my camera to get better pictures. I got one with both the comet and Aurora in view. Comet is quite small in the photo so I marked it.


I had my camera on an equatorial mount so the ground is tilted. Don't mind that.

I won't lie when I say that half an hour was probably the best show I've ever seen.



Saturday, February 9, 2013

Comparing planet stacking software

Living near city lights makes it quite difficult for me to see deep sky objects. I see many, but has to be an excellent weather. Planets are a lot easier target. Lately Jupiter has been in a good position for viewing. I've also tried to take a lot of photos. One of which was quite a success (with my skills and equipment) because you can see the moons as well.

A single shot of Jupiter. No stacking used here. 
This is the first photo ever I took of Jupiter that didn't require any imagination to recognize the planet. Well... best of the hundred I took that night. But still just a single shot and a bit help from Gimp.

Planets should be photographed by taking a video and stacking that. I've found 3 software to do that. RegiStax, AutoStakkert! and AviStack. None of them is open source but AviStack should work on Linux once you succeed on installing IDL Virtual Machine. For some reason I can't make it work.

I took my Skyliner 200, 2x Barlow, Canon EOS 1100D and a laptop with EOS Camera Movie Recorder (which is open source, yay!). I recorded this video:


...or actually about 6 of those. They're all quite identical so no need to share them all.

With the same movie I tried four different stacking software. My skills with them are almost non-existent so this comparison is mostly about how well the programs do automatically.

Here's the result:

I used drizzle when available, but I have no idea whether that was a good idea. I'm quite sure there was no need for it, but I don't know if it did any damage. This need more testing.

Autostakkert was perhaps the most automatic. It also did the best job although there was no wavelet sharpening. I did that with RegiStax6. The result is a lot better than the image that's also stacked with RegiStax.

Friday, January 25, 2013

Sharpening Moon with deconvolution

I bought a Barlow 2x lens for my Skyliner 200 and immediately went out to test it. I actually got quite lucky to have a clear sky that night. I took some photos of Jupiter and Moon and shared them on IRC. A friend suggested I should sharpen the photo of Moon with something like this: http://www.iceinspace.com.au/63-455-0-0-1-0.html

Having studied physics, I'm familiar with the concept of convolution and I'm aware it should be possible in theory to reverse the process. Still the images on that page seems like magic to me. The software Astra Image seems like a nice program but of course it has a price. I'm not against commercial software and the price isn't too high, but I always try to look for an open source alternative to everything.

I found Grey's Magic Image Converter. It even has a plugin for Gimp. Better yet, it installs right from Portage on Gentoo. There are .debs on their page so probably installation is easy also on Debian based distros such as Ubuntu.

I didn't try the command line version yet, only the Gimp plugin. Some page I found (and lost again so no link) suggested on command line you get better results than plugin. Perhaps there are more parameters to set or something. I'll try that later, but now the Gimp plugin.

I took some photos of the Moon. With my new barlow, I can fit about one fourth of the Moon in one picture. I made a panorama of six photos with Hugin. Because of my haste to get something ready, the images were jpegs from the camera. That's why the dark grey circle around the Moon. I probably should do some editing for the raw photos before stitching the panorama.

The photo is huge. Here's a part of it:


And here is the same photo deconvoluted:

See the difference? I applied (in haste as usually) G'MICs deconvolution filter with almost the default settings and that's what I got. Btw it took quite a while for 4200x4300 image.

Here are the original and deconvoluted photos:

Left one is the original and right one deconvoluted.
EDIT: Looks like Google doesn't show the photos in their original size. I'll add them elsewhere and link here.

Sunday, January 6, 2013

Script to control Canon 1100D on Raspberry Pi

I've finished the first part of my plan to use Raspberry Pi to remote control a camera. I put together the efforts from http://mikkolaine.blogspot.fi/2012/08/controlling-canon-eos-1100d-with-linux.html and http://mikkolaine.blogspot.fi/2012/12/raspberry-pi-canon-eos-1100d-and-gphoto.html and wrote a Python script to do it all.

Why? With the camera itself I can take max 10 photos sequentially after having to go to the camera and press the trigger again, I can use exposure times only to max 30 seconds and as a result I get hundreds of photos named IMG_6013.CR2 and such.

The script I wrote:
  1. Asks for 
    • ISO
    • exposure time
    • number of photos
    • name for the object in photos.
    Name is required for naming the pictures and directory for them.
  2. Sets all the necessary settings for camera. You need of course to aim the camera, focus it manually and set the control wheel to manual mode (M).
  3. Takes number of photos, resetting the USB connection after each photo (because on RasPi this is required)
  4. Downloads each photo instantly from the camera and uploads it to my NAS (mounted by NFS on RasPi). The photos are put to a directory by name asked before and named with a timestamp. For example M42_2012-12-16_16.22.28.099570.cr2.
I just ran a test of 200 photos with exposure time of 31 seconds and it seems to have worked perfectly.

The script and instructions for it can be seen here. It's easier to share files on Google Sites than Blogger and I also want a permanent page of that. I'll update the page to always include the newest version of my script.

Tuesday, January 1, 2013

Mosh - Mobile Shell and unavailable ports

The idea of Mosh is awesome. An SSH-connection that does not disconnect even if network does. On a mobile environment and behind unstable connections an extremely nice feature. After setting it up on our IRC shell server I've been testing it with my Galaxy Tab. I found Mosh for Irssi Connectbot and I've been using it for a while now.

Problem

The server I referred to is almost on our control. It's a virtual server and we have a domain and lots of open ports. No own IP address though. That we have to share with couple other servers. That's why we don't have access to the ports necessary for Mosh. Mosh works by taking a normal SSH-connection and starting a mosh-server on user space. It chooses an open port from 60000–61000. Too bad we don't have access for those.

Solution 1

You can choose the port outside the default range. It's easy. Just connect with
$ mosh -p <port> <user>@<host>
I really don't see this as an option. Our server has at the moment about 20 users. Some more technically oriented than others. To connect, one has to know the available port range (which is 41000-41999 something...) and available port at the moment, since there are 20 other users. Maybe we could give everyone two or three ports for their personal use...

No. This is not an option.

Solution 2

Since the default port range is hardcoded in the source and there is no config file, I thought I'd change the code. In version 1.2.3, in file mosh-1.2.3/src/network/network.h there are lines
static const int PORT_RANGE_LOW  = 60001;
static const int PORT_RANGE_HIGH = 60999;
Change those to preferred ones, make, make install and things should work.

I didn't get into testing this before I found myself once again bothering the developers on IRC. This seems to be an efficient method of solving problems with open source. I only hope the developers don't mind...

Better solution

I had to compile this from source after all, but without any changes. In the Git version they have a feature of giving a port range as an argument to mosh-server. Mosh-server is the program mosh runs on server side after an successful SSH-connection and mosh-client then connects to mosh-server. They both have to know which port to use.

I installed mosh on /usr/local and renamed /usr/local/bin/mosh-server to /usr/local/bin/mosh-server.real. Then I created a new /usr/local/bin/mosh-server

#!/bin/bash
/usr/local/bin/mosh-server.real $@ -p 44800:44999

Mosh calls for mosh-server, which again calls for mosh-server.real passing the original arguments and adding its own port range.

Users don't have to know any of this. They can now connect with
$ mosh <user>@<host>
and everything works as it should.

Best solution (to my opinion)

...would be a server side config file to define the default ports. Too bad there is no such file at the moment.

Tuesday, December 11, 2012

Raspberry Pi, Canon EOS 1100D and Gphoto

I finally have it! RS Components delivered it last week. Now all my free time has gone tweaking RasPi. :)

Because I plan to use RasPi as a media center, I chose Raspbmc as the operating system. It's based on Raspbian, which is basically Debian on ARM with some Raspberry specific packages. I'm sure I can get anything on this.

Then came the problems. Gphoto can control DSLRs and after initial problems, I got it working with my EOS 1100D. On RasPi, however, there are some more problems. First run works properly, but after the first I get only:

*** Error ***
PTP I/O error

*** Error ***
An error occurred in the io-library ('Unspecified error'): No error description available

After googling a bit and asking on #gphoto at Freenode, I found out the problem is not with Gphoto, but with Raspberry Pi. Hardware or software, no one seems to know.

There is a workaround!

After taking a photo with 

gphoto2 --wait-event=2s --set-config eosremoterelease=Immediate --wait-event=180s --set-config eosremoterelease=Off --wait-event-and-download=5s

the usb connection has to be reset. I found a piece of code to do just that: http://marc.info/?l=linux-usb&m=121459435621262&w=2. I copypasted that into usbreset.c, compiled it with gcc usbreset.c -o usbreset, and now taking photos seems to work. I'm running a loop of taking a photo, resetting usb and deleting the photos. While I'm writing this, it has successfully taken over 50 photos in a row.

Next I'm going to write a script to take photos, renaming them and sending them directly to my NAS.

Friday, November 16, 2012

Now I really found Ceres

It's a good thing I emphasized the word 'might' on my previous post. Turns out I did not find Ceres just yet. It's in the picture, but I looked at a wrong star.

There was a clear sky for a while the next evening after my initial photos. I was able to take another set of photos on 12th and 13th November about 24 hours apart. Now the movement of the dwarf planet is clearly visible.



I've marked the dot on both pictures. The right one is from November 12th and the left from 13th. Time is about 20:30 (18:30 GMT).

This doesn't change my opinion on Stellarium. Now I know for sure it shows the position of Ceres wrong for about 10'. I compared it for the position of Uranus (which I was able to photograph yesterday Nov 15th) and that is as correct as I can see on the photo.

Original photos:

November 12th
November 13th