Today Overviewer version 0.12 was released, which adds support for most of the Minecraft 1.8 blocks. You can download it at the usual location, right here on the download page. Not all 1.8 blocks are supported at this time; banners and armour stands are not implemented yet. These will not appear on your rendered map for now.

The new version of Overviewer requires a Minecraft 1.8 resource pack or the Minecraft 1.8 client. If you wish to stick with earlier versions of Minecraft, either use the latest Overviewer 0.11 version or install the Minecraft 1.8 textures.

Report any bugs you find on GitHub, and if you have any questions, you can reach us in IRC. Make sure to check out the official documentation as well.

Hi, I'm CounterPillow. If you've ever been in our IRC channel, you've probably seen me. I have been an irregular contributor to Overviewer for some time now, and recently, I've rewritten the way optimizeimg works. I thought that this would be a good opportunity to explain what it is, and how to best use it.

First, let's explain what this is all about. In essence, this increases the time it takes to render a map in favor of smaller images. But how does it do that? optimizeimg allows you to run various image optimizers against each tile image the Overviewer outputs. As of the time of writing, we support optipng, pngcrush and pngnq.

Lossless vs. Lossy Compression

One of the key things to understand is what lossless and lossy compression mean. In lossless compression, the file size is reduced, but the decompressed data is exactly the same. No data is lost in the compression step, hence the name "lossless". Lossy compression, on the other hand, does not preserve all information. An uncompressed output of a lossy compression algorithm is not the same as the input.

As you may already know, PNG uses lossless compression. However, there are a lot of different knobs to tweak when it comes to how the image is compressed, thus reducing file size without altering the image data, and we can even reduce the amount of colors in the image, essentially making the process lossy! I'm not going to go into detail as to how this all works in practice, but I will showcase the tools we currently support to achieve this.

Lossless Image Optimization, and "crushing"

First off, I'll have to admit that I've lied in the previous section. Some of the lossless image recompression methods are not lossless in the sense of "data in is the same as data out decompressed". Some tools, like optipng, discard unused alpha channels (where images store their transparency), to reduce file size. I said unused, which means that the visible output is still pixel-per-pixel the same, thus lossless, but the image data is obviously different. However, for all intents and purposes, we can call this process "lossless", because no visible information has been changed.

Discarding unused alpha channels is one way of making the image smaller, but there are other ways which are truly lossless. Both pngcrush and optipng tweak the previously mentioned knobs of the compression, trying to find the smallest possible output. The two tools do this a bit differently, but the principle is the same: Tweak the encoding parameters. This is what the Overviewer code refers to as a "crusher". If you wish to learn more on how this is done internally, you can read about it on the optipng site, but beware: It's quite technical.

Lossy Image Optimization

With pngnq, we also offer a way of lossy image optimization. You may be wondering how a PNG can be lossily optimized, as the compression method is lossless. The answer is simple: The amount of colors.

PNG supports a ton of different color modes, amongst them is an indexed color mode, or also referred to as "Palette PNG" or "PNG8". In images with indexed color modes, the colors of each pixel aren't determined individually using red, green and blue channels. Instead, it has a palette of colors, and then specifies for each pixel the color for it by assigning it the a color of the palette. This means less colors, in our case 256 at most, and because we can represent those with just one byte, it means less data that needs to be compressed. If we find the 256 colors that can best represent the image, we get pretty good results that are just a fraction of the original size; and since Minecraft doesn't use a lot of colors in the default texture pack, it's barely noticeable. agrif briefly mentioned this in the "Introducing OIL" blog post. In fact, if our input image has less than or exactly 256 colors anyway, the process is completely lossless!

Instead of waiting for OIL, you can use palette PNGs right now, with the pngnq tool. However, please be aware that due to multiple bugs in the imaging library we currently use, PIL (or Pillow, both are buggy), this will break transparency. As stated in the docs, this is not pngnq's fault.

Using Image Optimization In Practice

But how is this used in practice, you ask? It's not that hard. The first step is to install the tools you wish to use and make sure they can be called by Overviewer (i.e., are in your PATH environment variable). Then, add them to your config.

Please be aware that this will increase render times.

An example for everyone

The following example should be satisfactory for most people who wish to use image optimization. Please also be aware that when I say "most people", I always actually mean "most people". If you think you are not "most people", then you're doing so carrying the risk that you may be wasting your time.

from .optimizeimages import optipng

renders["foo"] = {
    # ... other stuff here
    "optimizeimg":[optipng()],
}

This will run optipng with the default number of trials (which is the way to go for most people).

Playing around with optimization levels

We can, of course, also specify some parameters for optipng. Please note that you're dangerously venturing out of most people-territory here.

from .optimizeimages import optipng

renders["foo"] = {
    # ... other stuff here
    "optimizeimg":[optipng(olevel=3)],
}

This will essentially execute optipng -o3 (instead of -o2), you can see what the exact meaning of that is in the optipng manual, or by typing optipng -h. Please note that anything above, or most likely even including the fifth optimization level, is pointless. The OptiPNG developers said so themselves:

It is important to mention that the achieved compression ratio is less and less likely to improve when higher-level presets (trigerring more trials) are being used. Even if the program is capable of searching automatically over more than 200 configurations (and the advanced users have access to more than 1000 configurations!), a preset that selects around 10 trials should be satisfactory for most users. Furthermore, a preset that selects between 30-40 trials should be satisfactory for all users, for it is very, very unlikely to be beaten significantly by any wider search. The rest of the trial configurations are offered rather as a curiosity (but they were used in the experimentation from which we concluded they are indeed useless!)

Getting crazy

Let's move on to something more hardcore, then. Let's say you don't care if your map looks a bit weird thanks to PIL. Let's say you want to use pngnq.

from .optimizeimages import optipng, pngnq

renders["foo"] = {
    # ... other stuff here
    "optimizeimg":[pngnq(), optipng()],
}

Note the order in which the two optimizers are specified. Here, pngnq is run first, then optipng is run on it. This is important: If you feed crushed output into something that is not a crusher (i.e. does not do lossless compression tweaking), all benefits of the crusher will be lost; essentially, you'd be wasting your time. If you choose to use more than one optimization tool, make sure the crusher is at the end. Overviewer will warn you if it isn't.

Don't be silly

Speaking of more than one optimization tool, let's answer a very important question: Will the image be smaller by using multiple crushers chained together? (i.e. optipng after pngcrush)

The short answer: No.

The long answer: Most likely not.

Crushers, by default, exit if they fail to make the image smaller, and just admit that they have not been able to crush it. Crushers may perform differently in different situations, so using two crushers chained after each other gives you essentially the best output of either; however, for most images (and I say "most images" like I say "most people"), this will be optipng in our example. Every optimizeimg configuration that uses both pngcrush and optipng can most likely be reduced to just optipng, with exactly the same results but much faster renders.

Conclusion

As you may have noticed, I often used "most likely" and "most people" in this post. This is because we can't make certain statements without large-scale tests, which I have not done, but other people did. If you're interested in utilizing image optimization, what you should take away from this blog post is that [optipng()] is the way to go. If you're not sure, do tests yourself. We may add support for better image optimizers in the future, including some for JPEG, so frequently checking the documentation to see which are available is a good idea.