webp is simply better in every possible sense
it's an open format, has a great compression, can animate and supports alpha compositing
>why aren't you using it right now?
jannies are trannies
joking. apparently it's another thing to implement, which is always some work
>it's not needed
popular alternatives are:
-jpeg: terrible. light, but way too lossy
-png: good, supports transparency and can be lossless. but it's too heavy and apng will never catch on with animating
-gif: outdated. limited colours scheme and shitty compression
>b-but googah! and the JOOOOOS!
who gives a fuck about who developed it? it's an open format you can use for anything. the new age of internet is here, despite webp being here since 2010
>compatibility
shitty excuse. be the change you want to see, always
/cyb/ - Cyberpunk Fiction and Fact
Cyberpunk is the idea that technology will condemn us to a future of totalitarian nightmares here you can discuss recent events and how technology has been used to facilitate greater control by the elites, or works of fiction
37 replies | 25 files | 23 UUIDs | Page 1
>it's an open format
Open sores poorfaggery: DETECTED
Opinions: DISCARDED
WEBP will be the next memory overflow backdoor exploit to any website.
Open sores poorfaggery: DETECTED
Opinions: DISCARDED
WEBP will be the next memory overflow backdoor exploit to any website.
Anonymous
No.4144
>>4142
>Open sores poorfaggery: DETECTED
actually after writing the OP, i researched that the licences of the mentioned formats expired or are also royally free, so disregard that argument
>WEBP will be the next memory overflow backdoor exploit to any website.
i should have mentioned that before. however unfortunate it was, it never amounted to any significant harm and was quickly patched
if it wasn't, webp wouldn't be used web-wide now. can't have advancements without some temporary drawbacks
>Open sores poorfaggery: DETECTED
actually after writing the OP, i researched that the licences of the mentioned formats expired or are also royally free, so disregard that argument
>WEBP will be the next memory overflow backdoor exploit to any website.
i should have mentioned that before. however unfortunate it was, it never amounted to any significant harm and was quickly patched
if it wasn't, webp wouldn't be used web-wide now. can't have advancements without some temporary drawbacks
>>4147
I think the advantages webp offers are not enough to offset the already established formats. To change just for the sake of zooming and marginal editing doesn't justify the trouble and svg may be the right format for zooming.
I think the advantages webp offers are not enough to offset the already established formats. To change just for the sake of zooming and marginal editing doesn't justify the trouble and svg may be the right format for zooming.
>>4148
SVG is used specifically for vector graphics. It's not possible to easily convert raster graphics into vector, so it cannot be thought of as a replacement for raster formats.
Usecases of WebP and SVG are completely different, and these formats are not mutually exclusive. If high-definition raster imagery is required, then lossless formats, like PNG, work best. In lossy encoding, however, AV1 seems to be more efficient than WebP. AV1 WebMs are already supported here, too.
SVG is used specifically for vector graphics. It's not possible to easily convert raster graphics into vector, so it cannot be thought of as a replacement for raster formats.
Usecases of WebP and SVG are completely different, and these formats are not mutually exclusive. If high-definition raster imagery is required, then lossless formats, like PNG, work best. In lossy encoding, however, AV1 seems to be more efficient than WebP. AV1 WebMs are already supported here, too.
>>4149
indeed, svg would either be too lossy or super bloated. but in future, i hope technical advancements could develop a vector format suitable for high definition images for deep zoom
with ffmpeg set with cpu-used 0 and lossless 1 i converted your image to apple.webp and got 130,1 KB, honestly not that big of a change. granted, it's based on vp8 which isn't magical
so i converted it to .avif and got whooping 20,8 KB! it was still lossless by the way. issue is that it took me 7 seconds compared to webp's instant 0.24 seconds on my mediocre laptop and i'm not sure if avif will ever catch on properly. i then tried lossless png to avif on a 1,1 MB PNG and got 24,1 KB compared to webp's 679,7 KB and cost me 11 seconds
it makes me consider using lossless avif for personal archiving, at least until av1 gets more hardware support and spreads on the net
>AV1 WebMs are already supported here, too.
and i'm happy for it. at least as far as video goes, av1 is being accepted widely
indeed, svg would either be too lossy or super bloated. but in future, i hope technical advancements could develop a vector format suitable for high definition images for deep zoom
with ffmpeg set with cpu-used 0 and lossless 1 i converted your image to apple.webp and got 130,1 KB, honestly not that big of a change. granted, it's based on vp8 which isn't magical
so i converted it to .avif and got whooping 20,8 KB! it was still lossless by the way. issue is that it took me 7 seconds compared to webp's instant 0.24 seconds on my mediocre laptop and i'm not sure if avif will ever catch on properly. i then tried lossless png to avif on a 1,1 MB PNG and got 24,1 KB compared to webp's 679,7 KB and cost me 11 seconds
it makes me consider using lossless avif for personal archiving, at least until av1 gets more hardware support and spreads on the net
>AV1 WebMs are already supported here, too.
and i'm happy for it. at least as far as video goes, av1 is being accepted widely
1765460739_3.webm (97.5 KB, Resolution:455x518 Length:00:00:00, lossless-av1.webm) [play once] [loop]
>>4150
SVG images are actually way more efficient for simple graphics than any raster format and can be scaled infinitely because mathematical shapes are used instead of pixels. SVG data is actually just text instructions, not binary, so `file` returns something like this with an SVG file:
>terri.svg: SVG Scalable Vector Graphics image, ASCII text, with very long lines (9226)
Naturally, this means SVG files are incredibly compact. terri.svg here is only 68KiB, but it can be converted into a PNG file of whatever size because it's scalable. Given that SVG data is plain text, files using it are also very compressible: using `xz -9e`, terri.svg could be compressed from 68KiB down to 20KiB. While SVG files cannot be lossy, because there's little they can lose to meaningfully decrease size, usually a lot of information is lost when, say, a PNG file is converted into SVG, so that's the closest thing to it.
>i converted it to .avif and got whooping 20,8 KB! it was still lossless by the way
Are you sure it was lossless? At most, using apple.png, I managed to get a 98KiB image with lossless AV1 and, by specifying `-crf 0 -preset 0`, 11 KiB with lossy. The thing about FFmpeg is that it ignores libaom options (eg., `-lossless`) if you are using the SVT-AV1 encoder; you have to specify them like `-svtav1-params lossless=1`. I haven't compared these encoders directly, but while SVT-AV1 is much faster than libaom, maybe libaom is more efficient in terms of size and quality.
`time` reports around 2s with lossy and 0.7s lossless when encoding with AV1. VP9 seems to be around 0.3s for lossless and 0.2s lossy. AV1 doesn't support RGB and converts it to YUV, so colours are a little off, even with lossless. VP9 seems to benefit a lot from using YUV over RGB, but it can use both. With lossy VP9 (`-crf 0`), images with yuv420p and gbrp pixel formats were 100KiB and 225KiB, respectively.
>as far as video goes, av1 is being accepted widely
You can also simply use one-frame AV1 WebM files in lieu of AVIF images. Same with VP9.
SVG images are actually way more efficient for simple graphics than any raster format and can be scaled infinitely because mathematical shapes are used instead of pixels. SVG data is actually just text instructions, not binary, so `file` returns something like this with an SVG file:
>terri.svg: SVG Scalable Vector Graphics image, ASCII text, with very long lines (9226)
Naturally, this means SVG files are incredibly compact. terri.svg here is only 68KiB, but it can be converted into a PNG file of whatever size because it's scalable. Given that SVG data is plain text, files using it are also very compressible: using `xz -9e`, terri.svg could be compressed from 68KiB down to 20KiB. While SVG files cannot be lossy, because there's little they can lose to meaningfully decrease size, usually a lot of information is lost when, say, a PNG file is converted into SVG, so that's the closest thing to it.
>i converted it to .avif and got whooping 20,8 KB! it was still lossless by the way
Are you sure it was lossless? At most, using apple.png, I managed to get a 98KiB image with lossless AV1 and, by specifying `-crf 0 -preset 0`, 11 KiB with lossy. The thing about FFmpeg is that it ignores libaom options (eg., `-lossless`) if you are using the SVT-AV1 encoder; you have to specify them like `-svtav1-params lossless=1`. I haven't compared these encoders directly, but while SVT-AV1 is much faster than libaom, maybe libaom is more efficient in terms of size and quality.
`time` reports around 2s with lossy and 0.7s lossless when encoding with AV1. VP9 seems to be around 0.3s for lossless and 0.2s lossy. AV1 doesn't support RGB and converts it to YUV, so colours are a little off, even with lossless. VP9 seems to benefit a lot from using YUV over RGB, but it can use both. With lossy VP9 (`-crf 0`), images with yuv420p and gbrp pixel formats were 100KiB and 225KiB, respectively.
>as far as video goes, av1 is being accepted widely
You can also simply use one-frame AV1 WebM files in lieu of AVIF images. Same with VP9.
Anonymous
No.4152
One peculiar thing is that XZ-compressed bitmaps are sometimes more efficient than PNG and lossless-AVIF files. BMP files do not use compression, and while this means that they are usually larger (eg., autumn.bmp was 90MiB before compression), it also means that they can be compressed manually, which, as it could be seen, can be beneficial. BMP files are lossless, too, obviously.
>>4151
>Are you sure it was lossless?
i believe so. it might have been only visually lossless, but nothing i tried finding out confirmed it. instead of crf 0 i used lossless 1 which i'm honestly not sure what does on technical level
>SVT-AV1 is much faster than libaom, maybe libaom is more efficient in terms of size and quality
i'm using libaom for these experiments but yeah, i'd use svt-av1 for some practical use
>You can also simply use one-frame AV1 WebM files in lieu of AVIF images
this is a great idea, actually, thanks for showing me
here i used the following command
ffmpeg -loop 1 -i apple.png -lossless 1 -t 1 -c:v libaom-av1 -cpu-used 0 -r 1 apple.webm
and still got a super small file with (i hope) no lossy compression, but still not sure what's the difference between yours "-crf 0 -preset 0" and my "-lossless 1"
>Are you sure it was lossless?
i believe so. it might have been only visually lossless, but nothing i tried finding out confirmed it. instead of crf 0 i used lossless 1 which i'm honestly not sure what does on technical level
>SVT-AV1 is much faster than libaom, maybe libaom is more efficient in terms of size and quality
i'm using libaom for these experiments but yeah, i'd use svt-av1 for some practical use
>You can also simply use one-frame AV1 WebM files in lieu of AVIF images
this is a great idea, actually, thanks for showing me
here i used the following command
ffmpeg -loop 1 -i apple.png -lossless 1 -t 1 -c:v libaom-av1 -cpu-used 0 -r 1 apple.webm
and still got a super small file with (i hope) no lossy compression, but still not sure what's the difference between yours "-crf 0 -preset 0" and my "-lossless 1"
>>4153
i found out i was wrong. no clue why is it named this way and why does no documentation mention it, but "lossless" is actually rather lossy so i must disregard my previous av1 tests
i found out i was wrong. no clue why is it named this way and why does no documentation mention it, but "lossless" is actually rather lossy so i must disregard my previous av1 tests
>>4153
>>4154
>not sure what's the difference between yours "-crf 0 -preset 0" and my "-lossless 1"
`-crf` and `-preset` are best used for lossy encoding--they don't seem to do much with lossless, but the latter seems to affect the file size a bit. Per `man ffmpeg-all`:
>crf
>crf Constant rate factor value used in crf rate control mode (0-63).
>preset
>Set the quality-speed tradeoff, in the range 0 to 13. Higher values are faster but lower quality.
In practice, CRF is just a quality scale from 0 to 63, where 63 produces the worst quality and the smallest size. `-preset` is something similar, I guess. To get lossless encoding with SVT-AV1, I used `ffmpeg -i apple.png -c:v av1 -svtav1-params lossless=1 lossless-av1.webm`.
>"lossless" is actually rather lossy
That's weird. Lossless I used was pretty lossless. Try using `-aom-params lossless=1`, which is unambiguous, unlike `-lossless`, which some other codecs use, and maybe that's an issue. It should also display warnings if something is amiss.
>>4154
>not sure what's the difference between yours "-crf 0 -preset 0" and my "-lossless 1"
`-crf` and `-preset` are best used for lossy encoding--they don't seem to do much with lossless, but the latter seems to affect the file size a bit. Per `man ffmpeg-all`:
>crf
>crf Constant rate factor value used in crf rate control mode (0-63).
>preset
>Set the quality-speed tradeoff, in the range 0 to 13. Higher values are faster but lower quality.
In practice, CRF is just a quality scale from 0 to 63, where 63 produces the worst quality and the smallest size. `-preset` is something similar, I guess. To get lossless encoding with SVT-AV1, I used `ffmpeg -i apple.png -c:v av1 -svtav1-params lossless=1 lossless-av1.webm`.
>"lossless" is actually rather lossy
That's weird. Lossless I used was pretty lossless. Try using `-aom-params lossless=1`, which is unambiguous, unlike `-lossless`, which some other codecs use, and maybe that's an issue. It should also display warnings if something is amiss.
>>4155
thank you for the insight, i have only little experience with ffmpeg and am learning it on the go
>-aom-params lossless=1
that did the trick, i assume without this the "lossless=1" got ignored and resulted in a very lossy compression without printing any errors
but i also experimented with other codecs. first with svt-av1 the colours were always off as it was using YUV while libaom used BRGB, and later found it this is just part of this encoder
from its upsides and downsides, i'm led to believe it's good only for transmitting production videos with low bandwith
but i also discovered a new avif encoder
https://github.com/kornelski/cavif-rs
using it on your image, i got a big size drop, only 117 KB
https://u.pone.rs/yjyunrtw.avif
it might be only visually lossless, but i'm pretty sure that's what av1 excels at now. i tried setting quality to 100 with speed 1 but the result was 2,2 MB, and both results have RGB set
thank you for the insight, i have only little experience with ffmpeg and am learning it on the go
>-aom-params lossless=1
that did the trick, i assume without this the "lossless=1" got ignored and resulted in a very lossy compression without printing any errors
but i also experimented with other codecs. first with svt-av1 the colours were always off as it was using YUV while libaom used BRGB, and later found it this is just part of this encoder
from its upsides and downsides, i'm led to believe it's good only for transmitting production videos with low bandwith
but i also discovered a new avif encoder
https://github.com/kornelski/cavif-rs
using it on your image, i got a big size drop, only 117 KB
https://u.pone.rs/yjyunrtw.avif
it might be only visually lossless, but i'm pretty sure that's what av1 excels at now. i tried setting quality to 100 with speed 1 but the result was 2,2 MB, and both results have RGB set
Anonymous
No.4157
1765556089.webm (584.7 KB, Resolution:3000x2500 Length:00:00:00, svtav1-preset_0.webm) [play once] [loop]
>>4156
If I understand correctly, cavif is a standalone programme, separate from FFmpeg. The Github page reads:
>Encoder/converter for AVIF images. Based on rav1e and avif-serialize via the ravif crate, which makes it an almost pure-Rust tool (it uses C LCMS2 for color profiles).
>Based on rav1e
FFmpeg actually has support for rav1e, too.
The image itself lost some colours, which is particularly noticeable in the eyes, but it doesn't have any obvious artefacts, and it is almost 15 times smaller. Compare that to SVT-AV1 lossless, which doesn't lose colour information as much, merely converts it to YUV, but is only about 2 times smaller.
Also, it appears that using
>1.7M orig.png
>778K svtav1.webm
>585K svtav1-preset_0.webm
>114K yjyunrtw.avif
If I understand correctly, cavif is a standalone programme, separate from FFmpeg. The Github page reads:
>Encoder/converter for AVIF images. Based on rav1e and avif-serialize via the ravif crate, which makes it an almost pure-Rust tool (it uses C LCMS2 for color profiles).
>Based on rav1e
FFmpeg actually has support for rav1e, too.
-c:v librav1e -rav1e-params The image itself lost some colours, which is particularly noticeable in the eyes, but it doesn't have any obvious artefacts, and it is almost 15 times smaller. Compare that to SVT-AV1 lossless, which doesn't lose colour information as much, merely converts it to YUV, but is only about 2 times smaller.
Also, it appears that using
-preset 0 with lossless shaved 193KiB with no quality loss, so that makes the SVT-AV1 image almost 3 times smaller than the original.>1.7M orig.png
>778K svtav1.webm
>585K svtav1-preset_0.webm
>114K yjyunrtw.avif
Anonymous
No.4158
apng was accepted into the mainstream spec now. nigp support can be fully dropped now. yay.
Anonymous
No.4160
How do we feel about jpegxl? It's relatively new and had problems with adoption until recently (basically just the chrome devs not liking it), but I feel like it solves most of the problems people have with every other format by just being straight up better than its competition in basically all aspects.
In theory, since binary data is not mangled in uploads here, APNG should work if one's browser supports it.
https://ponerpics.org/images/7311378
https://ponerpics.org/images/7311378
Anonymous
No.4162
>>4141
Webpee is cancer. It is from Jewgle. It is yet another file format nobody asked for and nobody wanted. It breaks every imageboard software I know of. Jpeg gives equal or better compression if you don't mind it being a bit lossy. Png is lossless and compatible with everything. Webpee, like avif, brings absolutely nothing to the table and offers no compelling justification for the constant pain in the ass it brings to me by existing.
Webpee is cancer. It is from Jewgle. It is yet another file format nobody asked for and nobody wanted. It breaks every imageboard software I know of. Jpeg gives equal or better compression if you don't mind it being a bit lossy. Png is lossless and compatible with everything. Webpee, like avif, brings absolutely nothing to the table and offers no compelling justification for the constant pain in the ass it brings to me by existing.
Hey Thistle, slim chance you might appear in this thread again, but what happened on the irc, may I ask?
>>4176
One janny got particularly upset over picrel, likened it to lolicon, lied about talking to an admin, and basically made a lot of fuss out of nothing. I talked to him, but he's just an insufferable faggot, and he also started spamming when I suggested I speak to the admin directly.
Context for the bystanders: this is offsite drama; move along.
One janny got particularly upset over picrel, likened it to lolicon, lied about talking to an admin, and basically made a lot of fuss out of nothing. I talked to him, but he's just an insufferable faggot, and he also started spamming when I suggested I speak to the admin directly.
Context for the bystanders: this is offsite drama; move along.
Anonymous
No.4179
>>4177
damn
yeah, the jannies, especially that specific person you were dealing with, have a tendency to misunderstand such things. i'm afraid that ban isn't fixable
shame. was fun having you around
damn
yeah, the jannies, especially that specific person you were dealing with, have a tendency to misunderstand such things. i'm afraid that ban isn't fixable
shame. was fun having you around
>>4180
Sucks to suck and all. Even if they were to, I wouldn't, because soicacas are stultifyingly prudish, so much so that they lose their minds over incredibly minute things. It's much comfier here all the same. I just want to post ponies, for goodness sake.
Sucks to suck and all. Even if they were to, I wouldn't, because soicacas are stultifyingly prudish, so much so that they lose their minds over incredibly minute things. It's much comfier here all the same. I just want to post ponies, for goodness sake.
>>4181
I'm not sure exactly what's going on with that irc drama of yours but your posts make me want to have steamy vaginal sex with an actual foal. How weird.
I'm not sure exactly what's going on with that irc drama of yours but your posts make me want to have steamy vaginal sex with an actual foal. How weird.
1768259305.png (1.0 MB, 2076x2084, 92164e6c.twilight_sparkle-applejack-cosy_glow-anon.png)
>>4182
You'd get b& for promotion of hecking pedophilia and zoophilia and half of the chat would have a meltdown if you were to say you want to kiss a foal on the cheek. That's the kind of place donkey show's IRC is.
You'd get b& for promotion of hecking pedophilia and zoophilia and half of the chat would have a meltdown if you were to say you want to kiss a foal on the cheek. That's the kind of place donkey show's IRC is.
>>4183
Glad I don't even know what donkey show is. I tuned out of the internets for like a couple months and then suddenly there's a new donkey show or something, I assume that's what it is. Not even gonna check any of it out though, I'd rather stare at a wall at this point than check any more glowops, no curiosity left. Fuck I barely interact with the Internet at all anymore, mlpol is pretty much all of it now.
>>4184
Huh?
Glad I don't even know what donkey show is. I tuned out of the internets for like a couple months and then suddenly there's a new donkey show or something, I assume that's what it is. Not even gonna check any of it out though, I'd rather stare at a wall at this point than check any more glowops, no curiosity left. Fuck I barely interact with the Internet at all anymore, mlpol is pretty much all of it now.
>>4184
Huh?
Anonymous
No.4187
1768260073.png (3.6 MB, 2700x3000, 0cf57cd7.twilight_sparkle-anonfilly-oc.png)
oh yeah, i could also mention i changed my mind about webp. it is indeed buggy and though it could be adopted, it's not worth the effort with the alternatives at our disposal
i am now a jpeg-xl shill and hope chromium and gecko will add support this year
i am now a jpeg-xl shill and hope chromium and gecko will add support this year
>>4188
Why the fuck not just go full .png? Yes it's not exactly efficient size-wise, but there is no quality loss ever. Am I missing something?
Why the fuck not just go full .png? Yes it's not exactly efficient size-wise, but there is no quality loss ever. Am I missing something?
>>4188
PNG and JPEG are the best image formats evar. You didn't need more then; you don't need more now. JXL, WebP, AVIF, &c., have no usecase outside of, I don't know, websites with a particularly large amount of user-generated content--that's where every bit counts. Otherwise, it is, honestly, pointless.
PNG and JPEG are the best image formats evar. You didn't need more then; you don't need more now. JXL, WebP, AVIF, &c., have no usecase outside of, I don't know, websites with a particularly large amount of user-generated content--that's where every bit counts. Otherwise, it is, honestly, pointless.
>>4189
>>4190
>Am I missing something?
practically speaking, no.
you did point out the size. looking at reading.png i posted before, i (i hope) losslessly compressed it to 175,3 KB from 5,3 MB
https://u.pone.rs/bvvpemgj.jxl
that's a pretty thick difference
that's not the end of it though. png supports up to 32 bits of colour depth compared to png's 16 bits. that probably doesn't really matter that much though, it's mainly the size
>websites with a particularly large amount of user-generated content
websites like boorus or social media like instagram? or better yet, archival sites. it does have its usage. i know i can always buy more disks, but you can use them for archival or the archive instead
i also just like seeing one file being smaller while being the same
>>4190
>Am I missing something?
practically speaking, no.
you did point out the size. looking at reading.png i posted before, i (i hope) losslessly compressed it to 175,3 KB from 5,3 MB
https://u.pone.rs/bvvpemgj.jxl
that's a pretty thick difference
that's not the end of it though. png supports up to 32 bits of colour depth compared to png's 16 bits. that probably doesn't really matter that much though, it's mainly the size
>websites with a particularly large amount of user-generated content
websites like boorus or social media like instagram? or better yet, archival sites. it does have its usage. i know i can always buy more disks, but you can use them for archival or the archive instead
i also just like seeing one file being smaller while being the same
Anonymous
No.4192
>>4191
Alright, I guess I can't deny the size advantage. One inevitable issue with these advanced formats, however, is their relative complexity. In practical terms, if it works, then it works, but if it doesn't, then it might be harder to fix. Furthermore, the more complex a format is, in theory, the harder it should be to implement support for it. It might also prove to be buggy, insecure, and bloated. One grand advantage PNG has is that it is a universal format; it is accepted wherever images are, and you just can't say the same about JXL or AVIF.
Currently, it only makes sense to convert your images to, for example, JXL if compatibility is not an issue, especially web compatibility. Otherwise, it's just a toy format which gives autistics like us a minor satisfaction from saving that a many bytes of disk space.
Alright, I guess I can't deny the size advantage. One inevitable issue with these advanced formats, however, is their relative complexity. In practical terms, if it works, then it works, but if it doesn't, then it might be harder to fix. Furthermore, the more complex a format is, in theory, the harder it should be to implement support for it. It might also prove to be buggy, insecure, and bloated. One grand advantage PNG has is that it is a universal format; it is accepted wherever images are, and you just can't say the same about JXL or AVIF.
Currently, it only makes sense to convert your images to, for example, JXL if compatibility is not an issue, especially web compatibility. Otherwise, it's just a toy format which gives autistics like us a minor satisfaction from saving that a many bytes of disk space.