The ImageWorker code is written so that the native png encoder is used anyways (the inner test used to skip to the pure java encoding uses "&& nativeAcc" where we already know nativeAcc is false). I noticed this by having a 16 color image be generated by geoserver having the native encoder disabled, and the encoder throwing this exception: "The provided image cannot be encoded using: com.sun.media.imageioimpl.plugins.png.CLibPNGImageWriter" One thing to consider is that GeoServer performance increased a lot in benchmarks when the broken code path was chosen on linux (but not on windows) meaning that there using the native encoder and the default compression is the probably the best option (I've forced a compression level of 0.1 on windows getting smaller images and no visible slowdown, but maybe on linux 0.1 is took much to ask.. an investigation is needed here). Oh, btw, if the pure java version can encode the 4bit pngs, then in that case the native encoder should not be used... this decision can be taken also outside ImageWorker thought, and we'll have to consider what's best, if have 4bit png encoded by the pure java encoder, or else reverting to 256 colors palette for everything but the 1bit pngs and use the native encoder...