| Time |
Nick |
Message |
| 00:00 |
|
Sokomine_ joined #minetest-dev |
| 00:00 |
|
jonadab joined #minetest-dev |
| 00:02 |
|
rubenwardy joined #minetest-dev |
| 00:02 |
|
beanzilla joined #minetest-dev |
| 00:29 |
|
v-rob joined #minetest-dev |
| 00:42 |
|
v-rob joined #minetest-dev |
| 00:56 |
|
Kimapr[i] joined #minetest-dev |
| 01:25 |
|
proller joined #minetest-dev |
| 02:29 |
|
queria^clone joined #minetest-dev |
| 02:33 |
|
queria^clone joined #minetest-dev |
| 02:37 |
|
proller joined #minetest-dev |
| 03:14 |
|
proller joined #minetest-dev |
| 03:23 |
|
olliy joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:02 |
|
specing_ joined #minetest-dev |
| 04:14 |
|
hendursaga joined #minetest-dev |
| 04:23 |
|
tekakutli joined #minetest-dev |
| 07:58 |
|
m42uko_ joined #minetest-dev |
| 08:05 |
|
hendursa1 joined #minetest-dev |
| 08:47 |
|
Kimapr[i] joined #minetest-dev |
| 09:04 |
|
hendursa1 joined #minetest-dev |
| 10:12 |
|
Fixer joined #minetest-dev |
| 10:30 |
|
tech_exorcist joined #minetest-dev |
| 11:05 |
erlehmann |
sfan5, what is blocking this PR? https://github.com/minetest/minetest/pull/11115 |
| 11:06 |
|
calcul0n_ joined #minetest-dev |
| 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:00 |
|
calcul0n__ joined #minetest-dev |
| 12:15 |
|
proller joined #minetest-dev |
| 12:23 |
erlehmann |
sfan5 ok cool |
| 12:47 |
|
tekakutli joined #minetest-dev |
| 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:04 |
|
erle joined #minetest-dev |
| 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 |
<Sublayer plank> 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:43 |
|
tech_exorcist joined #minetest-dev |
| 13:47 |
MTDiscord |
<luatic> 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 |
<Sublayer plank> 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 |
<Jordach> Webp is really only useful if you’re using high resolution pictures |
| 15:04 |
MTDiscord |
<Jordach> 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 |
<Jordach> It’s not worth the effort if you’re using small textures like we already do |
| 15:12 |
MTDiscord |
<Jordach> But if you’re using Vanessa’s HD pack |
| 15:14 |
MTDiscord |
<Jordach> It then makes a difference |
| 15:15 |
MTDiscord |
<Jordach> That and barely any image editors actually save as webp |
| 15:16 |
MTDiscord |
<Sublayer plank> "barely" both gimp and paint.net support webp opening and saving out of the box |
| 15:17 |
MTDiscord |
<Jordach> Aseprite |
| 15:23 |
|
fluxionary joined #minetest-dev |
| 15:26 |
MTDiscord |
<Sublayer plank> https://cdn.discordapp.com/attachments/747163566800633906/904028466301788250/unknown.png |
| 15:26 |
MTDiscord |
<Sublayer plank> libresprite/aseprite has webp support if you compile it in |
| 15:26 |
MTDiscord |
<Sublayer plank> 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 |
| 15:52 |
|
Extex joined #minetest-dev |
| 16:02 |
|
specing_ joined #minetest-dev |
| 17:15 |
|
Taoki joined #minetest-dev |
| 18:02 |
|
hendursaga joined #minetest-dev |
| 19:19 |
MTDiscord |
<exe_virus> Yeah webp lossless is 20-30% better than png |
| 19:20 |
MTDiscord |
<exe_virus> Webp lossy is better than reference jpeg, which is what the world uses |
| 19:20 |
MTDiscord |
<exe_virus> It's about the same as the newer jpeg formats so there's that. |
| 19:21 |
MTDiscord |
<exe_virus> 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 |
<exe_virus> 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 |
| 19:38 |
|
Extex joined #minetest-dev |
| 20:26 |
|
proller joined #minetest-dev |
| 20:26 |
|
appguru joined #minetest-dev |
| 21:15 |
|
v-rob joined #minetest-dev |
| 21:47 |
|
longerstaff13 joined #minetest-dev |
| 21:57 |
|
proller joined #minetest-dev |
| 22:07 |
|
Extex joined #minetest-dev |
| 22:29 |
|
proller joined #minetest-dev |
| 23:00 |
|
v-rob joined #minetest-dev |
| 23:04 |
|
Alias2 joined #minetest-dev |
| 23:18 |
|
v-rob joined #minetest-dev |
| 23:56 |
MTDiscord |
<exe_virus> 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 |
