[ 3 / biz / cgl / ck / diy / fa / g / ic / jp / lit / sci / tg / vr / vt ] [ index / top / reports / report a bug ] [ 4plebs / archived.moe / rbt ]

Due to resource constraints, /g/ and /tg/ will no longer be archived or available. Other archivers continue to archive these boards.Become a Patron!

/g/ - Technology

View post   

[ Toggle deleted replies ]
File: 22 KB, 760x400, 1521830159820.webm [View same] [iqdb] [saucenao] [google] [report]
68430296 No.68430296 [Reply] [Original] [archived.moe] [rbt]

Script from last thread:
for %%f IN (*.png, *jpg) do (
ffmpeg -loop 1 -i "%%f" -filter:v hqdn3d=8.0:8.0:10.0:10.0 -c:v libvpx -qmin 16 -qmax 16 -quality best -t 2 -r 1 "%%~nf.webm"

>*NEW* processes both PNG and JPG with a single script
>*NEW* post processing added to increase compression

>> No.68430301
File: 381 KB, 760x400, 1521830159820.png [View same] [iqdb] [saucenao] [google] [report]

Here's the original image.

>> No.68430312
File: 77 KB, 1024x887, i4eKfmZ.webm [View same] [iqdb] [saucenao] [google] [report]

>> No.68430321
File: 391 KB, 1024x887, i4eKfmZ.png [View same] [iqdb] [saucenao] [google] [report]

Original for this one.

>> No.68430327

I still can see things thinging in your webm.

>> No.68430343
File: 25 KB, 800x800, 1465101708732.webm [View same] [iqdb] [saucenao] [google] [report]

How noticeable? smoothing filter should have helped with that.

>> No.68430357
File: 319 KB, 800x800, 1465101708732.jpg [View same] [iqdb] [saucenao] [google] [report]

Oh fuck, you can tell this one has that. It's like it's alive and beating...

>> No.68430389
File: 23 KB, 800x800, 1465101708732.webm [View same] [iqdb] [saucenao] [google] [report]

Modified -t and -r parameters to 1. Artifacting seems to be gone but cpu usage is spiking...

>> No.68430398

wow! this reminds me of those "Compress this image for me" threads. those were fun. thanks for putting in the work anon!

>> No.68430418

Only added the smoothing filter to the script from a thread a while back. There's just this 1 weird problem I can't seem to solve: when setting webm duration and frame rate to 1, the cpu usage goes up but the "pulsing" artifact is gone. Any help on this would be greatly appreciated.

>> No.68430479
File: 58 KB, 1440x810, Sister-Maria.webm [View same] [iqdb] [saucenao] [google] [report]

>tfw the transcode makes JPGs look better

>> No.68430487
File: 149 KB, 1440x810, Sister-Maria.jpg [View same] [iqdb] [saucenao] [google] [report]


>> No.68430542

probably the deblocking filter?

What does "hqdn3d=8.0:8.0:10.0:10.0" do?

>> No.68430572
File: 15 KB, 530x325, 6c72fa4761.webm [View same] [iqdb] [saucenao] [google] [report]

Denoiser filter, though I have no idea what the numbers mean senpai.


>> No.68430584
File: 27 KB, 530x325, 6c72fa4761.jpg [View same] [iqdb] [saucenao] [google] [report]


>> No.68430616


>> No.68430619

What's the use?

>> No.68430632

Better image compression and the ability to post process them despite 4chans refusal to adopt webp. Even before the denoiser VP8's deblocking feature already smooths out images by default.

>> No.68430635

Since vp9 optimized for 4k+ videos, it should compress high res images better too. Unfortunately anhiro will never support it.

>> No.68430670

lost a lot of detail in the leaves outside and the wall below the window

>> No.68430695

looks like blurry shit in comparison to >>68430301

>> No.68430706

Is there a better denoiser than >>68430572

I know yify uses that or something similar BEFORE encoding their shitty releases to 400MB.

>> No.68430731

Would adding sharpening filter help?

>> No.68430748

Im a retard, whats the point of this?

>> No.68430763

We pretend 4chan adopted webp which is about 50% more efficient than JPG and lossless PNG now.

>> No.68430784

Don't mean to be a brainlet, but bash is telling me
└╼ for %%f IN (*.png, *jpg) do (
bash: syntax error near unexpected token `IN'

>> No.68430788

This should probably be limited to images that fit inside a 480p-720p frame, anything big like >>68430479 feels out of place.

>> No.68430793

It's for windows m8, you're gonna have to freetard yourself out of this one on your own.

>> No.68430795
File: 15 KB, 188x116, subnosub.png [View same] [iqdb] [saucenao] [google] [report]

Is this disabling the chroma subsampling as well?
It's quite darn useful with jpeg.

>> No.68430808

VP8 does 420 blaze it faggot afaik

>> No.68430888

edge and firefox have finally announced they're going to support webp


>> No.68430906

lol, now when safari adopts it macfaggots will call it "revolutionary".

>> No.68430993

Ah, I could probably do something with find then

>> No.68431090

Didn't even have to do that
mkdir out
for f in *.{png,jpg}; do ffmpeg -loop 1 -i "$f" -filter:v hqdn3d=8.0:8.0:10.0:10.0 -c:v libvpx -qmin 16 -qmax 16 -quality best -t 2 -r 1 "out/${f%.*}.webm"; done

>> No.68431160
File: 69 KB, 775x837, 1478201807359.jpg [View same] [iqdb] [saucenao] [google] [report]

I wish I was as smart as you anon. Life as a dipshit is so hard, you wouldn't believe.

>> No.68431457

what exactly is going on in this thread

>> No.68431626

People transcoding images to webms with a blur filter

>> No.68432367
File: 180 KB, 1024x887, 1516330863554.png [View same] [iqdb] [saucenao] [google] [report]

That's nice and all, but should only really be used when you're dealing with pictures that you couldn't post otherwise. Most images on here already look like shit. Encoding them lossy again and on top of that with a denoise filter shouldn't be the to-go solution.
Plus you can't do lossless compression like with WebP, since VP8 doesn't support it.

Also pictures like this can be effectively optimized without introducing additional losses.

You need to use two passes. libvpx's single pass bitrate control is basically broken.

NLMeans is a great denoiser, although you have to be careful not to smoothen the picture too much. It was designed for old VHS footage.

>> No.68432642
File: 183 KB, 1247x742, Screenshot_20181110_194211.png [View same] [iqdb] [saucenao] [google] [report]

Holy shit. OP not bad

To bad I can't post images with 4k resolution

>> No.68433122

Is this a joke? The garbage you've posted is blurry is shit. It's just crap.
The point of webp is that it can conserve detail and compress better. What you've shown compressed files, but loses a fuckton of detail.

>> No.68433158

notice how the webm have a smaller file size than the original image?

>> No.68433173
File: 20 KB, 760x400, 1541822519906.jpg [View same] [iqdb] [saucenao] [google] [report]

and lower quality

>> No.68433434
File: 58 KB, 760x400, youre a fag.webm [View same] [iqdb] [saucenao] [google] [report]

>> No.68433472
File: 68 KB, 800x800, youre a fag.webm [View same] [iqdb] [saucenao] [google] [report]

>> No.68433480
File: 136 KB, 1440x810, Sister-Maria.webm [View same] [iqdb] [saucenao] [google] [report]

>> No.68433496

The problem with this is that you can't zoom easily.

>> No.68433574
File: 55 KB, 775x837, 1478201807359.webm [View same] [iqdb] [saucenao] [google] [report]

OP is fucking retarded with his shitty ass blur filter.

ffmpeg -t 1 -loop 1 -r 1 -i %1 -c:v libvpx -quality best -qmin 1 -qmax 5 -an -sn -y -f webm "%~n1.webm"

Save that as a .bat and drag and drop your image on it.
You do lose quality and your image will get a bit blurry, but I think it's an acceptabl-ish amount. It's certainly not as retarded as OP's webms.
It works best for real life photos. Line art and plain color images do not get compressed well at all.

>> No.68433586
File: 50 KB, 760x400, 1521830159820.webm [View same] [iqdb] [saucenao] [google] [report]

Play with the qmin and qmax values for better quality and worse compression.
Ultimately, saving images as webm is retarded.

>> No.68433608

how do i use the script? do is ,/ script.sh file nameE?

>> No.68433863 [DELETED] 
File: 41 KB, 637x480, output.webm [View same] [iqdb] [saucenao] [google] [report]

>> No.68433872

high cpu, that's why OP uses -t 2 -r 1

Save it as a .BAT in a text editor, put it in the directory of images, and double click it. This assumes you have ffmpeg installed.

>> No.68433878

Those are pretty high values (especially for the spacial denoising). No wonder the pictures look washed out. Wouldn't even recommend those settings for grainy Blurays.
Also not sure how much of an effect the temporal denoising even has in this situation. I'm no expert, but doesn't it compare consecutive frames and average the movement? Does that even matter when every frame is the same?

The scripts you quoted are batch scripts for Windows.
OP's version gets executed by double clicking it. It'll loop through all JPGs and PNGs in the same directory.
The one from the other anon gets executed by dragging and dropping a file onto it.
For Linux use this one >>68431090. Put it in a shell script and either run bash script.sh or make it executable and run it via ./script.sh . This one will also loop through all JPGs and PNGs in the same directory.

>> No.68433889
File: 36 KB, 637x480, output.webm [View same] [iqdb] [saucenao] [google] [report]

>> No.68433903

High cpu

higher cpu

>> No.68433932

temporal denoiser is supposed to help reduce the "pulsing" of the image since 2 frames are generated with -t 2 -r 2 to reduce cpu usage

>> No.68434008

>high cpu
Does not matter. They're fucking reaction images. As I said, converting images to webm is stupid.

>> No.68434083
File: 633 B, 1920x1200, diff_constant_quality.png [View same] [iqdb] [saucenao] [google] [report]

The pulsing would be unlikely to occur if you would you constant quality. For example let's compare
ffmpeg -loop 1 -i in.jpg -t 2 -r 1 -c:v libvpx -crf 16 -b:v 0 out.webm
(that's how you use constant quality with libvpx)
ffmpeg -loop 1 -i in.jpg -t 2 -r 1 -c:v libvpx -qmin 16 -qmax 16 out.webm
ffmpeg -loop 1 -i in.jpg -t 2 -r 1 -c:v libvpx -qmin 16 -qmax 16 -vf hqdn3d=8:8:10:10 out.webm

After each webm was made I extracted the 2 frames via
ffmpeg -i out.webm -vf fps=1 "%02d.png"
and compared them via ImageMagick
compare -compose src 01.png 02.png diff.png
Red marks areas where 02.png differs from 01.png.

First the result of using constant quality.

>> No.68434094
File: 21 KB, 1920x1200, diff_whatever_OP_is_doing.png [View same] [iqdb] [saucenao] [google] [report]

Now OP's approach but without denoising.

>> No.68434101
File: 25 KB, 1920x1200, diff_whatever_OP_is_doing_but_with_denoising.png [View same] [iqdb] [saucenao] [google] [report]

And now OP's original approach.

>> No.68434134
File: 1.32 MB, 1920x1200, in.png [View same] [iqdb] [saucenao] [google] [report]

Also for anyone who wants to test it as well, here's the source picture.
Originally it was a JPG, but in order to prevent further generational loss I'll post it as PNG.

>> No.68434195

enjoy your oil painting

>> No.68434242

The two pictures have different colors of the skin. The WebP is more reddish.

Same here.

>> No.68434289
File: 63 KB, 720x269, Screenshot_2018-11-10-08-16-54(1).jpg [View same] [iqdb] [saucenao] [google] [report]

How the fuck do you run bash scripts on termux without root?

>> No.68434300

sh webm_c.hs
chmod +x webm_c.hs && ./webm_c.hs

>> No.68434336

And since I was testing it here some additional infos.
>constrained quality delivers the same results as constant quality with a high enough bitrate specified (in this case 10M)
>constrained quality with 2 passes differs even less
>constant quality with 2 passes is still better than OP's approach but much worse than when using a single pass

>> No.68434391
File: 30 KB, 720x114, Screenshot_2018-11-10-08-25-49(1).jpg [View same] [iqdb] [saucenao] [google] [report]

bless you anon, though now pic related happens with

mkdir out
for f in *.{png,jpg}; do ffmpeg -loop 1 -i "$f" -filter:v hqdn3d=8.0:8.0:10.0:10.0 -c:v libvpx -qmin 16 -qmax 16 -quality best -t 2 -r 1 "out/${f%.*}.webm"; done


>> No.68434415
File: 441 KB, 834x849, Screenshot 2018-11-10 at 15.26.50.png [View same] [iqdb] [saucenao] [google] [report]

2nd is better

>> No.68434478

What shells are available on your system? The brace expansion isn't defined by POSIX, so your system's shell might not support it.

>> No.68434499

bash is default


>> No.68434521

Then the only other explanation is that the script doesn't find any JPGs or PNGs in the directory (even though >>68434289 suggests otherwise).

>> No.68434548
File: 27 KB, 982x1024, Michael-Scott-Sad-Face-Funny-Picture.webm [View same] [iqdb] [saucenao] [google] [report]

I'm so fucking dumb anon, all I had to do was run it with bash. Thank you for putting up with me.

>> No.68434565

Alternatively put this shebang right at the start of your script

>> No.68434612
File: 48 KB, 955x610, just.webm [View same] [iqdb] [saucenao] [google] [report]

No dice but just glad bash werks™. This is fun, now /g/ will be twice as insufferable.

>> No.68434644
File: 138 KB, 1440x810, test.jpg [View same] [iqdb] [saucenao] [google] [report]

that's not much savings
here's a comparison with just having jpegoptim target the same filesize

>> No.68434699

And the colors are different, for some reason.

>> No.68434747
File: 999 KB, 470x353, 1489432763581.gif [View same] [iqdb] [saucenao] [google] [report]

>People pretending to have a feature that will never be implemented because hiro and the mods don't give a single fuck about this dead grave of a site except for the traffic and adbux it brings them.
I don't know whether I should feel sad or amazed at the delusion of some people here.

>> No.68434779

You just reintroduced the jpg artifacts lmao.

>> No.68434841
File: 12 KB, 1440x810, Sister-Maria.webm [View same] [iqdb] [saucenao] [google] [report]

Hey, guys, I did it! Check out that file size.

ffmpeg -t 2 -loop 1 -r 1 -i %1 -c:v libvpx -quality best -qmin 63 -crf 63 -qmax 63 -an -y -f webm "%~n1.webm"

>> No.68435013

For the file size that's fucking crazy. Can you go any lower?

>> No.68435110
File: 11 KB, 1440x810, Sister-Maria.webm [View same] [iqdb] [saucenao] [google] [report]

I tried setting the quality to realtime instead of best, but it gives me 16 KB for some reason.

>>68434841 12,174 bytes
This one is 11,398 bytes

>> No.68435124

By the way, the command is the same except for the -t, which is 1 in this >>68435110 case.

>> No.68435147
File: 114 KB, 470x353, 1489432763581.webm [View same] [iqdb] [saucenao] [google] [report]

Why not BOTH?

>> No.68435209

The colors are all wrong though. Real WebP with roughly the same file size (12,248 bytes compared to the WebM's 12,174 bytes) also looks shit, but at least it got the colours right.
>Can you go any lower?
This is the lowest I managed to go with cwebp. 11,868 bytes.

>> No.68435272

I don't think anybody here except that retarded OP is arguing that webm is better than webp. I'm pretty sure we're all fucking around with ffmpeg.

>> No.68435311

There are people out there that think WebP is just VP8 in picture form. Better fight that misconception from the start.
Plus it gives me an excuse to fuck around with cwebp. I normally don't use WebP so it's interesting to see what it can and can't do and how all the settings work.

>> No.68435351
File: 160 KB, 900x900, 1511396778699.jpg [View same] [iqdb] [saucenao] [google] [report]

Hey /g/oys I just thought of something massively retarded. How practical would it be to cram like 20-40 mango pages in a webm video under 3MB?

>> No.68435529

You can certainly try.
WebM is a lossy format, though, and if you want to read lossy-compressed to shit manga anywhere, you might as well use any of those hundreds of shitty manga sharing sites.

>> No.68435542
File: 2.57 MB, 969x1400, test.webm [View same] [iqdb] [saucenao] [google] [report]

Like this? You have to play around a bit with the quality parameters, but otherwise totally doable.
Although >>68435529 does have a point.

>> No.68435670
File: 72 KB, 302x371, 1533629109420.jpg [View same] [iqdb] [saucenao] [google] [report]

holy shit

>> No.68435990

That is a function of Unix not termux. The file itself wasn't given execute privileges. Hence the suggestion to chmod +x. Go look up octal privileges online. Eli computer guy on YouTube has a no bullshit guide that gets to the point without millennial Bing bing wahoo noise, just a whiteboard and explanations.

>> No.68436757

>youtube video to explain why you need admin pass to run terminal commands
>year of linux desktop soon

>> No.68436868
File: 92 KB, 736x1018, input-00.jpg [View same] [iqdb] [saucenao] [google] [report]

Cool. I remember these threads.

Wish I had more time to play with this stuff today.

>> No.68436895
File: 55 KB, 736x1018, output-04.webm [View same] [iqdb] [saucenao] [google] [report]

I was really bad at this...

>> No.68436980
File: 203 KB, 439x371, Y50P0vt.webm [View same] [iqdb] [saucenao] [google] [report]

There has to be a sweet spot with PP, highly compressed VP8 images look like oil paintings. Hoe the FUCK does yify do this shit...

>> No.68437036
File: 34 KB, 320x320, voMzrZYUq9_gW7cx9mAsFpMIuabTcEyaUNJUneXYk.webm [View same] [iqdb] [saucenao] [google] [report]

gif to webm bash script for anyone interested:

mkdir out
for f in *.gif ; do ffmpeg -i "$f" -filter:v hqdn3d=8.0:8.0:10.0:10.0 -c:v libvpx -b:v 0 -qmin 20 -qmax -crf 30 50 -quality best "out/${f%.*}.webm"; done

>> No.68437067

>-filter:v hqdn3d=8.0:8.0:10.0:10.0
Fucking stop. Kill yourself already. ow do you not see that your blurred garbage looks like shit?

>> No.68437085

people who do this should be jailed

>> No.68437103

Change the parameters then you dick, I'm just going for small file sizes.

>> No.68437202
File: 4 KB, 720x114, Screenshot_2018-11-10-12-35-36(1).webm [View same] [iqdb] [saucenao] [google] [report]


>> No.68437222

Why does compression turn me on so much?
Learning how jpg works was one of the best days of my life

>> No.68437278
File: 217 KB, 435x250, HardAbandonedChinesecrocodilelizard-size_restricted.webm [View same] [iqdb] [saucenao] [google] [report]

Because deep down we're all minimalists.

>tfw the original gif is over 4MB and looks slightly better than this webm

>> No.68437353
File: 59 KB, 1920x1080, file.webm [View same] [iqdb] [saucenao] [google] [report]


>> No.68437361
File: 1.05 MB, 1920x1080, 7b9cb3e85aec1a5c9a487156b2c75b9b.jpg [View same] [iqdb] [saucenao] [google] [report]


>> No.68437381
File: 3 KB, 500x374, DJK5nVt (1).jpg [View same] [iqdb] [saucenao] [google] [report]


>> No.68437395

they probably won't, they'll rather suck the dick of MPEG-LA

>> No.68437439

You just find the artifacts nostalgic.

>> No.68437499

brainlet here, what is the point of all this?

>> No.68437503

Look at >>68437353 and >>68437361
Compared the file sizes

>> No.68437517

Retards getting a boner when they compress images with a video format and lose a shitton of quality in the process.

>> No.68437522
File: 5 KB, 500x374, jpeg.webm [View same] [iqdb] [saucenao] [google] [report]


>> No.68437523

With added post processing you can cram images into smaller file sizes AND reduce their original artifacting. You win every time.

>> No.68437529

No practical reason for now.

Compare the file sizes of between the two "pictures" and then come to terms with the fact the "video" is several orders of magnitude smaller.
At the same time, overlord Hiroshima refuses to implement picture formats which blow these pseudo-pictures out of the water. And then goes on and on how much bandwidth 4chan eats up and how costly it is to run as a result.

>> No.68437544

>You win every time.
If you want to look at blurry images, sure.

>> No.68437547
File: 574 KB, 4466x5000, gal-smile.jpg [View same] [iqdb] [saucenao] [google] [report]

Even better with sound.


>> No.68437552


>> No.68437574

Isn't converting an image to video format missing the whole point though?
I see the filesize reductions, but on 4chan at least, size limits are 4mb, and most reaction images barely push 1 or 2 anyway. Also it just doesn't seem practical to have a .jpg/.png stored as a webm but what do I know

>> No.68437602

You are completely correct. OP is just retarded.

>> No.68437612
File: 221 KB, 320x287, 1386795355308.webm [View same] [iqdb] [saucenao] [google] [report]

nothing is free anon

>> No.68437627

>it just doesn't seem practical to have a .jpg/.png stored as a webm
The format is normally webp, but it isn't supported by 4chan, so the files are disguised as webm files

>> No.68437653

Are you baiting? Webm and webp have nothing to do with each other.

>> No.68437663

Its not 1995 anymore. noone cares about kb beancounting

>> No.68437686
File: 92 KB, 600x373, boomer king.png [View same] [iqdb] [saucenao] [google] [report]

>using video to display pictures
No thanks, I will stick with the proven file formats.

>> No.68437688


webp uses modified intra frame encoding of VP8 you dipshit

Tell that to half the internet that uses webp especially for high res images

>> No.68437700

>Tell that to half the internet that uses webp especially for high res images
Literally which?

>> No.68437740

That's the whole point, really.
Hiroshima did actually complain about the bandwidth taken up by the pictures on 4chan and actually threatened to shut the whole site down because of the generated expenses and not being able to cover them.

Yet he's vehemently against implementing these bandwidth saving measures for some retarded reason only known to him.

In other words, he's either a genuine imbecile or simply a lying dick trying to scam idiots out of their money.

>> No.68437741

You're storing images as video. You're retarded.

>> No.68437766

Just blurring the whole picture is a really bad way to get rid of compression artifacts. Using something like waifu2x gets rid of them without sacrificing too much detail (although some is still lost).

It has two advantages. It allows you to post pictures that you normally couldn't fit within the 4MB limit with a reasonable quality. Additionally it gets rid of the generational loss that you usually have when using JPG.
Personally I rather use PNG, optimize it lossy and perhaps scale it down if it still doesn't fit the limit, but using WebMs for it is also an option. Applying such a strong denoise filter is stupid though and most people in here don't seem to know a thing about libvpx's bitrate allocation modes.

>webp uses modified intra frame encoding of VP8 you dipshit
Not him. Yes, WebP is based on VP8 technology, but that doesn't mean they are the same. You're not disguising WebP as WebM.

>> No.68437771

ebay, facebook, blog posts, benchmarking websites, high res image websites just to name a few of where I've seen webp used extensively.

>> No.68437775

i dont know ANYONE that does photography that uses webp to publish or even share images. certainly not to store them.
and if they do , its for lossless stuff so size isnt the main concern to begin with

>> No.68437825

>It allows you to post pictures that you normally couldn't fit within the 4MB limit with a reasonable quality.
Nobody in this whole thread has done this yet.

Webm is as susceptible as jpg to generation loss.

>> No.68437837

Went to ebay now, didn't see a single webp.

>> No.68437850

that's a good point
Apparently Hiro's unironically started shoving ads mid thread now, and not small ones but the huge ass ones.

>> No.68437873

>thinking anyone except some people on /g/ would actually use it

>> No.68437893

>It allows you to post pictures that you normally couldn't fit within the 4MB limit with a reasonable quality.
Sounds useful, but even if I were to save that, I couldn't use the file like an image, so it seems like its use would be limited to posting here. which is useful, but not massively so

>> No.68437899

Imagine an 8MP image about 40MB with JPG. Webp can encode a 32MP image that fits on an 8K monitor for about 60MB. AVIF will then be able to encode a 64MP image for about 40MB for similar quality.

File size does matter, dipshit.

>> No.68437936




Just a few from the front page, most of them are covered in javascript.

>> No.68437965

Protip: you can extract VP8 frame, slap on a riff, and generate a webp without having to transcode.

>> No.68437985
File: 42 KB, 683x1024, flower-00.webm [View same] [iqdb] [saucenao] [google] [report]

These threads used to be about trying to compress a large image file into something smaller (video file). It wasn't a crusade to save bandwidth. It wasn't an attempt to abandon png/jpgs. It was something odd and fun.

You faggots ruin everything.

>> No.68438001

Okay, I just used the network checker in Firefox and didn't see them.
Does the JS convert them to jpg or something though because I can't even open those without downloading them?

>> No.68438019

Are you on the latest build? They should have webp support by now, they abandoned their lib-turbo SJW frankenstine a while ago.

>> No.68438021

Blame OP for that. He abandoned quality for muh filesize.

>> No.68438037

Hey twarfarts, how about you help us figure out what post processing will give us the best results. We're trying to make a webp yify kind of thing here.

>> No.68438047

I've always remembered people constantly comparing them to jpg/png though.

"Don't worry jpg/png (((we))) are just comparing"
t. webm/p

>> No.68438049

Youtube also uses it for animated thumbnails.


>> No.68438055
File: 70 KB, 683x1024, input-01.jpg [View same] [iqdb] [saucenao] [google] [report]


>> No.68438061

No post processing. If you can't get it with just qmin, qmax, crf and b:v then give up.

>> No.68438081

>62.0.3 (64-bit)
From the Arch repo, don't know if that makes a difference.

>> No.68438103

>Youtube also uses it for animated thumbnails.
Does Youtube have that now? Thought the porn sites were better there as with many things they've done first.

>> No.68438123
File: 73 KB, 531x683, 1959365039576.jpg [View same] [iqdb] [saucenao] [google] [report]

Dam dude, don't give up that easily.

>> No.68438142


>> No.68438147

Every single person counts and it's not been that long ago that /g/ taught the rest of the site how to WebM.

The only real issue is that communicating the advantages to the people won't be as easy as with gifs. I think the people who'd appreciate the most would be artfags/mangafags.
WebP, even when set to lossless, is smaller than PNG and the stuff they upload sometimes doesn't quite fit on the site.
So they'd start using WebPs and, on average, lessen the bandwidth.
Bonus points for fighting the issue of repeated JPG compression which people now fight by putting it all into a gigantic PNG which is, once again, often denied by the system as too large and they have to cut and resize the image.

>> No.68438148

>Nobody in this whole thread has done this yet.
Yeah. OP is apparently only interested in saving file size by butchering the quality.
>Webm is as susceptible as jpg to generation loss.
Goddammit, I need another coffee. My mind went to lossless WebP while typing that.

>> No.68438177


Why would we want to keep png and jpeg around?
It's 1990's technology, nice for their age but hopelessly inefficient compared to modern techniques.
They only still get used because people got used to them, by the same logic we should all be using VHS.

>> No.68438216

Keeping other formats around is good because it shows people that not all pictures are the same and that formats actually exist and some are better than others.
If you simply buddied up with all tech companies and stopped supporting all other formats in favour of WebP, you'd face an unwinnable battle trying to get people to switch to the something better that might arise in the future.

>> No.68438229

This is what I've the biggest problem with, webm had a huge advantage compared to gifs. With webp I mostly see a meme format that might as well be dead in 10 years while jpg and png will probably live on.

>> No.68438232

Looks better on original

>> No.68438249
File: 70 KB, 950x534, apple aux.jpg [View same] [iqdb] [saucenao] [google] [report]

>It's 1990's technology, nice for their age but hopelessly inefficient compared to modern techniques.
"It's just so old, it had to go."

>> No.68438263
File: 56 KB, 720x720, reee.jpg [View same] [iqdb] [saucenao] [google] [report]


>> No.68438265

Nobody is talking about dropping legacy support.
You will still be able to view all existing files.
Just stop making new files that use outdated compression, that's all.

>> No.68438289

From shitty mobile devices? Yes, it had to go. It's not going anywhere for more serious stuff.
Smartphones are used by normies. The less cables there are, the better.

>> No.68438307

Compatibility. That's the big reason. You don't just dethrone codecs that have been around for decades in a day. It takes years to establish a new standard.

>> No.68438387

>have to use the same cables + dongles
Huge improvement...

>> No.68438464

>You don't just dethrone codecs that have been around for decades in a day.

We do it with video all the time.

>> No.68438493

Once we have a better alternative, like analog audio over USB-C, then it's time to switch yes.

>> No.68438527
File: 21 KB, 800x800, not b8 bait.png [View same] [iqdb] [saucenao] [google] [report]

>analog audio over USB-C
>better alternative

>> No.68438732

Yes, because we completely abandoned H.264 yet and DivX was also immediately dropped for H.264.
The reason Theora, VP3 and stuff like that disappeared quickly is because they never became popular in the first place.

>> No.68439059

Realistically, how can we get webp adoption on 4chan?

>> No.68439390

>why you need admin pass
you literally don't you idiot

>> No.68439511


Look at the colour tiling on the wall

>> No.68439517

holy shit a GOOD thread

>> No.68439524


Lost details for the wires in the back left

>> No.68439960
File: 58 KB, 722x349, 1522271157248.jpg [View same] [iqdb] [saucenao] [google] [report]

Right? Almost feels out of place.

>> No.68439993

The only cable you need to use with a phone is the charging cable. And maybe not even that if you're into wireless charging.
It's a fucking phone.

>> No.68439996

Why the fuck would I want to make a 2 second video of an image

>> No.68440073

Why to do this in general has been answered several times in this thread now. Whether or not it's worth it is a different question.
The 2 second duration is necessary to prevent a CPU spike, because browsers don't handle 1 frame videos well.

>> No.68440080

yify makes sure the first 5 - 10 minutes of a movie is really really good looking, then drops the quality immensely afterwards. Take any random yify rip you have saved and look at the quality of the first few scenes and one towards the end of the movie. There's no magic going on, it's the same kind of "imperceptible loss" that mp3 does: stripping out quality where it expects the mind to not notice.

>> No.68441707

If your sole goal is compression efficiency then why bother with webp? It excels at nothing compared to other modern image codecs. The only advantages it has is more support than formats like flif.

>> No.68441723

tranny standards. fuck that shit.

>> No.68441794

the webm looks blurry as shit

>> No.68443214

make sure you specify "-g 1" so each frame is an i-frame

>> No.68443604

because he ran it through a blur filter

>> No.68443841
File: 3.69 MB, 6400x6400, dabb.jpg [View same] [iqdb] [saucenao] [google] [report]

fuck hiro fuck 4chen bandwidth

>> No.68444008


How many pages can you fit in this? webm supports chapters, what happens when you use those for fastforwarding?

>> No.68445281

rip sound image threads ;_;7

>> No.68445446

I remember when people were doing this solely to piss off Apple users.

>> No.68446864
File: 2.98 MB, 852x1200, 175.webm [View same] [iqdb] [saucenao] [google] [report]

That depends on the image resolution and whether or not you follow this anon's advice >>68443214.
However if you need to increase the keyframe interval to fit the WebM in the 3MB limit, you're already butchering the quality considerably. Plus (something that I also didn't know until I tried it now) libvpx has actually good multi-threading support for intra prediction, so it's a lot faster to use -g 1.

Here's what I can cram into a WebM with only one keyframe at the very beginning.

>> No.68447034
File: 2.64 MB, 852x1200, 116_with_chapters.webm [View same] [iqdb] [saucenao] [google] [report]

And here's one with -g 1. It still looks bad, but I can accept this level of quality for storing 116 pages within 2.6MB. Also added chapters to see if it works.

>> No.68447071

Not this fuckhead again

>> No.68447920
File: 46 KB, 460x566, 1514522538460.jpg [View same] [iqdb] [saucenao] [google] [report]

fucking nice

>> No.68448444

How'd you get it to deteriorate throughout the course of the clip? Fascinating

>> No.68448623

Isn't webp and webm essentially the same thing?
There's animated webp as well.

I guess the only real difference is that webp supports transparency?

Also why doesn't hiro just add support for webp so he can reduce server costs?

>> No.68448687

Force keyframe on each new page?
Set frame rate to 1?
...Much better
Can I ask, how does it compare in size to a zip folder of the PNG's?

>> No.68448736

however BPG/HEIF (coincidentally based on h.265) is way better

>> No.68449038


>> No.68449085

>why doesn't hiro [make a change to 4chan that isn't designed for instant money]
careful anon, next time hiro doesn't have enough money for instant noodles you can expect 4chan pass users to be able to post more file types while non pass users might get mp4 if they're lucky

>> No.68449231

>Force keyframe on each new page?
-g 1 sets the GOP (group of frames) length to 1. a GOP is a span of frames from one i-frame until the next, a GOP of 1 forces every frame to be an i-frame, which is best suited for slideshows where there's no correlation/motion between frames

>> No.68449260

ps. by i-frame i mean an intra-only frame, meaning a frame which uses only spatial references, not temporal, simply put, they're complete, still images

>> No.68449354

who knows how he did it, but you could easily write a one-liner to take chunks of the clips and incrementally decrease the quality then combine them again

>> No.68449408
File: 64 KB, 750x710, 1529029062235.jpg [View same] [iqdb] [saucenao] [google] [report]

I wish I wasn't a mong so I could understand what you're babbling about. But tl;dr -g 1 is hacker code for putting manga in a video file, ya?

>> No.68449452

WebP's compression is based on VP8, but they aren't the same. WebP is overall more efficient for images and in contrast to VP8 it allows lossless compression.
Also I'm pretty sure VP8 supports transparency, but the usage of an alpha channel conflicts with the alternate reference frame, so you have a less efficient compression.

>Force keyframe on each new page? Set frame rate to 1?
The command I used was
ffmpeg -pattern_type glob -framerate 1 -i "*.png" -c:v libvpx -g 1 -deadline best -b:v 1K out.webm
-b:v 1K only tells libvpx to use the lowest possible quality. I deleted chapters from the source directory until it fit the 3 MB limit.
>Can I ask, how does it compare in size to a zip folder of the PNG's?
Lossless optimized PNG (via ECT): 68.9 MB
Lossless WebP (-z 9): 56.4 MB
Lossless somewhat optimized FLIF: 45.0 MB
Lossless optimized PDF (via pdfsizeopt utilizing ECT): 69.7 MB
That's what I tested so far.

>> No.68449552

So flif is the best for lossless and webp the best for lossy?

>> No.68449553
File: 1.28 MB, 1920x1080, 1545261982222.jpg [View same] [iqdb] [saucenao] [google] [report]

This looks interesting.

I'll try it with some pleb software.

>> No.68449558

Gotcha, thanks
I thought you somewhat got around this by setting the framerate to 1fps, as I checked in VLC. Being able to set the GOP itself is quite nice, a very handy tool. Thanks for letting me know about it!

>> No.68449569

sure, why not.

>> No.68449572
File: 475 KB, 1920x1080, 1545261982222.webm [View same] [iqdb] [saucenao] [google] [report]


>> No.68449577

And the size of the smallest webm containing all the full set (not trimmed for 4chan?)
Just for something to compare those numbers to?

>> No.68449585

Yea just wondering how the code went but I guess I could figure it out for myself over the period of a few days.

>> No.68449747

Difficult to say. Most recent test I saw indicates that AVIF will beat FLIF.
As for lossy compression BPG produced better results than WebP in the past. I haven't seen any comparisons with v1.0.0 yet, but I doubt they improved that much.

Those numbers are already for the full set (116 images).

>> No.68449821

>flif average decoding time
wew lad

>> No.68449882

You'd figure a site that serves so much media content would be adopting tech that reduces bandwidth consumption and thus costs

but no, 4chan continues to ignore the existence of webp, vp9, and av1

>> No.68450021

>Those numbers are already for the full set (116 images).
Yeah, how big was the webm?
Ah, this one, >>68447034, right.
So 2.6MB compared to 70MB.
Not bad, but I'm kinda... eh, no.
I just checked a manga I had on hand, 48MB for 158 pages, so that's pretty good. Considering how readable >>68447034 is, you could easily shrink a hell of a lot of manga into a tiny size. Great for archiving or going innawoods, if you have a decent player.

>> No.68450327

if they gave much of a shit about bandwidth, they wouldn't allow 4MiB GIFs
gifs are great for tiny icon-sized, low-color animations, but if you're gif is anything close to 4MiB, you really shouldn't be using gif at all

>> No.68450670
File: 277 KB, 852x1200, 03_vp8.png [View same] [iqdb] [saucenao] [google] [report]

To be honest I don't see much of a use for it myself besides making manga sharing on 4chan easier. If you want something like this only for yourself you might as well stick with a more efficient video codec. VP8 is worse than H264 and especially HEVC at those low bitrates.

A quick comparison. Here's one image extracted from my WebM (2,766,675 bytes) via ffmpeg. This is an example where the compression actually interferes with the readability.

>> No.68450722
File: 264 KB, 852x1200, 03_hevc.png [View same] [iqdb] [saucenao] [google] [report]

And here's the same image but from a HEVC video (2,774,699 bytes).
Not every frame show this much of a quality gap, but they all look better to some degree.

>> No.68450827
File: 556 KB, 500x670, HitClips.png [View same] [iqdb] [saucenao] [google] [report]

I read through the entire webm, and actually decided to download all of Nagatoro because of it.
The only thing I couldn't read in the whole webm was that TL note, everything else was fine.
I think it's a great way to share manga on 4chan, if someone's all "Hey, what's (x) like?", you can just send them a chapter (And tell them to open it in VLC, pause, and press "e" to turn the page).
It's amazing, given you can share them on practically every board.
I'm reminded of hit-clips for some reason, just a small, easy to share snippet of a product.
(...I still wish manga was slightly easier to compress in original quality, tho. All my favorites alone take up a good 20GB+, I can easily get through 1GB of manga in a night or so, pretty easy to max out your phone's storage just for emergencies, thank god for 400GB microSD cards though (And old e-readers that used uSD cards for their internal storage). Still, a nice collection of manga can still take up 100GB. Getting that down to your 3MB/100 pages is quite nice).
(...There's so much fucking whitespace though, if only encoders knew how to properly do hard-interpolation like gif used to)

>> No.68450882

Holy fuck, that's amazing!
That text, even the TL note is totally readable, it's clear as day! This would be a fantastic way to crunch massive collections into hundreds of megabytes!
Forgive me if you've already posted it, but what command did you use to make that? All i've seen so far are your VP8 ones.

>> No.68451088
File: 297 KB, 852x1200, 116_hevc.png [View same] [iqdb] [saucenao] [google] [report]

Guess it's an advantage of only reading manga on your PC.
I store all the original images as FLIF on an external HDD and combine all volumes into PDF which I optimize lossy via Ghostscript.

ffmpeg -pattern_type glob -framerate 1 -i "*.png" -c:v libx265 -preset placebo -pix_fmt yuv420p10le -x265-params min-keyint=1:keyint=1 -b:v 155K ../out.mkv
Mind you I'm not an expert. I don't know how much 10-bit actually improves the compression in this scenario and I'm unfamiliar with x265's options. You might be able to get even better results buy tweaking the command.
And again this is one of the most impressive frames. You definitely notice the low file size in other instances.

>> No.68452750
File: 206 KB, 852x1200, 03_av1.png [View same] [iqdb] [saucenao] [google] [report]

Currently testing how AV1 compares to HEVC. With the fastest speed setting it looks unfortunately worse, so I guess I'll try the default one.
Also for anybody who might want to try libaom with ffmpeg: Single pass encoding seems to be broken and keep away from 10-bit.

>> No.68453754
File: 303 KB, 852x1200, 116_av1.png [View same] [iqdb] [saucenao] [google] [report]

For anyone interested:

>AV1 (3,076,199 bytes)
>HEVC (3,079,138 bytes)

Doesn't seem to be worth to switch to AV1 for this kind of stuff. At least not yet. >>68452750 is a bit better now, but still worse than with HEVC. In contrast >>68451088 looks better than the HEVC equivalent.
AV1 and HEVC merely prioritize different pictures/details at the moment, but at the cost of AV1 taking a LOT longer to encode.

>> No.68453919

So this is the fastest AV1 encode you mentioned before?
I don't think it's reliable when you compare it to the 'placebo' x265.
Still, it's a really cool idea to use them like this.

>> No.68453966

who came up with this? /sci/ helped solve math problems, is /g/ making innovations in computer science now?

>> No.68454020

No, the video in the link was done with the default speed (1 on a scale from -8 to 8; I guess the negative values are some special debug presets). The picture was also taken from the new video.

>> No.68454166

Oh, ok. I just thought it looks better than the image you posted earlier.
How about you do lossless encode and use some metrics to compare results?
i.e. for SSIM:
ffmpeg -i [copy] -i [source] -lavfi ssim -f null -

>> No.68454854

Sure thing. According to these results AV1 clearly beats HEVC. Please note that I didn't use any tune settings (x265 offers options to focus on maximizing PSNR or SSIM values; not sure about libaom).
PSNR y:27.452633 u:48.862176 v:47.756623 average:29.195611 min:26.988611 max:50.928418 -- HEVC
PSNR y:30.472774 u:47.937667 v:47.260415 average:32.191677 min:29.268025 max:36.347583 -- AV1
SSIM Y:0.931299 (11.630377) U:0.994943 (22.960695) V:0.994474 (22.575999) All:0.952436 (13.227178) -- HEVC
SSIM Y:0.952734 (13.254467) U:0.995114 (23.110493) V:0.994651 (22.717007) All:0.966783 (14.786419) -- AV1

>> No.68455211

Nice, it's good to know AV1 performs well despite being disastrously slow.
libaom has the following tune options:
--tune=<arg> psnr, ssim, cdef-dist, daala-dist
You can probably pass them to the ffmpeg. Actually i think that simple PSNR tuning could be the best for static images.
Also, is it necessary to put a keyframe for every image? Compression could be better without it...

>> No.68455737 [DELETED] 

>Also, is it necessary to put a keyframe for every image? Compression could be better without it...
No, but at least for WebMs on here it's a good quality control measure. If you can't fit the video within the 3MB limit then use less pages or the quality will suffer too much.
As for AV1 I think I'll just compile libaom directly and have direct control over it.

If someone's interested here are also VMAF scores
AV1 -- Aggregate (mean): VMAF_feature_adm2_score:0.977093, VMAF_feature_motion2_score:59.830835, VMAF_feature_vif_scale0_score:0.525919, VMAF_feature_vif_scale1_score:0.837412, VMAF_feature_vif_scale2_score:0.901192, VMAF_feature_vif_scale3_score:0.934960, VMAF_score:99.889811 -- AV1
HEVC -- Aggregate (mean): VMAF_feature_adm2_score:0.951309, VMAF_feature_motion2_score:59.830835, VMAF_feature_vif_scale0_score:0.467277, VMAF_feature_vif_scale1_score:0.770596, VMAF_feature_vif_scale2_score:0.843156, VMAF_feature_vif_scale3_score:0.889247, VMAF_score:99.928366 -- HEVC

>> No.68455757

>Also, is it necessary to put a keyframe for every image? Compression could be better without it...
No, but at least for WebMs on here it's a good quality control measure. If you can't fit the video within the 3MB limit then use less pages or the quality will suffer too much.
As for AV1 I think I'll just compile libaom directly and have direct control over it.

If someone's interested here are also the VMAF scores
AV1 -- Aggregate (mean): VMAF_feature_adm2_score:0.977093, VMAF_feature_motion2_score:59.830835, VMAF_feature_vif_scale0_score:0.525919, VMAF_feature_vif_scale1_score:0.837412, VMAF_feature_vif_scale2_score:0.901192, VMAF_feature_vif_scale3_score:0.934960, VMAF_score:99.889811 -- AV1
HEVC -- Aggregate (mean): VMAF_feature_adm2_score:0.951309, VMAF_feature_motion2_score:59.830835, VMAF_feature_vif_scale0_score:0.467277, VMAF_feature_vif_scale1_score:0.770596, VMAF_feature_vif_scale2_score:0.843156, VMAF_feature_vif_scale3_score:0.889247, VMAF_score:99.928366 -- HEVC

>> No.68457541
File: 1.21 MB, 603x699, punpun-contemplates.png [View same] [iqdb] [saucenao] [google] [report]

testing this >>68433574

>> No.68457556
File: 127 KB, 603x699, punpun-contemplates.webm [View same] [iqdb] [saucenao] [google] [report]


>> No.68458713
File: 67 KB, 982x1024, Michael-Scott-Sad-Face-Funny-Picture.jpg [View same] [iqdb] [saucenao] [google] [report]

Post the rest, I must know.

>> No.68460581
File: 2.65 MB, 960x1378, 1.webm [View same] [iqdb] [saucenao] [google] [report]


>> No.68460602
File: 2.89 MB, 960x1378, 2.webm [View same] [iqdb] [saucenao] [google] [report]

That's all I currently have on my PC.

>> No.68460725
File: 551 KB, 960x1378, Ijiranaide, Nagatoro-san - Vol.3 Ch.23.png [View same] [iqdb] [saucenao] [google] [report]

nanashi updated the last page from the beach chapter

Name (leave empty)
Comment (leave empty)
Password [?]Password used for file deletion.