As an input, a two-dimensional image or landscape is given by an a x a square of black-and-white pixels.
Your code should create an approximation of this landscape by a set of superimposed circular disks. It should aim at the best possible accuracy for a given maximum number of circular disks that can be varied as part of the input. It should also be able to generate a lossless representation of the image/landscape using an unlimited number of circular disks.
Assume that each pixel is b/w, that is either completely black (colour value 0) or completely white (colour value 1), not on a greyscale in between.
Have your code produce a sequence of m circular discs 0 ≤ i < m, each with two coordinates of the centre, a radius, and a colour value ci, that compresses the pixel-based representation. The conversion back from the vector representation to the pixel representation could look as follows. For all pixel coordinates (0, 0) to (a-1, a-1): Initialize the pixel colour to black. Then, iteratively for all i from 0 to m-1, whenever the pixel coordinates are inside circle i, update the pixel colour to ci.
Agreement between the original and the compressed version can be quantified by the fraction of pixels for which the algorithm above reconstructs the original colour value of the pixel correctly. In the case of a lossless compression, the two versions should agree for all pixels.
You can deviate from the default recommendations; follow them just if you do not see any good reason not to.
See the image-benchmark pixel/vector graphics generator code.
See also the benchmark series of pixel graphics (BMP and Charmap formats) with 4x4, 8x8, …, 1024x1024 px.
It is both allowed to place circles with the same or with the different colours directly on top of each other. It only counts how well the vector-graphics and pixel-graphics versions agree in the area where there are pixels, that is, within the square; the part of a circle that goes outside this area is irrelevant.