[pornel]

PNG is not a format for uncompressed or RLE "hello worlds". It's a format designed for the Web, so it has to have a decent compression level. Off-the-shelf DEFLATE implementations were easily available since its inception.

I think it is pretty pragmatic and relatively simple, even though in hindsight some features were unnecessary. The CRC was originally a big feature, because back then filesystems didn't have checksums, people used unreliable disks, and FTPs with automatic DOS/Unix/Mac line ending conversions were mangling files.

PNG could be simpler now if it didn't support 1/2/4-bit depths, keyed 1-bit alpha for opaque modes, or interlacing. But these features were needed to compete with GIF on low-memory machines and slow modems.

Today, latest image formats also do this competition of ticking every checkbox to even worse degree by adding animation that is worse than any video format in the last 20 years, support all the obsolete analog video color spaces, redundant ICC color profiles alongside better built-in color spaces, etc. By modern standards PNG is super simple.

[PaulHoule]

There was talk about upgrading PNG to support the equivalent of animated GIFs but it never really happened because of complexity, see

https://en.wikipedia.org/wiki/Multiple-image_Network_Graphic...

As for color spaces that is a case where things get worse before they get better. In the 1990s I remember the horror of making images for the web with Photoshop because inevitably Photoshop would try some kind of color correction that would have been appropriate for print output but it ensured that the colors were wrong every time on the screen.

Today I am seeing my high color gamut screen as a problem rather than a solution because I like making red-cyan anaglyph images and found out that Windows makes (16,176,16) when I asked for (0,180,0) because it wants to save my eyes from the laser pointer green of the monitor by desaturating it to something that looks like sRGB green to my eyes, but looking through 3d glasses it means the right channel blends into the left channel. To get the level of control I need for this application it turns out I need to make both sRGB and high gamut images and display the right one... Which is a product of the complexity of display technology and how it gets exposed to developers.

[edflsafoiewq]

Animated PNGs eventually did quietly happen in the form of APNG.

https://en.wikipedia.org/wiki/APNG

[Jasper_]

> There was talk about upgrading PNG to support the equivalent of animated GIFs but it never really happened because of complexity

This was mostly due to overengineering on the part of the PNG committee. Why stop at animated PNGs, when we could support sound and interactivity! MNG is not a simple format, and the spec has MNG-LC ("low complexity") and MNG-VLC ("very low complexity") subsets, because the whole thing is too complex. Did you know you can embed JPEGs in MNGs? That it has synchronization points for sound, even though sound is still "coming at a later date"? That it allows pasting other images into the movie at arbitrary 2D transforms?

MNG's complexity is self-inflicted, because they second-system effect'd their way into features nobody wanted.

APNG, by contrast, is a series of PNG chunks with a couple extra fields on top for timing and control information.

[jcelerier]

> Today, latest image formats also do this competition of ticking every checkbox to even worse degree by adding animation that is worse than any video format in the last 20 years,

yet just seeking in any random vpX / h26x / ... format is A PITA compared to trusty old gifs. it's simple, if you cannot display any random frame N in any random order in constant (and very close to zero) time it's not a good animation format

[edflsafoiewq]

You can't do that for GIF. Each frame can be composited on top of the last frame (ie. no disposal; this allows storing only the part that changed), so to seek to a random frame you may need to replay the whole GIF from the start.

The reason you can seek to any frame is GIFs tend to be small, so your browser caches all the frames in memory.

[pornel]

GIF has no seeking at all. It's entirely sequential, requires single-threaded decoding start to finish.

OTOH every video format has keyframes, is more friendly to post-90s CPUs, and recent formats are parallelizable.

You have only been able to notice how "heavy" VPx is because lengths and resolutions used with this format are way beyond GIFs capabilities.

Try encoding a mere 10-minute 30fps 1080p video in a GIF, I dare you.

[thrashh]

That’s not a format problem so much as a viewer software problem