Coffee Space

TL;DR

NASA’s ‘NASAView’ is closed source - I decided to make an open source version and port the code to Java. I’ve had nothing but tonnes of issues in doing this, neither my code or the original code passes the original tests. If that wasn’t fun enough, my code doesn’t operate the same as the original code either.

Introduction

Once again I found myself browsing the interwebs and found this page “An un-edited view of Saturn”. My interest was peaked an I decided to follow along with the article.

Viewing ISO

It’s great that these are on archive.org, but like all old CD-ROM’s they are not quite ‘ISO CD9660’ enough so they don’t mount on Windows 10, or OS X. So once more again I used Qemu & a raw disk image, xcopying the CD to the disk and using 7zip to extract the disk onto the native filesystem.

I thought “ah, maybe this person is just not using the right tools”. I looked up what a CDR image is - seems to be just an ISO in a different name. I rename and open with the archive manager - incorrect format. Damn.

All this messing around really isn’t for me - and this is supposed to be the easy part. I simply mounted it using the default Ubuntu disk mounter and it worked! Why on earth it was in some crazy format anyway is beyond me…

Me: 1, NASA: 0

Viewing Images

Seeing that Voyager 2 was launched in 1977, and didn’t rendezvous with Saturn until 1981, it’s safe to say that the images are not in TIFF, GIF, or anything that modern machines will read. Instead they are compressed with Kris Becker’s implementation of Huffman encoding.

So again I thought “maybe this guy just didn’t try each tool to open the images”… After exploring everything I had installed, then DuckDuckGo - these formats really aren’t supported. They also aren’t documented anywhere, awesome!

Me: 1, NASA: 1

Use The Source

Thankfully the source to the compression, and various manipulation tools are included in both C & Fortran.

I looked around the internet stupidly for the tool - and then I realized it was included on the CD image itself. Makes sense! Try to build - nope.jpeg.

Me: 1, NASA: 2

It was not to much work to get the C version to build, and have it detecting a 32bit LittleEndian machine.

So I eventually get the code compiling and export to the required FITS format for the conversion. I then run through the convert tool - EOF error. Turns out that there is still some issues…

(A patch can be found here.)

Me: 1, NASA: 3

Debugging

So I decided to throw in some printf() statements and find out what the heck is going on. Oh damn. Turns out that the insertion sort returns a badly (read: unsorted) sorted list of frequencies. Now I know the NASA implementation probably is a little different (it sorts two lists at the same time), but this doesn’t seem like the behaviour wanted from any kind of sort function.

I suspect:

• Compiling the code for a 64 bit machine somehow causes issues. I haven’t been able to find any architecture specific assumptions in their code (other than byte ordering), so I’m not sure about this one.
• The byte ordering is still somehow incorrect or not working. It’s difficult to figure out exactly what format the image data comes in and which format they want for processing the histogram data.
• Something I’ve missed or assumed is acting screwy.
• The code’s tests never worked correctly, but the conversion process did.

For this one I think we both get a point, I for discovering there are some issues and one for them for fooling me into thinking this will be simple.

Me: 2, NASA: 4

Implement My Own

Here comes in ‘OpenView’, a (soon-to-be) open-source version of ‘NASAView’. It to generates a difference answer during debugging to the original code. Yaay! After testing the encoding swap, at least this code actually works in that respect though (using the ported code from the C version).

There appears to be some issue still in generating the huff_tree() with different nodes appearing in both implementations, but without some working code to compare results against, it’s quite difficult to see exactly what it was actually supposed to do.

The best bet is probably to get the C version up and running, as it did at least historically once work. It’s very possible I introduced some bug in porting the code from C to Java, the code makes high use of pointers, which of course are not easily manipulated in Java.

What I may attempt to do is to isolate the different functions within both my implementation and theirs, and to individually test these against one another in a script. This should at least isolate the obvious differences within both sources.

Given my initial cocky-ness of thinking this may actually be easy and it would only take a single evening, I lose a point.

Me: 1, NASA: 4

To Be Continued

So obviously I’m not giving up, I’ll be having my NASA Voyager images one way or another! This code will exist, but obviously it doesn’t seem like tonight is the night for that.

Expect this story to be continued…