Pixelart

>>1987498
>saw .gif
>mfw
>click on image
>ready to bate.jpg
>no animation
>gun in mouth

>>1987559
Dithering != pixel art

File: Dither example.gif (1MB, 3000x2000px) Image search: [Google]

1MB, 3000x2000px

>>1987731
Aw, really? But I just wrote a fun program to dither images! :-(

File: Dithering ultimate example 4MB.png (4MB, 5200x1034px) Image search: [Google]

4MB, 5200x1034px

>>1987872
https://en.wikipedia.org/wiki/Dither

File: 256.png (370KB, 885x1200px) Image search: [Google]

370KB, 885x1200px

>>1988359

File: 256.png (225KB, 707x1000px) Image search: [Google]

225KB, 707x1000px

>>1988366

File: 256.png (262KB, 708x1000px) Image search: [Google]

262KB, 708x1000px

>>1988367

File: 256.png (358KB, 800x1215px) Image search: [Google]

358KB, 800x1215px

>>1988368

File: 256.png (253KB, 800x1131px) Image search: [Google]

253KB, 800x1131px

>>1988371

File: 256.png (276KB, 800x1131px) Image search: [Google]

276KB, 800x1131px

>>1988373

File: 256.png (145KB, 560x802px) Image search: [Google]

145KB, 560x802px

>>1988375

File: 256.png (466KB, 1120x1426px) Image search: [Google]

466KB, 1120x1426px

>>1988376
Large blank spaces...

File: 256.png (194KB, 707x1000px) Image search: [Google]

194KB, 707x1000px

>>1988367
...I guess I have to compromise on my original goal of allowing error to propagate forward ad infinitum. :-(

Here, only two-thirds of the error is propagated forward.

>>1988388
Make a kernel that distributes error to all adjacent pixels.

File: you did nothing wrong.gif (15KB, 128x160px) Image search: [Google]

15KB, 128x160px

>>1987730
...and?

>>1987730
>Thinks GIF == multiple frames

Regardless, PNG is superior to gif compression-wise in almost all cases, especially for images that can be paletted.

>>1988733
It's really too bad that animation isn't a standard feature of PNG, which has lead to GIF living on for way too long. I hope FLIF can finally kill it.

>>1988766
there was the animated png, what happened to it
good look to this flif

>>1988832
Yeah, but APNG isn't a standard feature of PNG, it's an extension, and it has competed against MNG.

>>1988834
It took about 15 years for PNG to be widely accepted and used. FLIF will never get there, its advantage over PNG is marginal (and filesize is practically no consideration for still images anymore), whereas WEBM fulfills all the animation needs nowadays already.

The advantage over having both in a single new format is negligible.

>>1988839
>WEBM fulfills all the animation needs
It's neither supports transparency nor lossless compression, it's a fucking video format.

>>1988832
As always, Microsoft is a hold-out for making it a web standard (MSIE/Edge lacks support). Oddly Google is too (Chrome/Chromium requires a plugin which in the real world means unsupported). Mozilla products have had apng support since forever and Apple products have supported it for quite some time. Nothing really happened to apng but you can't just throw it on the web and expect more than a minority to see it.

>>1988846
Why would you even need transparency for animations?! And actually webm can be perfecty lossless with the right codec settings.

>>1988850
There's tons of GIFs and APNGs that use transparency.

>>1988839
>FLIF will never get there, its advantage over PNG is marginal
No. FLIF blows a PNG you've invested 40+ minutes and billions of cycles into optimizing, right out of the water, usually in under 5 - 10 seconds, if not instantly. Even if you have very fast and accurate heuristics for scanline filter selection, generating a decent DEFLATE stream takes time and trials of a number of methods. It's often hard to know which will converge the best.

Every system has an absolute minimum size required to represent a given set of information. I've found very few cases where a png (that's been practically brute forced), has been able to beat FLIF. Like I said above though, single frame GIFs are rarely capable of better compression than PNG. The script I made has a switch to try both when it receives such a gif, and in almost all cases, the PNG is better (relative to gifsicle -O3).

>>1989054
Wow, this is something I didn't expect on /e/!

>>1989054
Sure, FLIF is better but still only marginally (i.e. not an order of magnitude), and even then filesize is a non-issue nowadays with multi-TB disks and high-speed internet connections. Who cares if an image is 3 MB or 2.7 MB large?

Ease of use and compatibility are what matters, and FLIF has no advantages there over existing solutions.

Don't get me wrong, I love the idea of FLIF, and I wish it would've been invented 10 years ago to be able to make a difference. But I don't think it will ever be anything but a niche format.

>>1989108
>Sure, FLIF is better but still only marginally
This isn't the case. Run some tests. Make sure to always try interlaced, progressive is usually worse (inverse of PNG).

Especially on large images >~2000x2000. But on small image it still tends to be better by 10 - 25%.

>But I don't think it will ever be anything but a niche format.
Unfortunately, I'd have to agree. I don't see widespread adoption, nor support, happening soon if ever. Even when they come to v1.0, or some other arbitrary freeze where no changes are required in the decoder.

File: bb71edf681d829bc4e26433bfdfef046.gif (26KB, 180x240px) Image search: [Google]

26KB, 180x240px

This thread has taken an interesting path in life.

File: Faris-Berserker.png (768B, 32x48px) Image search: [Google]

768B, 32x48px

...

>>1992516
heh