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.

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.

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.

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.

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

I might have found Ceres

Emphasis on the word 'might'. (UPDATE: Didn't find yet. Details here.)

For more than a month it has been either cloudy, foggy, rainy or all at the same time. Stargazing or astrophotography haven't been possible. I even had two weeks paternity leave and I thought there must be at least one clear night during that but no...

But yesterday November 12th it was! I got my set out immediately after dark and started shooting. Ceres was my goal but it was still below the horizon. I started with Pleiades and continued on Messier objects near Ursa Major since they seemed easy to find on the camera. I still haven't checked the photos if I caught any.

About 20.30 (looks like my camera has it's time set wrong) Ceres has finally risen enough and I forgot everything else. According to Stellarium it was in Gemini near ŋ Gem. So that's where I aimed.

I stacked the image hastily, rotated it to match Stellariums alignment and started comparing stars. Much of my dissapointment I found nothing from the place Stellarium showed Ceres. Strange though. Its magnitude is supposed to be 7.13 and I could see stars with magnitude more than 11. It should easily visible.

Couple stars off, there was an extra one. Not where Stellarium says. And according to Stellarium, Ceres should never be where I think I see it. Nevertheless, an extra star on a place where should be nothing. Quite convincing. I still have to take another photo myself whenever the next clear night is and compare with it. Or try some astrometrics software to recognize everything in the picture, except for Ceres.

Here's the first stack I made. I really have to make a better one and try the astrometrics for it.

Still waiting for my Raspberry Pi

I ordered a Raspberry Pi from RS Components in July 17th. That's the date in the order confirmation they sent me. Estimated time of dispatch was 11 weeks. That was last Tuesday and I still haven't heard from it. Looks like RS Components has had problems getting the devices. Had I ordered mine from Farnell I'd already have it. Even a Finnish electronics store is selling RasPi with delivery times less than one week... At least mine costs only about 30€. Otherwise I'd have already cancelled my order.

This page says I'll be getting my RasPi in late November. Also it should be Rev 2, but I have no idea how that is different from older boards.

My plan to use RasPi to control camera on EQ3-2 and shoot some stars will probably fail. Not because the camera or RasPi but because the tracking mount isn't accurate enough (with my skills at least) to track stars for more than 15 seconds with my equipment. We'll see... Maybe it's worth it just to make the camera shoot 50 photos continuously instead of ten it can shoot now.

I also had other plans for RasPi. A media center with XMBC. I just got an even better plan but that might be outside my skills. I have an old Luxor 3079 amplifier that looks like this:

Luxor 3079. Image borrowed from http://new-hifi-classic.de/forum/index.php?topic=2577.0

It's not working properly. There's a lot of static over everything I play unless the volume knob is exactly in the right position. Luckily that's a good level for volume too. Still it would be better if the thing worked without glitches like that. If I'm able to fix it, I could embed RasPi in it. Why? Why not?