FLIF

FLIF support in browsers when?
FLIF support on Sup Forums when?

flif.info/

Other urls found in this thread:

nikkhokkho.sourceforge.net/static.php?page=FileOptimizer
github.com/FLIF-hub/flifcrush
twitter.com/AnonBabble

>it outpreforms...
>lossless
>lossless
>lossless
>lossless

So what about lossy algorithms?
If you think lossy encoding isn't necessary then you're supremely retarded.

It's not meant to compete with lossy formats and of course they will produce smaller files above all else.

Have a better preforming lossless format is still worth going for and there a lots of cases where using a lossy format is not optimal like line art images.

FLIF also has a pseudo lossy mode that is still quite good.

Even that's outdated

We have made better formats than PNG and JPG. About a dozen different times

These formats are hilariously outdated

We just continue to use them for the sake of ubiquity

Outside of webm there aren't many gains to be made by supporting the newer formats.

Even using a 10% more efficient format is not exactly trivial when you consider the thousands of images and bytes served on this site alone let alone everywhere else.

There's no gains to be made by the internet supporting an image format that's 50% faster? You're a fucking idiot

Images are a standard method of communicating that exist anywhere and everywhere on the internet. How many petabytes of redundant data a day could be trimmed down?

No one is going to bother converting all of their images, and server side conversation is just lol. Drawing a line in the sand and forcing VP9 WebMs would be okay though.

Yeah it'll take a while

I'll produce enough discerning jew and cuck memes as I can to catalyse the process

Not until major web browsers support it. (Never)
Hell, VP9 is STILL not supported on Sup Forums even though most browsers can play it natively. You can thank Apple for that.

>No one is going to bother converting all of their images

Why not? I would do it to all of my images to save a rather large amount of space.

Do you brute force all your png files to save space as it is now?

Yes.

I do too.
What chain?
I just use this guys program nikkhokkho.sourceforge.net/static.php?page=FileOptimizer

I've yet to see any better chain in terms of file size.

Just converted a set of 2.2k pngcrushed assets to FLIF using the maximum compression options in the tool and got an overall reduction of less than 5% of file size in exchange for apparently slower decode times. In the trash the meme format goes.

Whoops, was looking at disk size. Overall reduction was 12% not 5%. Largest file got reduced from 214K to 158K, smallest from 132 to 51. At least one file got reduced by 60%.

pngcrush (default): 10 secs, 100% size
FLIF (-E100): 26 secs, 89.2% size
pngcrush (-brute): 230 secs, 99.9% size

I'm sorry I called you a meme FLIF.

Is it created by a big company?
Is it endorsed by a big company?
Is there a big enough demand for it that inferior formats can't fulfill?
Is there a political incentive for any vendor to support it?

The answer to all of these questions is "No" for FLIF, and that's why you'll never get native support for FLIF.

People are barely settling into WebP being the new kid on the block, and FLIF doesn't have a significant enough advantage to convince vendors to switch.

Try flifcrush

github.com/FLIF-hub/flifcrush

>it's another meme format thread once again

Picked some random files (the source images are mostly low color pixel artwork):

9.5 seconds to crush a 56x54, 407 byte PNG file. (6.35% reduction over flif -E100)

91 seconds to crush a 104x120, 5939 byte PNG file. (23.34% reduction over flif -E100)

425 seconds to crush a 145x290, 25.4KB PNG file. (0.77% reduction over flif -E100)

Pulled the plug on crushing a 1730x406, 214KB PNG file after 10 minutes. (it just spat out a larger file)

While I'm sure there's some potential, I won't be able to get a result before the thread is long dead. Doesn't seem to be any options on flifcrush to make any speed trade-offs, and I'd estimate this would take ~12 hours to run over all of the images. Seems to work decent and "fast" on some of the smaller images. I'll try take a random subset of images that I can complete in an hour and report back.

I tested decode speed and my rough and probably wrong test showed ~1.6x slower for the flif reference implementation to convert FLIF to PNM, vs imagick to convert PNG to PNM (PNG was 20x slower than imagick PNM to PNM). I think the "slow decoding" excuse was overblown too.

After 45 files. Can't stick around until the end right now.

388 bytes: E100=83.76% crush=68.81%
6586 bytes: E100=160.58% crush=123%
276 bytes: E100=60.87% crush=52.54%
2981 bytes: E100=129.05% crush=86.65%
1248 bytes: E100=81.25% crush=72.44%
318 bytes: E100=62.89% crush=60.38%
158 bytes: E100=65.19% crush=33.54%
311 bytes: E100=68.81% crush=54.34%
295 bytes: E100=57.63% crush=52.88%
1509 bytes: E100=105.24% crush=77.6%
286 bytes: E100=60.84% crush=52.45%
511 bytes: E100=103.72% crush=91.59%
897 bytes: E100=82.72% crush=76.03%
743 bytes: E100=70.66% crush=69.04%
8898 bytes: E100=125.03% crush=101.66%
273 bytes: E100=60.44% crush=54.95%
329 bytes: E100=64.74% crush=59.27%
185 bytes: E100=52.97% crush=35.14%
905 bytes: E100=91.6% crush=83.54%
487 bytes: E100=75.77% crush=69.61%
272 bytes: E100=61.03% crush=51.84%
2442 bytes: E100=104.71% crush=93.9%
7697 bytes: E100=104.21% crush=94.74%
211 bytes: E100=47.39% crush=37.44%
3216 bytes: E100=140.42% crush=117.91%
2936 bytes: E100=92.37% crush=75.68%
2738 bytes: E100=100.58% crush=79.8%
205 bytes: E100=50.73% crush=32.68%
190 bytes: E100=67.37% crush=55.26%
660 bytes: E100=78.03% crush=69.55%
885 bytes: E100=110.28% crush=81.47%
345 bytes: E100=66.09% crush=59.13%
501 bytes: E100=66.47% crush=59.88%
3054 bytes: E100=127.41% crush=93.45%
204 bytes: E100=69.61% crush=60.78%
209 bytes: E100=68.9% crush=40.67%
289 bytes: E100=64.01% crush=57.09%
2839 bytes: E100=119.3% crush=74.39%
1199 bytes: E100=79.82% crush=73.81%
4084 bytes: E100=106.39% crush=82.3%
513 bytes: E100=56.14% crush=46.39%
201 bytes: E100=59.7% crush=41.79%

Number of images: 100

Directory sizes:
225,674 source/ [100%]
224,634 pngcrush_brute/ [99.5%]
223,603 optipng_o7/ [99.1%]
248,542 flifE100/ [110.1%]
199,735 flifcrush/ [88.5%]

flifcrush totalled ~5.6 hours of CPU time
pngcrush and optipng totalled 10-20 seconds each
Why do `optipng` and `pngcrush -brute` suck? How do I make them try harder?

Source bytes/sec/core processed: 7.6 ~ 19.2 (i5-6500)
(few bigger files went slower than many small ones, I think)

Smallest 5 source files:
158 bytes: E100=65.19% crush=33.54%
185 bytes: E100=52.97% crush=35.14%
190 bytes: E100=67.37% crush=55.26%
197 bytes: E100=49.24% crush=40.61%
201 bytes: E100=59.7% crush=41.79%


Small files seem to have huge savings due to a smaller header. Not a great comparison.

Biggest 5 source files:
8373 bytes: E100=111.37% crush=103.94%
8898 bytes: E100=125.03% crush=101.66%
11796 bytes: E100=147.69% crush=96.92%
12675 bytes: E100=105.21% crush=70.35%
28502 bytes: E100=70.79% crush=69.43%

Flif (especially -E100) doing really badly on a lot of the larger files:

05130e07e4ef5ff2.png: 128x144
4254 bytes: E100=172.92% crush=128.3%
066064500759e2a3.png: 1280x32
6586 bytes: E100=160.58% crush=123%
1fb97ea0b9131086.png: 800x75
2981 bytes: E100=129.05% crush=86.65%
2d04ec2573203756.png: 960x32
3649 bytes: E100=157.14% crush=142.15%
4acc40238fd89802.png: 608x38
2296 bytes: E100=169.03% crush=124.7%
4ce83ea3202b147b.png: 736x46
2142 bytes: E100=202.61% crush=136.41%
4d965ee130f54fac.png: 1920x125
11796 bytes: E100=147.69% crush=96.92%
52947f6455c00913.png: 384x124
8898 bytes: E100=125.03% crush=101.66%
54f4d64ccc948c4a.png: 576x32
1903 bytes: E100=131.9% crush=110.04%
6f2d7b875d79cb39.png: 480x55
1485 bytes: E100=134.28% crush=113.87%
75a584bbe7fc98f2.png: 288x80
8070 bytes: E100=156.38% crush=125.38%
83e55d763940bc50.png: 485x119
6807 bytes: E100=227.81% crush=137.45%
8dee60b6524b15c8.png: 448x32
3216 bytes: E100=140.42% crush=117.91%
9bdb440bf3024a66.png: 576x36
1606 bytes: E100=155.17% crush=119.36%
afa9691b85818f99.png: 83x168
3974 bytes: E100=159.44% crush=133.44%
c11801cf4b9dd1f8.png: 64x200
3054 bytes: E100=127.41% crush=93.45%


Attached the image FLIF did the worst on.

Images under 1024 bytes:
51 files, 21,017 source bytes
E100: 71.12% crush: 61.03%


Images over 1024 bytes:
49 files, 200,657 source bytes
E100: 114.32% crush: 91.06%


Overall compression ratio when larger FLIF files are ignored:
E100: 89.82% crush: 82.21%

Overall compression ratio of files over 1024 bytes when larger FLIF files are ignored:
E100: 91.83% crush: 84.43%

Gimmick

Interesting. I what it is struggling with in those images.

Shrug. I started converting the entire set now.

Other than wishy-washy "deflate might just be better at certain patterns", most of these images are very low color and are encoded using PNG palettes. If FLIF is compressing 32-bit RGBA, then that could explain why it does worse by so much. Attaching the actual worst performing FLIF conversion which is even a completely different style of image.

Elapsed time: 2 hours, 57 minutes, 16 seconds
Estimated completion: 4.62%
Estimated time remaining: approx. 57 - 69 hours

Converted: 204 / 2,330 files
PNG Size: 397,053 bytes / 8,597,142 bytes
FLIF Size: 349,582 bytes (88.04%)
Best Size: 319,315 bytes (80.42%)

Estimated FLIF Size: 7,569,282 bytes
(-1,027,860 bytes saved)

Estimated Best Size: 6,913,929 bytes
(-1,683,213 bytes saved)


That's a reasonable improvement for "best size", meaning I'm going to embed a FLIF decoder in a game engine, and serve up the smallest format (either PNG or FLIF), so that's one more application of FLIF in the world. The numbers keep improving as it goes so a reduction of 25% on this specific set of images might be reached. Not bad, but I really feel like I didn't use pngcrush/optipng correctly for true optimization.