D-Sat

D-Sat was a series of CD/DVD-ROMs from the 1990s which contained aerial and satellite imagery of Germany.¹ 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.

Posts with tags: cis-cod, coordinates, dsat, tiles

Posts

• 
  Jul 28, 2024

  Solving a mystery (and finding something unexpected again)

  We have now mapped almost all parts of dsatnord.mp except for the one I have dubbed unknown2. Looking at the greyscale byte representation again, we can see roughly five regions with distinct patterns:

• 
  Jul 21, 2024

  Fragmenting the tile data

  When looking at the data segment of CIS/COD images (i.e., the tiles) the byte sequence 0x63 0x6f 0x64 (ASCII: cod) appears several times and thus is conspicuous. According to a wiki page describing a derived video codec it marks the end of a “plane”, a basic building block of wavelet-compressed images. In this post we explore the size distribution of these blocks.

• 
  Jul 4, 2024

  Finding something unexpected again

  This week I was poking around in the few remaining unknown territories of dsatnord.mp with the excellent Kaitai Struct Visualizer (ksv) again. I have known for quite some time now that the city database is followed by some strings that seem to be related to the development of that database, namely D:\Dsat\Dsat23\CityDlg.cpp and c:\temp\cityname.bin. When I showed my colleagues that part using ksv, it looked like this:

• 
  Jun 27, 2024

  Documenting the file format

  Since the first post on decoding the city database I have learned so much more about the structure of the D-Sat file format: where the image tiles are located, how they are indexed and which information the image header reveals, as well as that the file also contains points describing borders and highways.

• 
  May 11, 2024

  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 named un1.dat.

• 
  May 6, 2024

  Finding something unexpected

  After having visualised the “uncharted” parts of dsatnord.mp our quest to find the index for the tiles continues.

• 
  Apr 23, 2024

  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:

• 
  Apr 22, 2024

  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.

• 
  Apr 21, 2024

  Visualising the tile size distribution

  With mp.py’s offsets command we can dump tile byte position, size, width and height as follows:

• Apr 20, 2024

  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:

• 
  Apr 19, 2024

  Viewing tiles with Firefox

  Knowing the offsets of (potential) tiles, we can pick one (56057877) and extract the tile into a file:

• Apr 3, 2024

  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:

• 
  Apr 2, 2024

  Finding the tiles

  To find the image tiles in dsatnord.mp and possibly decode them, we had a look at the decompiled lsd26dll.dll. My colleague Jan found the function CLsDecode::GetImageDataSize and figured out that the first lines

• 
  Mar 26, 2005

  Decoding the city database

  Note: This post is a copy of the original web page I set up in 2005.

subscribe via RSS