Hi! I’ve actually not personally played RimWorld yet, but saw this community and felt obliged to share some suggestions for people to consider.

I usually post from @MHLoppy@fedia.io and I share (and recompress) a lot of digital art. In doing so (and partly out of general personal interest) I’ve played around a bit with encoders and codecs trying to find good quality vs file size tradeoffs.

My three suggestions to consider, which are certainly not “do this because it’s always 100% better” - just suggestions (!), are aimed at those who already save to PNG in Progress Renderer and then recompress afterwards in an image editor.

1: MozJPEG encoder

This will offer small file size improvements at the same quality for JPEG images compared to the more commonly-used JPEG encoders. For example, Paint.NET has a free plugin that offers this capability within a friendly-enough interface.

This should let you get either slightly smaller or slightly higher quality images based on your preference if you were already using the PNG -> JPEG workflow. The difference will not be earth-shattering, but may be worthwhile.

Note that the MozJPEG encoder will be a bit slower (that’s the tradeoff it chooses for slightly better compression). For “normal” sized images like 1500x1500 it’s still basically instant on my machine, but RWP uses crazy resolutions so it may be noticeable at e.g. 5000x5000.

2: WebP

WebP is supported in almost all browsers these days and in my experience with recompressing digital artwork, it seems to “overperform” for digital art, which may translate to the types of graphics RimWorld uses (not photorealistic).

WebP encoding will unfortunately also be slower than normal JPEG encoding, and also has chroma subsampling (from 4:4:4 to 4:2:0) forced as part of the format’s specification. However, because human visual perception is more sensitive to luma (bright/dark) than chroma (color), this isn’t a deal breaker. At the end of the day the important thing is file size vs how good the image looks, and WebP might work well for you there.

In my tests with digital artwork (and with my personal visual perception), when encoding at fairly high quality settings (JPEG quality 85~88), WebP never performed worse than JPEG by that metric. Note that the quality numbers for WebP are not directly comparable to the numbers with JPEG, so a “quality 85” in JPEG is not the same as “quality 85” in WebP. Usually you need a slightly higher (single-digit higher) number in WebP’s quality setting to match JPEG’s quality setting.

3: VERY light denoising

This is more of a bonus suggestion, but something I think is still worth considering.

Image encoding can spend a lot of extra resources trying to encode fine details that are similar to image noise. By reducing (not removing!) some of this effect with a denoiser, you might be able to improve the overall quality vs file size. Be careful with overdoing this, as overly aggressive denoising settings will remove detail from the image that you may actually care about keeping. A feather-touch approach should ideally improve file size by reducing tiny detail that you basically can’t even see in the image whilst preserving the stuff that you can.

I tested some very light-touch denoising on a couple of already-encoded RWP images and saw file size reduction of 15~20% and the difference was almost impossible to see at both 100% and 200% zoom even when flicking between the images on different layers (which makes changes much easier to see than a side-by-side). Of course this is not a purely free lunch - at 600% zoom I could see small changes made in some textures, but given the file size improvements for normal zoom levels this may be worth using.

To be clear, denoising should be done BEFORE lossy compression (such as JPEG and WebP) is performed, which in this case means doing it on the PNG you’ve saved from PR.