Also, for compressing into 8 bits - is this not like saying "I can compress all of Shakespeare's plays in 6 bits" because there are ~39 plays, but then the size of the "shakespearezip" is just the sum of the works?
This encoding already goes too far towards “support the existing flags”.
As a simple example, look at the pattern of the flag of the Comoros (https://en.wikipedia.org/wiki/Flag_of_the_Comoros). Even using just the top colours (FTA: “red, then white, blue, yellow/gold, green, black and orange”), there already are 7 × 6 × 5 × 5 × 5 = 5,250 ways to colour it so that no two neighbouring colour bands are identical. That alone doesn’t fit into 12 bits.
Even limiting one to all colours different, there still are 7 × 6 × 5 × 4 × 3 = 2,520 colourings using the 7 most popular colours. That’s (just) over 11 bits.
And then, you still have to encode the crescent with the four stars.
We could also complain that the crescent is a complex primitive. Why not define it with three parameters: two circle radii with a center offset?
Choosing the primitives is hard and requires domain knowledge/taste, and finding a simple enough implementation solving for key usecases (e.g. decent coverage of maps, meaningful bit encoding) and descoping (e.g. deciding on no emblems) is also hard.
But I am personally impressed with the primitives the author created and the scope simplifications done to achieve it.
In fact, the article says
> With this (rather primitive) format I managed to encode 128 flags with varying success.
Which means that, actually, 7 bits would be enough.
So, this comment is (correctly) pointing out that requirements are imprecise.
You may find such "rules lawyering" obnoxious, but I think that in the real world tasks it is often useful to clarify such things, because it let's you avoid doing hard and complex work that is actually not needed.
I think that every experienced developer has this automatic response to reading a list of requirements: "here is a shortcut that will technically fulfill all the requirements. Please, either tell me that it is okay to do it, or update your requirements to close this loophole".
[0] https://read.vantezzen.io/miniflags#3d8e32040c2a808e8d95c8a0...
As a side note, the title is not accurate either because the method in the article can compress only one flag to 11 bits:
> Using this format, the average flag can be represented in 76 bits, with a median of 55 bits.
One can use Huffman encoding (the same encoding the article uses) to compress one of the flags to a single bit.
The techniques here let you encode the currently existing flags but aren’t really enough to build a flag from scratch.
While in fairness the remaining flags seem like they would need more hard coded symbols, it’s still interesting as a procedural plausible flag generator.
Obviously an arbitrary bitmap of dimensions that could be used for a recognizable flag would need orders of magnitude more storage. The constraint that we are representing a finite set of flags is what admits such a compact representation.
[1] https://www.unicode.org/Public/emoji/latest/emoji-sequences....
also then it's no different from a svg sprite