Block Model Compression Algorithm
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
Block Model Compression Algorithm
Software Engineering
Introduction
This project is presented as a gamified design and implementation challenge. You are required to develop and
upload either an .exe file or a Python script to a verification service on a web site. The program you deliver has
to take uncompressed input data on standard input and produce compressed output data on standard output
with no loss - see below for details. The verification service will execute your code and score it on processing
speed and compression performance and put the results on a leaderboard showing all the results from all
teams. The group that submits the best performing program in each category by the end of the semester will
win the competition in that category. Each group can enter as many times as they wish. The leaderboards will
always reflect your best entry to date so you can experiment with different techniques without losing your place
on the leaderboard.
Algorithm Background
Images that do not contain many colours can be compressed by grouping neighbouring pixels into larger parent
pixels of the same colour, as can be seen in the first term of the sum below. Where this is not possible, the
remaining parent-sized regions, as shown in the last term, can be encoded as collections of rectangular regions
of uniform colour that pack to perfectly fill each region.
This technique is especially effective for low colour resolution images in 3D. Such structures are commonly
used to represent geological domains in the Earth’s crust and are known as block models. This project
involves developing algorithms for such compression on very large block models and can explore GPU as well
as CPU techniques.
Functional Requirements Detail
Input
Input block models are provided via a text stream on standard input.
The first line contains 6 comma separated natural numbers:
x_count, y_count, z_count, parent_x, parent_y, parent_z
The first three (x_count, y_count, z_count) specify the number of columns, rows and slices in the block model
respectively, much like the width and height in pixels of an image but with an additional Z dimension for the
number of slices there are or depth. The second three (parent_x, parent_y, parent_z) specify the parent block
size in each of these dimensions to use for compression.
www.maptek.com
For example, the first line in the stream that defines the small map of Australia above is:
64,64,1,8,8,1
This indicates that it’s a width=64, height=64, depth=1 model and that it needs to be compressed using a 8x8x1
parent block scheme.
The next n lines of the stream specify tag, label pairs, one per line, defining all characters that will be seen in
the remainder of the stream and what labels they correspond to. This is known as the tag table. The end of the
tag table is marked with a single blank line.
For example, the tag table for the small map of Australia above appears next on the stream as:
o, sea
w, WA
n, NT
s, SA
q, QLD
n, NSW
v, VIC
t, TAS
Finally, the individual blocks comprising the model are provided as x_count tag characters per line, y_count
lines per slice z_count slices with a blank line separating each slice. The columns in each row are streamed in
the positive x direction (left to right order). The rows in each slice are listed in the positive y direction (bottom to
top order). The slices in each model are listed in the positive z direction (bottom to top order).