| Time |
Nick |
Message |
| 04:00 |
|
MTDiscord joined #minetest-docs |
| 04:07 |
|
erle joined #minetest-docs |
| 04:37 |
|
BuckarooBanzai joined #minetest-docs |
| 06:20 |
|
erle joined #minetest-docs |
| 11:12 |
|
appguru joined #minetest-docs |
| 12:51 |
|
erle joined #minetest-docs |
| 17:33 |
MTDiscord |
<Jonathon> dunno https://forum.minetest.net/viewtopic.php?p=411925#p411925 is something we would ever want to have in the docs? |
| 19:28 |
erle |
Jonathon yes, but the post is wrong on bitmap optimization, lol |
| 19:29 |
erle |
it was probably written by someone who never even tests their own stuff |
| 19:38 |
erle |
Jonathon: here are two good rules of thumb for optimizing lossless images: for images with about 70 pixels or below (e.g. 8×8) → TGA is always the smallest. from that point up to about 256 pixels (e.g. 16×16) you are guaranteed to have lossless compression with colormapping regardless of format. |
| 19:38 |
erle |
also the post mentions optipng and pngcrush without going into detail and does not even mention zopfli |
| 19:38 |
MTDiscord |
<Jonathon> ya know what, im just not going to comment further than to say, believe what you want to believe, no matter how different from reality it is |
| 19:39 |
erle |
? |
| 19:39 |
erle |
the thing with 256 pixels is pretty obvious, the palette can have up to 267 one-byte entries |
| 19:39 |
erle |
up to 256 i mean |
| 19:40 |
erle |
the other thing is obvious if you figure out how much overhead you need to encode the first pixel in a PNG image, which is about 69 bytes of boilerplate |
| 19:41 |
erle |
optimizing PNG images can take very long |
| 19:41 |
erle |
so i am pretty sure i know what i am doing |
| 19:41 |
erle |
anyways, i just wanted to point out that the post is missing two very obvious optimization techniques |
| 19:42 |
erle |
(i.e. counting bytes and calculating minimum overhead) |
| 21:13 |
MTDiscord |
<luatic> erle: I don't think this kind of byte-shaving is really worth it; games are unlikely to have loads of textures with < 70 px, standard is 16x16+ |
| 21:14 |
MTDiscord |
<luatic> anyways, add what you feel is missing in the thread (e.g. zopfli) |
| 21:16 |
erle |
i think, if people want to shave off bytes, they should not cargo-cult it, but understand the matter |
| 21:17 |
erle |
luatic has the PNG encoding situation become better? i.e. is the checkerboard still 20 times the size that optipng outputs? |
| 21:17 |
erle |
(i can also check, but i thought maybe you know) |
| 21:18 |
erle |
i personally think the 4k bytes boundary is relevant for disk space, so i think in 4k blocks |
| 21:18 |
erle |
for example, some of the textures of minetest game could be a few bytes smaller if saved differently. did i make a patch? hell no lol |
| 21:19 |
erle |
luatic btw one of the funniest things btw regarding image optization is bloated metadata. someone once left in metadata in textures for mcl2 and those became HUGE |
| 21:19 |
MTDiscord |
<luatic> erle: no, nobody touched the encoder |
| 21:19 |
erle |
i think it was an entire XML metadata element in a text chunk or so |
| 21:20 |
MTDiscord |
<luatic> if I was to write a checkerboard texture I'd use a palette |
| 21:20 |
erle |
same |
| 21:20 |
erle |
however, minetest.encode_png() gets confused by it |
| 21:20 |
erle |
i assume that no filtering is happening |
| 21:21 |
MTDiscord |
<luatic> encode_png is kept as simple as possible |
| 21:21 |
MTDiscord |
<luatic> it's literally dumping ARGB8 scanlines and then compressing the entire thing using zlib |
| 21:21 |
erle |
oh LOL |
| 21:21 |
MTDiscord |
<rubenwardy> texture format discussions are so incredibly boring |
| 21:21 |
MTDiscord |
<rubenwardy> mutes channel for a day |
| 21:21 |
erle |
well, i am pretty sure if minetest.encode_png() can produce textures that are 5% of the size it makes now it is kinda useful |
| 21:21 |
MTDiscord |
<luatic> @rubenwardy don't worry, I'm working on an exciting debug mod |
| 21:22 |
erle |
(without loss of quality) |
| 21:22 |
MTDiscord |
<luatic> it's pretty much finished actually |
| 21:22 |
erle |
code is unexciting lol |
| 21:22 |
erle |
if it gets exciting, things go wrong |
| 21:22 |
erle |
i prefer boring stuff |
| 21:22 |
MTDiscord |
<luatic> erle: the hacks I've implemented here are magnificient |
| 21:22 |
erle |
luatic tell? |
| 21:22 |
MTDiscord |
<luatic> I've found a way to get function arguments from within Lua |
| 21:22 |
MTDiscord |
<luatic> using only the debug library |
| 21:23 |
erle |
the problem with “dump scanlines into zlib” is “no prefiltering” am i right? |
| 21:23 |
MTDiscord |
<luatic> erle: problem 1 is ARGB8, problem 2 is no filtering |
| 21:23 |
MTDiscord |
<luatic> solving 1) is doable, solving 2) is harder |
| 21:24 |
erle |
i am pretty sure that “no prefiltering” means this is about as good as RLEd TGA (i.e. okay for small textures, abysmal for large ones) |
| 21:25 |
MTDiscord |
<luatic> except we still have zlib to save us ;) |
| 21:25 |
erle |
like prefiltering is the best part of PNG |
| 21:27 |
erle |
the thing i am pointing out is that zlib does not save you |
| 21:30 |
erle |
luatic without prefiltering i can get a smaller filesize by pushing the raw pixels into zlib (which is basically what i am doing in xmaps to get a very small item meta) |
| 21:30 |
erle |
okay, i am putting a paletted TGA in it |
| 21:30 |
erle |
but same |
| 21:31 |
erle |
anyways, luatic i bet you have thought about it. why is prefiltering difficult? |
| 21:41 |
MTDiscord |
<luatic> there are multiple filters you can use, some more complex than others and you have to decide which to choose for every scanline, and which filter you choose for one scanline affects your options for neighboring scanlines |
| 21:41 |
MTDiscord |
<luatic> TBF the PNG spec mentions some heuristics... |
