webp is the stupidest fucking botnet filetype
every time I want to link an image or shitpost, firefox always saves it as a fucking webp
file extension says it's .jpg or .png? SIKE, ITS FUCKING WEBP
fuck jewgle and their infectious bullshit
how do I escape this shit?
Other urls found in this thread:
files.catbox.moe
files.catbox.moe
files.catbox.moe
files.catbox.moe
files.catbox.moe
github.com
files.catbox.moe
files.catbox.moe
files.catbox.moe
files.catbox.moe
files.catbox.moe
files.catbox.moe
files.catbox.moe
twitter.com
Have you tried not being mentally retarded. Kill yourself.
wow great contribution faglord
why don't you elucidate me to secrets of avoiding this fucking retarded image format since you're so fucking big brained? or are you just fishing for (You)'s? maybe you should kill yourself, since you're clearly squandering your absolute genius by writing one-note replies on a hungarian bread basting forum, you fucking cretin
stop using firefox
I was scraping a bunch of website the other day to get all the images. For most websites I could just save the jpeg, but one stupid website returned everything is this retarded format. I changed the headers I sent to the website to exclude webp and it still sent webp. So I had to convert it on the fly to jpeg like the others.
We don't need any other fucking formats. Google shit me. They only do this to benefit themselves (to save k/b that they don't have to pay for) at the expensive of having a standard fucking format that people can rely on. Fuck google.
the real question is, why hasnt gookmoot enabled webp on here yet? it would be great
You are part of the problem too.
mogrify -format jpg *.webm
>posts 55.922 Bytes PNG (already losslessly optimized) to shit on WebP
>even very time consuming brute force optimization (still lossless) only brings it down to 55.760 Bytes
>same image compressed as lossless WebP is 36.028 Bytes
files.catbox.moe
itoddler detected
for f in ~/Downloads/*.webp
do
mogrify -format jpg "$f"
rm "$f"
done
throw in cron
I think the format is a pile of shit specifically because it's one more format to the bucket of "shit I don't want to deal with but have to"
It's like .apng. yes it's a thing, but no I don't want to deal with it.
generations of what? how were they degraded?
lol its not to save k/b, it actually costs them more money to keep up support for an extra file format. its so you have to go to the website itself and give them traffic and ad revenue. which is, you know, mostly run by google. it's a pretty obvious usage of their top down monopoly to manipulate people's behavior in one area of business so it benefits another area of business
Add -- to both commands before the variable
I was torrenting some weeb shit, and the faggot rippers included scans in webp format. On Debian GNU/Linux, I apparently cannot open webp with any imlib2 based image viewer, and opening them with mpv or ffmpeg is slow as fuck. Fuck technological progress 2bh.
Filetypes are botnet
Get imlib2-webp. If Debian doesn't package it, shout at the repo maintainers and build it yourself.
In a nutshell it's not about you but the website being hosted. Webp is now over 2X more efficient in compressing lossy and lossless images than JPG, PNG, GIF combined and even outperforms modern day PNG lossy compression algos which use 10X or more resources. Websites can't afford to host deprecated image formats like those mentioned anymore because it requires the use of more bandwidth which costs money. Webp:
1.) Saves money for hosting a website (less than half the typical bandwidth is now required)
2.) Loads faster for users.
3.) You don't have to have multiple formats for different image types, now one does the work of 3 (though webm is better replacement for gifs).
>look, ma', I replied to everyone!
Otherwise true; if a PNG is served as a lossy WebP, change/remove your User-Agent header.
You're complaining about botnet on a website "protected" by ReCaptcha, go fuck yourself, be fucking logic.
whenever i use webp on my site it seems like its more mb though? shit just loads slower. starting to think webp is just some meme pushed by google.
Consider a standard lossless PNG. This one is 1.54 MB
I don't care to argue about lossless WebP because it's trivially converted to other format. Lossy WebP, especially when generated from PNG source and made loseless to save bandwidth, is the issue.
WAIT FOR IT you mongrel.
And now here is the webp version of it only 945 KB in size. Which one do you think a web host interested in keeping costs down and profit up will use?
And that's the best part of it all, we now have a built in PNG crusher for Webp called the near_lossless param. Webp related max strength.
Does webp have EXIF? Might be worth it if it's the only lossless compressed format that can do metadata. png is dogshit with metadata
you got cherry MX reds in that beast?
NOOOOOOO DON'T GIVE ME HIGHER QUALITY IMAGES FOR LESS BANDWIDTH!!!!!!!!
>"-metadata string
A comma separated list of metadata to copy from the input to the output if present. Valid values: all, none, exif, icc, xmp. The default is none."
Here is my basic windows PNG batch script:
for %%f IN (*.png) do (
cwebp -z 9 -lossless "%%f" -o "%%~nf.webp")
>lossy WebP
Pathetic.
Observe, lossless 976K: files.catbox.moe
>no web browser support
>no software support of any kind
>literal who? virtually everywhere
>in perpetual pre-alpha
Are the devs who abandoned it at least putting their time and effort into avif?
>"Input #0, webp_pipe, from 'sfj6p1.webp':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: webp, argb, 1020x1480, lossless, 25 tbr, 25 tbn, 25 tbc"
Also can YOU even tell the difference of that "lossy" webp and the original PNG?
Consider this lossless 1125 KiB FUIF image: files.catbox.moe
Using latest FUIF commit, which is a worse version of what will be known as JPEG XL and also supports the extra features that FLIF also has (e.g. interlacing, downscaling) while still being smaller than the comparable lossless WebP (-preset drawing -m 6 -lossless) at 1154 KiB and without these features.
Don't care if it's in the lossless WebP codec; the image itself is quality-degraded from the source. I could've posted a ~650 KiB Q90 FLIF if I wanted to compete with "perceived" quality.
The issue here is that the lossless source exists and is even available, but some providers use UA detection to provide degraded images to certain client. There would be no real issue if they were full-quality lossless WebP or whatever.
How the FUCK do I open this piece of shit?
Compile FUIF (github.com
-lossless and -m cant be used together. Should be -lossless -z 9
Fuck that, webp already gives me migranes. Fuck off with your literally who? format.
PNGcuck was using lossy dithering in that thread IIRC. I'm actually surprised completely lossless webp was even able to reduce the file size of that even further.
My bad, 1146 KiB WebP then. Whole 7.7 KiB saved, not bad.
>JPEG XL
>Literally who
It's the actual successor to JPEG and PNG both, containing all the good features of FLIF (interlacing, downscaling, etc.) and PIK (and JPEG), not the AVIF thing that's only kinda okay for lossy stuff.
explain
Does it even outperform Webp by a significant margin? I got around 100KB with a quality setting of 90.
It's an old retarded test from like 2015 using a highly outdated webp encoder testing what would happen if a clinically braindead retard transcoded an image over and over again for no reason hundreds of times with lossy compression. It's a dumb test of use to fucking no one.
Sometimes, perhaps. Lossy FUIF can be even worse than lossy AVIF or even lossy WebP, but with PIK stuff, JPEG XL should improve on that too. Also, note that it's a different kind of compression with different quality degradataion. Unlike the VP8/AV1 inter-frame encoding, this one won't blur the image and delete fine details (but might produce more JPEG-style blocks, IIRC).
Also note that FUIF is a mere tech demo. To get the full idea of what JPEG XL will potentially be able to do, also consider FLIF and PIK.
What a shame, guess I'll wait for avif and use webp atm.
AVIF is just an improved lossy WebP without the decent lossless algorithm. Wait for JPEG XL while using lossless WebP.
Nah, too literally who? for me. I'd rather just experiment more with the advanced params of webp. Webp related was made with the following params: -preset drawing -sharp_yuv -m 6 -sns 70 -f 50 -size 150000 -pass 10
Do you recommend any specific param settings to get the most out of lossy encoding possible?
it's 'psych' as in 'psychology'
Followup on this:
cwebp -preset drawing -m 6 -q 90 1568640721843.png: 176K: files.catbox.moe
Decoded: files.catbox.moe
Compared with source: files.catbox.moe
fuif -Q90 1568640721843.png: 219K: files.catbox.moe
Decoded: files.catbox.moe
Compared with source: files.catbox.moe
WebP doesn't support many of the features of FLIF/FUIF/PIK/JPEG XL, such as being interlaced (decode into lower res version by truncating data) or being able to losslessly reencode and compress lossy JPEGs.
For lossy stuff, you always want to balance quality with size. Toy around with cwebp's -q, -psnr, -size; try -af and other such silly stuff, but then actually do compare the images. There's no single magical loss option that will work well for every example.
based and retarded
You niBBas are forgetting we can post Webp files here, script related:
for %%f IN (*.png, *.jpg) do (
ffmpeg -loop 1 -i "%%f" -pass 1 -y -g 1 -c:v libvpx -auto-alt-ref 0 -lag-in-frames 25 -bf 8 -b:v 1M -deadline best -cpu-used 0 -an -t 1 -r 1 -f webm nul
ffmpeg -loop 1 -i "%%f" -pass 2 -y -g 1 -c:v libvpx -auto-alt-ref 0 -lag-in-frames 25 -bf 8 -b:v 1M -deadline best -cpu-used 0 -an -t 1 -r 1 -f webm output.webm
)
I'm not sure if "-lag-in-frames 25 -bf 8" does anything tho, It's from a 2-pass video webm script I already have:
for %%f IN (*.mp4, *.mkv, *.webm, *.gif) do (
ffmpeg -i "%%f" -pass 1 -y -c:v libvpx -auto-alt-ref 0 -lag-in-frames 25 -bf 8 -b:v 1M -deadline best -cpu-used 0 -an -f webm nul
ffmpeg -i "%%f" -pass 2 -y -c:v libvpx -auto-alt-ref 0 -lag-in-frames 25 -bf 8 -b:v 1M -deadline best -cpu-used 0 -an -f webm output.webm
)
Congratulations, you win the "worst lossy version in the thread" award!
Thanks
How about this one? I was just using the stock 1M bitrate param on the last one. This one has 50% extra bits and pieces.
>using dumb hacks to post an oudated image format
for what purpose though
Webp, like Linux, is only promoted by pedos, gay pedos.
Slightly better, but still worse than the WebP in , which is smaller than your WebM
HQ high res wallpapers or pics that load faster I guess. 4chink maxes out rest at 2048x2048 tho so the hack can only go so far. Also someone figured out how to hack it to put entire manga chapters in a single Webm under 3MB but I lost the script for that. It used -g 1 param, that much I remember.
Just use gyazo to copy the image from the search results.
They'll probably make screenshots illegal when they're done with vapes though.
Obviously re-encoding the output over and over.
When you encode from lossy format to lossy format data loss will occur.
If you open a JPEG and save as JPEG, take the output ans save it as JPEG, and so on for 500 times, that's what you get.
>shitting on open sores webp
Have you no shame, Jow Forums? Would have you all preferred another royalty fee ridden mpeg abomination have taken over?
>using a encoder from 2009 while comparing it to other formats with modern encoders
Talk about bias, you're actually retarded. Enjoy this (You).
I remember trying to save some webp shit from tenor and it didn't save the actual webp file or something, and I was not able to transcode from webp to webm or gif.
webp is fucking cancer and i make sure to search through my hdd every now and then and delete any webp files i may have accidentally saved.
>When you encode from lossy format to lossy format data loss will occur.
Fun fact: PIK (and upcoming JPEG XL) can be used to losslessly reencode JPEG while also compressing it.
Works for me.
>user closed this permanently
>user added wontfix label
HOLY SHIT I FOUND IT:
ffmpeg -r 1 -f image2 -i img_%%03d.jpg -pass 1 -y -g 1 -c:v libvpx -auto-alt-ref 0 -lag-in-frames 25 -bf 8 -b:v 1M -deadline best -cpu-used 0 -an -f webm nul
ffmpeg -r 1 -f image2 -i img_%%03d.jpg -pass 2 -y -g 1 -c:v libvpx -auto-alt-ref 0 -lag-in-frames 25 -bf 8 -b:v 1M -deadline best -cpu-used 0 -an -f webm output.webm
pause
Just adjust the bitrate to change the resultant output quality and change the -i param as needed else make sure your JPG image files read img_001, img_002, img_003...
Webm for manga chapters is absolutely insane. Webm related didn't even use the 1Mbps bitrate I gave it, QP maxed out around 700Kbps.
wtf
>2.) Loads faster for users.
It would be even faster if WebP would support progressive decoding like JPG or PNG.
>3.) You don't have to have multiple formats for different image types, now one does the work of 3
That is not really positive or negative. Purists will argue that it muddles the immediate understanding of which compression is applied. Personally I have at least a problem with lossy and lossless WebP being to independent compression algorithms.
-z implies -lossless
JPEG XL will solve all of these issues.
Perhaps in older versions. -m is now just the speed setting and can be used for both lossy and lossless WebP.
So -m implies lossy?
>SIKE
god i wish that was me
Nah, webp is here to stay. Progressive decoding isn't really a necessity when images are 480p-1080p 50-200KB files.
Webp works fine. Can't stop everyone from mislabeling file types.
Maybe you should only identify files by MIME type rather than file name, eh.
Yes
No
Are people really too braindead to install nomacs to view them and use gimp to edit them? Doesn't photoshop have a webp plug-in by now?
>
-m does not imply lossy and does not turn off -lossless
>AVIF is just an improved lossy WebP without the decent lossless algorithm.
AV1's intra compression is much more efficient than VP8's and it does offer a pretty good lossless compression (close or equal to FLIF).
a) -lag-in-frames won't be used without alternate reference frames and even then it's pretty useless, if you just encode a single keyframe.
b) Activating B-frames is just as pointless and VP8 doesn't even have them.
c) It's better to use constant quality or constrained quality (with a very high bitrate) for these "WebP hacks".
d) You don't need to loop the image, if you just encode one frame.
e) You don't need to suppress audio output, if there's no audio input.
No. -m is just the general speed setting and can be used for lossy and lossless WebP. -z is the speed settings specifically for lossless WebP and basically includes -m as well as some other options.
It should, it uses macroblock prediction malarchy aimed for lossy encoding. -z uses exhaustive searches that actually benefit lossless encoding.
>close or equal to FLIF
Even if it is close, it lacks all the other features FLIF has. Not worth it.
Whether lossy mode will be better or worse than AVIF remains to be seen. They produce fundamentally different loss (blurring/detail loss vs artifacts). JPEG XL will also be usable as a true original JPEG replacement, since it can recompress them without adding any additional loss.
What lever nerd are you? I could only understand half of what you wrote. Be more concise, jesus.
Cool all jpeg has to do is reach 80% browser support. It can get in line behind flif.
Sure, but I was talking about WebP vs. AVIF.
What didn't you understand?
FLIF will essentially be deprecated by JPEG XL. As for browser support, there's really only two browsers that have to include it. Mozilla generally hasn't been too hostile to supporting alternate formats, as long as the implementation is decent, so Chromium would likely be the main one to convince. JPEG XL will be an actual standard with support from more than just one dev as his pet project, so it wouldn't be unimaginable that it'd get accepted.
Mobile phones would likely be the main issue, but if it gets into Chromium, it'll also get into Android and iOS already doesn't support most sane formats right now anyway.
b) Actually it kinda does. Alternate reference frames are used in a similar manner when performing 2 pass encodes.
c) QP control on VP8 has been perpetually borked, forcing a specific bitrate forces better bit distribution even on a single keyframe.
Fuck it, I wasn't cut out for this 1337 hacker darkweb shit, I'm going to /v/. Have fun you nerds.
>FLIF will essentially be deprecated by JPEG XL.
Really? It doesn't seem to have the same feature set.
Seems to me like Pik will be superseded by JPEG XL. Maybe.
FLIF's author is responsible for a large part of the JPEG XL proposal (FUIF) and it shares a lot of the feature set of FLIF, with more focus on lossy stuff. What exactly does FLIF have over it?
So why does -z exist then if both control compression level?
In 2019, what becomes popular or deprecated is almost solely dependent on what the almighty Chrome/Chromium/Blink team decides. You could figure out a way to have a million to one compression ratio, but it means jack shit in terms of the WWW so long as the resulting files are unreadable in the monopoly browser.
Personally, I hope they're deprecating everything in favor of dumb bitmaps.