posts tagged with cis-cod
-
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. -
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.
-
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 lines