Blinking cepheid variable stars in Messier 13

Something that feels like a once in a lifetime event happened here in Bergen this spring. We had four consecutive days of clear skies, with very little wind and no moon!

Earlier on the blog I have expressed the desire to try and image Messier 13 on consecutive nights, to see if I could see the difference in magnitude in the variable stars in the cluster. Especially the variable star V1553 Her, which has a very convenient period of approximately 5 days. 4 days of observing would get me most of the period.

These 4 days were pretty late in spring (30th of March to 2nd or April), and observing had to be done after 10PM in a work week. Not ideal. Thankfully except from the usual tracking problems, there were few problems with the equipment. My own patience failed while doing focusing though, which resulted in two nights with good images, and two with not so great quality.

This was a bit problematic since I wanted to compare images over time, and since I had 40 good images from one night, and 10 from another there was a big difference in the brightness of the stars once I was done stacking images from each night. To account for this I did some brightness matching in post processing matching on the non variable stars of each frame.

The resulting 4 frame time-lapse looks like this.

I was pretty happy with this, as it shows the variability of not only one, but at least one more, and maybe even a third variable star I missed at first (Can you find it? This paper has charts to help). The change in brightness especially for V1553 Her was also much clearer then I expected. Great success!

The process to find the distance to the star from the magnitude and variability data is neat. Since V1553 Her is a Type II Cepheid (how this was determined is not clear to me, please add a comment if you know) which period is approximately 5 days the star has an absolute magnitude of approximately -1.5 according to this chart. The formula below (from here), should then give the distance \(d\).

$$ M_v = m – 2.5log((d/10)^2) $$

Looking at the images and the reference stars, a rough estimate would be that V1553 Her varies between 12 and 13 in apparent magnitude. Plugging in -1.5 for \(M_v\) and 12.5 for \(m\) gives the distance of 6310 parsecs, which is 500 parsecs off.

While I have not followed a very thorough process here, it is anyway nice to verify that my data seems to fit to reality. To get better data for deep space objects, I am evaluating to get a solid equatorial mount with either a small refractor or an 8 inch newtonian for imaging, and keep my dobsonian for visual and planetary. Once I do I hope a can revisit this project and get a time-lapse with much higher quality. Maybe do one which would also capture the really fast variables with down to 0.2 days period.



Using Jetbrains products in a VM and on the host at the same time

I have been hacking on some libcamera experiment, and this time I had the misfortune to have to try and use a Jetbrains product in a local VM and on the host system at the same time.

Since it is practical I was using UTM shared networking, but that had the unfortunate side effect that Clion in the VM and IntelliJ on the host detected each other and refused to both be open at the same time. Incredibly annoying…

Googling I figured out that if you use the same username in the VM and on the host it will all work out. I got more and more confused as to why this feature exists, but a glimmer of hope emerged. I was not ready to change user in the VM or on the host though, since I had used some time to set up that user.

Thankfully, this detection feature uses the JVM system property user.name, to lookup the user, so adding -Duser.name=<host username> to the clion64.vmoptions file made it all work out.

Major annoyance averted!

I ❤ globular clusters

I love observing globular clusters visually. There is something very satisfying about turning the focuser to try to resolve the maximum amount of stars.

On the 12th of march I did an observing session in moonlight and quite a bit of wind, and I finally learned why astrophotographers dread wind. The telescope kept shaking, and had to park my car in front of the telescope to get it to be usable at all.

That had the sad effect of blocking most of the sky I was interested in, but M3 and M13 were still visible. After doing some visual observing I did some very lucky imaging in the wind. Of about 350 exposures of M13, about 70 were decent, and 10 of those were good. Stacking those 10 gave me this image.

M13 (Hercules Globular Cluster), image using my 10″ skywatcher dobsonian, a Televue powermate 2x, and my Canon EOS RP. This is 10 exposures of 8 seconds at 12800 ISO, stacked using APP.

The star density in such a cluster can be up to 1000 stars pr cubic parsec. Imagine living there…

Astro observation log 27.12.2021

Finally clear skies and I was at a bortle 2 location. I also had my new Canon EOS RP Camera.

M 42 – The Orion Nebula again

M 42 at a bortle 2 location was great! Last time I imaged the Orion Nebula I struggled with tracking. This time I had fine tracking (for my dobsonian anyway) and I finally got pretty round stars. I got 20 good 15 second exposures at 1600 ISO. After stacking in AstroPixelProcessor and post processing in Pixelmator Pro i got this result:

Around 15 light frames, and 20 dark frames stacked.

NGC 2024 – Flame Nebula

I have tried to observe the Flame Nebula visually many times, and I have failed every time. I was therefore planning to only do some testing photos of the region. I had trouble lining up the finder scope and camera, and I therefore did some visual observing. The nebula showed up surprisingly clear. Bortle 2 skies are really something.

Once back inside I regretted not observing more carefully visually as well as taking several image sequences. The Horsehead Nebula showed up quite clearly in my images, and with the bortle 2 skies, maybe it would have been visible visually as well.

5 lights stacked of the Flame nebula (upper left), Horsehead nebula (lower right) and NGC 2023 in the lower middle center.

M 33 – Triangulum galaxy

The galaxy showed up very clearly, and I got some images. Sadly the tracking worked badly in that region of the sky, and my focus was off. Looking forward to try this again some other time.

Single M33 shot

M 1 – Crab Nebula

I also got some images of the crab nebula. My focus work was not great, and I should use my Powermate next time, to get more nebula data.

NGC 281 – Pacman Nebula

I have tried and never even gotten close to observe this visually before. This night it was visible, and I got few images that were fine. I do not have enough data to stack, but my single ok light frame looks like this:

NGC 869/NGC 884 – Perseus double cluster

This cluster is easy to find, and with little battery left, and tracking that was not working, I decided to do 2 second shots. Stacking those resulted in this, which by far is my best open cluster image to date.

NGC 869 (left) and NGC 884 (right)

Closing thoughts

All in all this was a very rewarding session, and I finally got some deep sky data that was worth it to process. The Orion nebula image turned out way over my expectations.

I am thinking about getting an equatorial mount, and maybe a guide camera, so I can take longer exposures. It was also really great to finally see some of the more difficult nebulae visually.

Here’s to hoping I get a night in 2022 that beats this one.

Adventures in creating a Snap from an LWJGL2 based game

The old Artifact is still kicking, not too long ago I created a Snap for it. Creating the Snap felt a bit like concocting a magical snapcraft.yaml and and hoping it works out. For the first few attempts the magic never works out, and the process of figuring things out tend to be tedious at best. This was no exception. Here are some of the problems I ran into, hope it helps someone else.

Xprop missing

My first Snap attempt immediately spit out this during startup:

java.io.IOException: Cannot run program "/usr/bin/xprop": error=2, No such file or directory

This was fixed by adding these lines to my snapcraft.yaml. The layout is needed since xprop is referred to by an absolute path. See this thread for more information.

layout:
  /usr/bin/xprop:
    bind-file: $SNAP/usr/bin/xprop

parts:
  mypart:
    stage-packages:
      - x11-utils

A xrandr puzzle

Next in line was this:

Exception in thread "main" java.lang.ExceptionInInitializerError
	at org.newdawn.slick.AppGameContainer$1.run(AppGameContainer.java:39)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.newdawn.slick.AppGameContainer.<clinit>(AppGameContainer.java:36)
	at game.Artifact.main(Unknown Source)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
	at org.lwjgl.opengl.LinuxDisplay.getAvailableDisplayModes(LinuxDisplay.java:951)
	at org.lwjgl.opengl.LinuxDisplay.init(LinuxDisplay.java:738)
	at org.lwjgl.opengl.Display.<clinit>(Display.java:138)
	... 4 more

This was caused by xrandr not being installed in the snap, which LWJGL2 uses to find display stuff. This was fixed by adding the x11-server-utils package, which installs xrandr.

stage-packages:
  - x11-xserver-utils

For debugging snaps and finding packages these commands were great.

#This allows you to look at the system as seen from the snap
snap run --shell <your-snapname> 

#This will give the package that installed an executable, in this case xrandr
dpkg-query -S /bin/xrandr

I hope this helps someone else looking to get their application in a Snap.

Observation log 18. of April 2021.

Conditions were not great, moonlight was a pain, and some red light leaked from some camera status light into all of my M3 images.

On the positive side I finally got to see M3 and M5 and also M57 (Ring nebula), and I got decent images (for me anyway) of M13 and the leo triplet.

M57 (Ring Nebula)

I have long wanted to try to observe a planetary nebula, but I think I had the size all wrong. I was looking for something larger.

In my finder scope M57 looked a lot like a star, and if it was not so easy to locate due to being in between two bright stars I would have probably scanned past it. Once I found it, the ring structure was clearly visible at medium magnification. Really neat!

I think that having calibrated my expectations now, finding other planetary nebulae will be easier.

M13 (Hercules globular cluster)

Earlier this year I ordered a 2x TV Powermate mainly for planetary observation. To test it I tried using it together with my 2″ Aero on the globular clusters and M57. It worked way beyond my expectations.

I also took 15 seconds exposure of M13 below (the most my tracking was good for). The two red spots I marked are two variable stars, which I found comparing the chart here to my image.

M13, with two marked Cepheid variable stars. These are stars are used as distance measures, since their period determine their absolute (actual) brightness.

These stars have a periodic change in brightness. The period of their change in brightness determine their absolute brightness. Then the relative brightness (the brightness observed from Earth) and the absolute brightness can be used to find the distance to the star.

It would be really nice to try and observe M13 with the same magnification over time, and see if I can catch the blinking.

Leo triplet

I observed these galaxies visually some time ago, but this time I got to take a series of pictures as well. Out of like around 20 exposures of 15 seconds, I got 6 images that were fine. After stacking this was the result. Noisy, but some structure at least.

M65 top right, M66 to left, NGC 3628 bottom

I had a lot of fun this night!

Artifact Snap and AppImage for Linux

Some time ago I added an AppImage for my old game Artifact, as an easy way of installation on Linux. AppImages have a neat architecture, and hopefully will keep Artifact running for a long time on a lot of systems. AppImages can also be run sandboxed using Firejail if you have little trust in me or the source of the AppImage.

Artifact running as a Snap

Now, AppImages do not really have a nice centralized location where applications can be discovered. There are some initiatives, but it feels a bit crude and lacking some polish.

Snaps and their central registry on the other hand feel way more polished. If anything the content in the store often feels unpolished compared to the store. Snaps also run sandboxed by default. While this is good, it sometimes causes unexpected issues, and can be opted out of.

Making a Snap of a LWJGL 2 application was a bit of a headache, but it worked out in the end. My experience with the Snap documentation in general was good, and most of the work was a breeze after I got the game running as a Snap.

Now, go play some Artifact on Linux!

Babynavnvelgeren – Fast exploration of Norwegian given names

My good friend Feda Curic recently came to me and wanted to make something together during his parental leave. At first we started out with something a bit too ambitious (for the time we had set aside), but then his wife came up with a great idea we could finish in our limited amount of time.

She wanted an app where you could quickly look up names for babies. Here in Norway Statistisk sentralbyrå (SSB) has statistics for all names used 4 or more times. The SSBs user interface leaves something to be desired though. It is either small lists containing some names, or a name search, where you input the exact name, and then get statistics about that specific name.

The SSB interface is not at all useful for exploratory search for names. In Babynavnvelgeren (the app we made) we have a lightning fast interactive search and filtering options. The data is available locally in the app, so it mostly works offline as well.

The very simple but effective UI of Babynavnvelgeren

Babynavnvelgeren makes searching for names easy and fun. My 8 year old daughter loves searching while sorting for the least popular names. She found some very interesting ones like:

  • Sau – Sheep in Norwegian.
  • Lillebil – I initially thought this was a bug for sure, but it is a name. My daughter finds it hilarious (“Lille” means small and “bil” is car in Norwegian).

More generally I think Interactivity and responsiveness is essential for exploration, and the process of exploration often leads to accidental discoveries and new hypothesis building. UIs which support this kind of interactivity are very useful in my experience, and I think more applications/data providers should have this in mind when presenting their data.

I also think there is a lot of low hanging fruit in this space, and small improvements in interactivity often cause massive increases in efficiency. For Norwegian names, Babynavnvelgeren has got you covered. Go get it!

Astro observation log

As a kid I was always very fascinated by astronomical objects. I vividly remember the first time I observed the Andromeda Galaxy in a pair of binoculars. I think I was around 14, and I had tried to find it several times before. I did not really know what it would look like in binoculars, and I remember freezing my hands off to keep it in view once I found it. Even if it was just a blurry blob it was amazing.

Fast forward 20 years, and I now have the knowledge, time and money to buy and use a telescope. I recently bought a 10 inch Dobsonian. I am still learning to to use it well, but it has so far been worth every NOK spent.

Last night was my first observing session with the telescope under not extremely badly light polluted skies. These are the objects I have observed so far.

M35 and NGC 2158 (Open cluster in Gemini)

M35 is huge, and looks great on low magnification. It was also not very hard to find by following the stars in Gemini. It would be useful with an even lower magnification eyepiece to observe this next time.

M37(Open cluster in Auriga)

Since it is far away from the closest clearly visible star, it was a bit hard to find even though it showed up pretty clear in the finderscope once I was in the right region.

M42 (Orion Nebula)

This is so far the only nebula I have been able to observe from the city. Sadly Orion was not visible when I observed in the less light polluted location. I have not yet tried filters for contrast, but M42 is still very visible, and it looks great. Looking forward to observe this with filters and less light pollution.

M13 (Hercules globular cluster)

M13 gave M42 a run for its money. M13 was easy to find (shows up clearly in the finder scope), and at low magnification it looked great. Increasing the magnification made it awesome. Suddenly thousands of starts exploded into view.

M65 and M66, part of the Leo Triplet

With the light pollution at the time, M65 and M66 were visible but with little detail. They were not visible in the finder scope, and I just randomly found them scanning from the stars in Leo. They pretty much both looked like Andromeda in binoculars. I am hoping to see some more structure next time.

I also observed some galaxy in Virgo, but I have no clue which. It seems the area is filled with galaxies, and I found one just scanning around. Pretty neat.

♥ Princesses versus giraffes ♥

TLDR; I’m writing a coop multiplayer game with my daughter, this is the current result! Works in Firefox and Chrome. Use arrows to move and space to fire. Share a URL to play with a friend.

Some years ago, my daughter figured out I made some computer games, and she even played one of them quite a bit. After a while she wanted something new, and we figured we’ll make a game together. She would draw concepts and come up with ideas, and I would try to make them happen in game.

The initial concepts she drew were these:

We then together made them into vector with some modifications.

Princess and "giraffe"
A princess and a giraffe… I guess

Tips on kid friendly vector drawing programs would be very much appreciated, throw me an email or post a comment. We used Sketch, but Sketch is a bit overwhelming and distracting with all its features. I want a program which only have bezier patches and transformations on them, as well as fill, stroke and possibly opacity settings.

Going from concepts to a prototype

I had been wanting to try compile to JS with Kotlin for a while, so I started a project in IntelliJ and quickly threw something together using a plain HTLM5 Canvas.

We drew some more concepts, and after some evenings implementing we had an infinite randomly generated castle, an arrow firing princess, a hyperactive bow carrying giraffe, and a bunch of collision detection bugs (yay for rolling your own).

Wriggling out of hard requirements

After a lot of fun triggering bugs, my daughter came up with some new requirements.

I want to play with my friends, and we should all be princesses!

These are sort of hard to implement, disregarding networking, it would mean a total rewrite of how the world generation and camera worked. It would also need a solution for how to avoid someone getting stuck due to the camera movement of others and so on.

Those giraffes are in for a surprise.

After some bargaining we made some new concepts, and we agreed to add a player controlled cloud, and a bunch of new giraffes.

Adding networking

For me this meant that I would need to add some kind of networking to the game. For browser games, the choices are:

  1. Communicate with a server using WebSocket and have that relay state, or run the game on the server.
  2. Negotiate a WebRTC datachannel, and send communication directly between the browsers.
  3. Have players install a browser extension like netcode.io,and use it instead of WebSocket.

Since the game is cooperative, there is little reason to run the game on a server. Actually I really, really do not want to run the game on server, for a bunch of reasons, mostly for abuse and scaling troubles.

Using a server as a relay of state or input is also a bit funky, since it will introduce a lot of unnecessary latency. Since I am also willing to sacrifice some poor kids behind a symmetric NAT, I decided for option 2 and I have not regretted that.

I was cautious about doing this initially, since I had read this Gaffer on Games post which deemed WebRTC too complex, though that was in the context of server based architectures.

Having some more experience with WebRTC now, I agree a bit about the complexity, though I think it has gotten way better, especially with a more stable standard and more complete alternative implementations like rawrtc. I also ♥ how WebRTC abstracts away most of the P2P complications behind a very nice API.

Autorative peer or GGPO?

To share state in the game, I needed to come up with an architecture for networking. Initially I evaluated using something like GGPO, but in the end I chose to go with using the princess peer as an autorative peer, and sync the state to the cloud playing peer continuously, while the cloud peer only sends input. I chose this mostly for simplicity and time constraints. Since the game is cooperative, a lack of fairness is also not really a problem.

For the amount of work i put in, I am very pleased with how the networking worked out. Right now it is not tuned at all, just JSON over the datachannel, but even without tuning and no extra speculative integration, it has worked fairly well.

Where to go from here.

While the game is in a state of continuous updates, I think it is mostly just going to be small changes from now on. Maybe some sound effects and new graphics when we feel like it.

Rendering is currently also quite slow, and takes a lot of the frame budget. I would like to migrate to a framework with a WebGL based renderer. But sadly that seems like quite a bit of work, mostly due to using SVGs for graphics.

For future projects game projects, I will for sure start with a WebGL based framework, or possibly Unity tiny, and raster based images.

That is all for now, go and see how far you can get in our game!