Time Nick Message 11:05 erlehmann sfan5, what is blocking this PR? https://github.com/minetest/minetest/pull/11115 11:10 sfan5 more reviews 11:12 pgimeno strictly speaking, lack of approvals 8) 11:13 erlehmann i see, i can't do anything about it 11:15 erlehmann pgimeno, what would it take for you to approve it 11:17 erlehmann sfan5, does anything have to change about the code or is it strictly a lack-of-time thing? 11:23 pgimeno erlehmann: I'd have to take a look in the first place, but I don't think my approval would be very useful as I'm not a core dev 11:33 sfan5 erlehmann: well I looked at it now because you linked it and I would still have some change requests yes 12:23 erlehmann sfan5 ok cool 13:00 erlehmann btw regarding image file formats (in particular webp), i think now that big savings for small files are almost entirely due to PNG having *a lot* of intrinsic overhead. for a single black pixel, the smallest realistic PNG file is 67 bytes, the smallest TGA file i made using imagemagick was 19 bytes. i wasn't able to produce a valid webp image smaller than 44 bytes, but with that kind of overhead you can waste a 13:00 erlehmann lot of bytes before you even need to figure out compression. so no wonder webp handily beats png – a lot of bytes are just wasted on CRC32 and chunk namings. 13:01 erlehmann i.e. i'd expect any better structured format to beat png by about 50 bytes, always, even if using similar compression techniques 13:15 pgimeno erlehmann: when you talk about files smaller than, say, 0.2K, it really doesn't matter. Even 100,000 files of 0.2K means 20 MB which is reasonable for most networks. 13:19 erlehmann pgimeno yeah, i just wanted to spell it out for ppl who said things about compression efficiency without actually looking at the bytes. 13:19 erlehmann (which were mostly wrong btw) 13:20 pgimeno that's really pointless given that at these sizes it doesn't matter, it's a valid generalization even if it doesn't apply to each and every case, because the cases where it doesn't apply are irrelevant 13:21 pgimeno you're just making a world of an insignificant detail 13:21 pgimeno and that doesn't help development 13:22 erlehmann i think it is useful to point out why ppl (including myself) were wrong here 13:25 pgimeno no it's not, it would be useful if it mattered in the end. I know for sure that PNG overhead is bigger than TGA overhead, by design, and I knew in advance that there would be exceptions to that general rule. 13:25 erlehmann bc if a bunch of formats are about the same for small files, it means a) benchmarking small files is pointless b) removing support for “inefficient“ stuff is pointless, it only breaks stuff c) you would need a bunch of benchmarks to justify webp integration (otherwise you just gain a dependency without any benefit) 13:26 pgimeno no, removing support for stuff for small files is not pointless, it facilitates development by having one less thing to maintain/care about 13:26 erlehmann i.e. the recent “png 150 bytes webp 100 bytes” thing is *not* entirely explainable by better compression 13:27 pgimeno it is, webp also compresses headers, but that's beyond the point anyway, for such small sizes I wouldn't care 13:27 erlehmann ah i meant by better payload compression. if it compresses headers, i see. 13:28 erlehmann “for such small sizes I wouldn't care” → yeah so the question is, at what size would or should anyone care? 13:28 pgimeno above I put the threshold in about 200 bytes 13:29 pgimeno but that's not a rule you need to stick to, it's my own estimation 13:29 pgimeno if you have say 20 million files, something like 50 bytes may matter 13:30 erlehmann yeah so about webp, i think it rather competes with jpeg than with png. 13:30 pgimeno that's right 13:33 erlehmann pgimeno, so, regarding benchmarking webp. google compares webp to the jpeg reference encoder (cjpeg) when promoting it 13:35 erlehmann pgimeno so someone benchmarked webp against mozjpeg and the answer was “not so different after all” https://siipo.la/blog/is-webp-really-better-than-jpeg 13:37 erlehmann TL;DR: “So, is WebP better than JPEG? It depends if you are using the reference libjpeg library or the improved MozJPEG encoder.” 13:37 pgimeno i'm not much for adding another lossy compression algorithm myself if that matters, except maybe jpeg2000 which can also be lossless 13:38 erlehmann what a surprise that google carefully picked data points to promote their own stuff! 13:40 MTDiscord so lossy webp isn't even smaller than a decently encoded jpeg file? 13:40 pgimeno please keep these kind of comments out of #minetest-dev, it's what pollutes this channel 13:42 erlehmann Sublayer plank, mostly yes, but read the article, it's not that easy. 13:47 MTDiscord Now I wonder whether the same holds for PNG. 13:50 pgimeno to clarify, @Sublayer plank that was not directed to you :) 14:07 MTDiscord haha it's alright, I figured it wasn't directed to me since it was sent about a second after what I sent :) 15:03 MTDiscord Webp is really only useful if you’re using high resolution pictures 15:04 MTDiscord But if you’re using low resolution images there’s real no need for such problems 15:09 erlehmann Jordach the linked article says otherwise though, webp is slightly more efficient than mozjpeg for the test pictures up to 500px × 333px, then equal or worse 15:09 erlehmann i.e. not worth the effort 15:09 erlehmann Jordach do you have different experience/benchmarks? 15:12 MTDiscord It’s not worth the effort if you’re using small textures like we already do 15:12 MTDiscord But if you’re using Vanessa’s HD pack 15:14 MTDiscord It then makes a difference 15:15 MTDiscord That and barely any image editors actually save as webp 15:16 MTDiscord "barely" both gimp and paint.net support webp opening and saving out of the box 15:17 MTDiscord Aseprite 15:26 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/904028466301788250/unknown.png 15:26 MTDiscord libresprite/aseprite has webp support if you compile it in 15:26 MTDiscord disabled by default for some reason 15:34 pgimeno webp is really bad for extremely zoomed images with sharp borders like many of the 32x32 images in Minetest; see the comparison in the middle of this page: https://www.ctrl.blog/entry/webp-sharp-yuv.html 15:35 pgimeno even with "sharp YUV" you get blur, which will look bad when zoomed 15:36 sfan5 wasn't the discussion about webp lossless? 15:36 pgimeno is there such thing? 15:36 sfan5 yes 15:36 pgimeno oh, my bad 15:37 sfan5 https://developers.google.com/speed/webp/gallery2 has some stuff 19:19 MTDiscord Yeah webp lossless is 20-30% better than png 19:20 MTDiscord Webp lossy is better than reference jpeg, which is what the world uses 19:20 MTDiscord It's about the same as the newer jpeg formats so there's that. 19:21 MTDiscord And it's best at long areas of the same color, like a sign or wall. Those look far better than jpeg versions of those 19:21 MTDiscord It's not the end all be all by a long shot, but it's an improvement in lossless which is what we mostly use 23:56 MTDiscord I tested this with all of mtg's default textures, vanessaE's 64x64 texture pack, all of homedecor, and all of nodecore. In every case webp was small than TGA and png for all files