An endeavour to reverse-engineer the file format of D-Sat 1.
What is it about?
D-Sat was a series of CD/DVD-ROMs from the 1990s which contained aerial and satellite imagery of Germany.1 The data was stored in a proprietary file format and thus can only be used with the original Windows programs. Since this is not sustainable, this project seeks to reverse-engineer the file format and develop tools to access the contained data (coordinates, images, etc.).
The first post on decoding the city database is a good starting point for further reading.
Next Steps
- test SK-42 and derivatives (check older usenet discussion on how to decode the geo coordinates)
Files
file name | comment |
---|---|
dsatnord.mp |
data for D-Sat 1 CD 1 |
NPLS32.DLL |
NPAPI browser plugin for Netscape/Firefox |
-
The CD/DVD-ROMs of D-Sat 1 and 2 are available in the Internet Archive. ↩
Posts
Visualising Entropy
Our quest to find the tile index of D-Sat 1 continues. I have described before, what I mean with “tile index” and I have also given a clue that I found something in the first part of the big blob of data
dsatnord.mp
which I namedun1.dat
.Finding something unexpected
After having visualised the “uncharted” parts of
dsatnord.mp
our quest to find the index for the tiles continues.Searching for the index
Now let us inspect the unknown segments between tiles where I suspect the index for the tiles. First, we extract all unknown parts:
Getting an overview on the file content
In the last post we already gained a good overview on the distribution of tiles in
dsatnord.mp
. Together with the first post this allows us to find the parts of the file which we do not understand, yet.Visualising the tile size distribution
With mp.py’s
offsets
command we can dump tile byte position, size, width and height as follows:Understanding the image header
One important question remains: Are the tiles in
dsatnord.mp
stored with or without gaps? To find this out, we would need to know the actual byte size of each tile. But how to find that out? Well, one guess is that the data/file size of each image is stored in its header. The following Python code prints each consecutive 16 bits (two bytes) among the first 20 bytes as unsigned little endian integer:Viewing tiles with Firefox
Knowing the offsets of (potential) tiles, we can pick one (56057877) and extract the tile into a file:
Learning about the image format
The tiles are apparently stored in the lightning strike wavelet-compressed raster image format. Apparently, there exists no free software to work with such files. Here’s what we found:
Finding the tiles
To find the image tiles in
dsatnord.mp
and possibly decode them, we had a look at the decompiledlsd26dll.dll
. My colleague Jan found the functionCLsDecode::GetImageDataSize
and figured out that the first linesDecoding the city database
Note: This post is a copy of the original web page I set up in 2005.
subscribe via RSS