Currently there are no browsers that have native FLIF support

Not op but just search some nep r34 and you're bound to find it.

>Why does nobody support our compression systems that can barely compete with fucking JPEG
Because cost of creating renderer for them outweighs the benefits.

I don't think ImageMagick does support it. I just tried.

convert in.png -format flif out.flif

does nothing. if you specify webp as the format then it works.

chan.sankakucomplex.com/post/show/7365737
here sir

>Currently there are no browsers that have native FLIF support.
Not surprising. The codec is still in its early stages (not only encoding, also decoding performance is an issue) and unlike WebP there's no company behind to push the shitty pre-1.0 versions.

For lossless images
>FLIF for best compression
>WebP for best compression/speed
>PNG for best compatibility
Not sure about lossy images. There are so many lossy image formats that never made a breakthrough and I haven't tested half of them. JPEG 2000, JPEG XR, BPG, Pik, ...
I just know WebP isn't that good when it comes to lossy compression, as it's optimized to produce good PSNR values and is prone to get rid of fine details.

>how?
If I remember right you'd have to compile it with FLIF support
>and after that, how do you view it? feh?
ImageMagicks display command. Alternatively the FLIF repo comes with the code for a gdk-pixbuf-loader, so any image viewer based on it should be able to view them (unless you're using proprietary Nvidia drivers; there's a bug that'll prevent you from decoding FLIF).

Not what i hoped for but thank you anyway good sir!

ah my good sir why don't you fuck off back to plebbit. *Tips fedora*

>Not sure about lossy images
lossy images go straight to the trash

Attached: 1548067808141.png (861x889, 853K)

>Why would anybody want to add browser support for a meme image format that kills your CPU?
It shouldn't kill your CPU? OP said encoding was slow, but arguably that is common for new codecs no matter what, and images aren't an actually tough challenge because you rarely need to encode tens of thousands like with video frames.

>so what format should I use? WebP?
Not for anything you post on the web, because:

youtube.com/watch?v=IheZzcYUV9w

>CPU usage spikes when use XnView to view FLIF image.

That's probably just XnView, yes? Even Javascript rendering of flif for browsers that otherwise don't support it isn't too horribly taxing.

Same artist as OP BTW.

Attached: 295df305440caf6dd95d33c4f260945a811e71933edc4b49e8b5b2fa3c04fe18.jpg (1200x1200, 595K)

for file in *.png ; do cwebp -z 9 -m 6 -q 100 -mt -lossless "$file" -o "${file%.png}.webp"; done
for file in *.jpg ; do cwebp -z 9 -m 6 -q 100 -mt -noalpha "$file" -o "${file%.jpg}.webp"; done

reminder to hit the feedback page once a day requesting webp support

how to flif on debian ?

>Currently there are no browsers that have native FLIF support.
True, but the polyfill works.
>And FLIF is very slow at encoding, atleast x100 slower than WEBP.
It hasn't been optimized like popular encoders have. Besides, high-compression encoders for popular formats like ZopfliPNG and MozJPEG already take a long time. Even the encoder ends up being 20x slower after optimization, that's something you can live with. It's a small price to pay for FLIF's main advantage: LOSSLESS FUCKING EDITING OF LOSSY IMAGES. That is a huge deal. If successful, FLIF will do more for the preservation of content on the Internet than any format since 1996.

Post a better image viewer.

Now that's some generation loss.

Attached: jpeg strongest.jpg (400x412, 6K)

>ZopfliPNG and MozJPEG
Nobody cares.

>LOSSLESS FUCKING EDITING OF LOSSY IMAGES. That is a huge deal.
Nobody cares.

WebM

Attached: generation-loss.webm (960x540, 2.95M)

-z 9 is equivalent to -m6 -q 100 -lossless

oops

>JPEG 2000
Has the ugliest artifacts in existence. Fuck spline "ringing".

Attached: Comparison_between_JPEG,_JPEG_2000_and_JPEG_XR.jpg (1600x480, 299K)

To be fair, those videos are pretty outdated. Nowadays WebP's generation loss mostly fucks with colors.

Attached: WebP_Comparisons.png (1920x1025, 1.73M)

>>ZopfliPNG and MozJPEG
>Nobody cares.
They should.

Attached: Generation loss at quality 97 or higher-w7vXJbLhTyI.webm (854x480, 2.92M)

Here is my test using "Save as" method.

Attached: FLIF generation loss.png (2100x960, 1.73M)

Thanks!

Here's one more at high quality settings, webp destroys the image again though:
youtube.com/watch?v=w7vXJbLhTyI

nobody cares about your meme format

WEBP version.

Attached: WEBP generation loss.png (2100x960, 895K)

>LOSSLESS FUCKING EDITING OF LOSSY IMAGES
Yes, but that's not some great innovation. It's the result of FLIF being inherently lossless.
Also it's possible to edit JPEG to some extent without introducing further losses.

>ORIGINAL PNG 8MB
may as well use BMP instead, if you're gonna use PNG as a bitmap format without compressing

>Yes, but that's not some great innovation. It's the result of FLIF being inherently lossless.
No shit, Sherlock.
>Also it's possible to edit JPEG to some extent without introducing further losses.
Yes, you can rotate and crop whole images losslessly and do so color adjustment. You can also edit parts of a JPEG and only recompress them, but the quality will still suffer in those parts.

They like Windows Photo Viewer and don't want to use a "special viewer".

Attached: NEW IMAGE FORMAT vs NORMIES.png (862x919, 80K)

>No shit, Sherlock.
Then you should know that it's not as big of a deal as you make it out to be.

It is a big deal because it's a lossless format developed together with a lossy encoder.

"lossless" as in raster perfect or """""lossless""""" as in "you can't tell the difference"?

The format is raster perfect.

Tried my hand at doing this to the OP image for 1000 generations with cwebp 0.6.1. This is generation 1000. From left to right: q=25,m=4; q=25,m=6; q=90,m=4; q=90,m=6. I'm encoding a video right now.

#!/bin/sh
method=6
quality=90
output_prefix="q$quality-m$method/"
generations=1000

encode() {
cwebp -mt -m "$1" -q "$2" "$3" -o "$4"
}

input="$1"
for i in $(seq 1 "$generations")
do
output="$output_prefix$(printf "%05u.webp" "$i")"
encode "$method" "$quality" "$input" "$output"
input="$output"
done

Attached: 01000.png (1200x900, 1.01M)

PNG

Everything else exists only to depreciate older OSes and software to get people to upgrade to the latest botnet versions.

Attached: 1437236096962.jpg (600x600, 199K)

>depreciate older OSes
Such as?

Done. 1 frame = 1 generation. Most of the action happens in the first 3 seconds.

Attached: loss.webm (1200x900, 2.83M)

Attached: original.png (300x900, 264K)

can you test with this image and see if the format holds up on tiny details or if it just blurs it out like a motherfucker?

Attached: test1.png (400x400, 161K)

Okay. Not doing the different methods, though.

Literally anything that needs to upgrade or use a plugin to use any new standard.

Thank for the video, user.

If there's going to be generation loss, it's gonna happen within the first 5 generations anyway

WebP q90 looks good desu.

You're welcome!

Here it is.

You are right. Most of it happens very rapidly. It looks to be pointless to go beyond 100 generations. However, I've 1000 again for the sake a fair comparison with .

Attached: test.webm (800x400, 1.43M)

The first 10 generations.

Attached: first10.png (800x4000, 2.97M)

Attached: 01000.png (800x400, 308K)

yeah, neighboring areas with similar chroma get smudged together even if there's a high contrast ledge between them
terrible fucking artifacting
Thanks for the tests

Forgot to say that the left is q=25,m=6 and the right is q=90,m=6.

You are also welcome, user.

I don't think I need FLIF after this video

How does it compare to avif?

>avif
who?

What the video doesn't show is what happens if you edit the image between the reencodings.

>edit the image between the reencodings
No thanks.
I'm not that retard.

This isn't about you, user. Most JPEG recompression probably happens due to clueless, careless users.

>clueless, careless users
They deserve it.

Ga weg jon

It is not just they who suffer for it. OC gets preserved in degraded quality because the only surviving copy is the one some idiot recompressed. Separating the compression from the quality reduction would in large part solve this problem.

>OC gets preserved in degraded quality because the only surviving copy is the one some idiot recompressed.
the issue at hand is people not really giving a shit before the content is lost, not that the content's only surviving iteration is a second generation 4:2:0 80q jpg.

Sure, but the big difference between people and technology is that you can fix technology.

>you can fix technology
History teaches us that you need to burn it to the ground before you can rebuild it

Attached: 1549218554747.png (500x700, 207K)

I don't want to fix technology for shitposters who like to do JPEG recompression.
Pic related is an example.

Attached: 1464819568425.jpg (653x726, 67K)

Testing this. I am going to superimpose this mask over the image from every time it is saved.

Attached: mask.png (300x900, 21K)

So what the fuck do I even use form my gimp?

Attached: he who hides behind the wall.jpg (170x392, 20K)

Currently testing with v1.0.2. 80 generations in with -m 6 -q 25 and my results already look worse than yours.

#!/bin/bash

# First lossy encode
cwebp -m 6 -q 25 -mt input.png -o 1.webp

for input in {1..999}
do
(( output = input + 1 ))
cwebp -m 6 -q 25 -mt ${input}.webp -o ${output}.webp
done

Gonna post results once done.

The AV1-based image format.

Left is the original, right is WebP after 1000 generations (-m 6 -q 25).

Attached: m6q25.png (680x885, 523K)

The biggest losses happen during the first 5 seconds (= 125 generations).

Attached: m6q25.webm (340x885, 1.01M)

Done. The result after 200 generations is better than I expected. Again, the left image
is q=25,m=6 and the right is q=90,m=6.

#!/bin/sh
method=6
quality=90
output_prefix="q$quality-m$method/"
generations=500

encode() {
cwebp -mt -m "$1" -q "$2" "$3" -o "$4"
}

input="$1"
for i in $(seq 1 "$generations")
do
output="$output_prefix$(printf '%05u.webp' "$i")"
composite -gravity center mask.png "$input" temp.png
encode "$method" "$quality" temp.png "$output"
input="$output"
done

Attached: 00200.png (600x900, 541K)

>AV1
DOA

Now, the video.

Weird. Maybe the meaning of the quality settings has changed between the versions?

Attached: text mask.webm (600x900, 2.66M)

Mask and no mask after 200 generations. The quality is, again, q=25 and q=90 with m=6. Aside from the discoloration around the text, the masked images are not very significantly worse at q=90.

Attached: mask-no mask.png (1200x900, 1.16M)

This is what I get when I run your script.

Attached: 1000.png (300x900, 246K)

q=0, 200 gens (didn't want to wait).

Attached: 200.png (300x900, 217K)

What size does your 1000th WebP have? Mine's 152.8KB. Perhaps they made the quality parameter more aggressive when it comes to saving file size.

Why should there be? We already have webp.
This useless forcing of different open standards is dumb, people develop them anyways, there's no need for competition, it's only going to hurt the user.

Attached: 1551127257344.png (1267x785, 97K)

>Mine's 152.8KB
8.4 KB. Are you compressing the whole image? My input is the crop I posted in .

We also have JPG and PNG, webp just isn't a standard at all

Yeah. That's the difference. I downloaded the picture in and cropped my results.

Webp is supported in browsers and operating systems.

>people still use webp codecs from 2009 just so they can pretend it's bad

Attached: Laughing Whore.jpg (762x900, 161K)

Sorta. Appleshit and Firefox Mobile still can't handle it. Are there any imageboards that allow WebP yet?
caniuse.com/#feat=webp

libwebp 1.0.0 came out in April 2018.

>taking the word of someone

What is this software?

Well, I made so I'm pretty sure it's true.

The video is from 2016, but it doesn't state the version of libwebp.

How convenient. Does your dad work at Nintendo too?