Not backwards compatible I think
A new PNG spec
171–180 of 622 posts
Re: A new PNG spec
#172Earlier quoted context omitted.
> 5% of people can't view them, yet 25% of top websites use them? That's not how it works. The server declares what versions of media it has, and the client requests a supported media format. The same trick have been used for audio and video for ages too. Example:
This problem was solved by HTTP since forever. Client sends `Accept` header with supported formats and server selects the necessary content with corresponding `Content-Type` header. You don't need any HTML tags for it.
What about file extensions?
Re: A new PNG spec
#173Earlier quoted context omitted.
Overshadowed by CSS animations for almost all use cases.
But animated gradient outlines on text is the only use-case I care about.
"Use case" is written without hyphen https://en.m.wikipedia.org/wiki/Use_case
Re: A new PNG spec
#174Earlier quoted context omitted.
> Having an extensible format and electing never to extend it seems pointless. This proves OP analogy regarding USB-C. Having PNG as some generic container for lossless bitmap compression means fragmentation in libraries, hardware support, etc. The reason being that if the container starts to support too many formats, implementations will start restricting to only the subsets the implementers care about. For instance…
But where the analogy with USB-C is very good is that just like USB-C, there is no way for a user to tell from the look of the port or the file extension what the capabilities are. Which even for a fairly tech savvy user like me is frustrating. I have a bunch of cables, some purchased years ago, how do I know what is fit for what? And now think of the younger generation that has grown up with smartphones and have bee…
> there is no way for a user to tell from the look of the port or the file extension what the capabilities are
But that's typical for file extensions. Consider EXE – it is probably an executable, but an executable for what? Most commonly Windows – but which Windows version will this EXE run on? Maybe this EXE only works on Windows 11, and you are still running Windows 10. Or maybe you are running x86-64 Windows, but this EXE is actually for ARM or MIPS or Alpha. Or maybe it is for some other platform which uses that extension for executable files – such as DOS, OS/2, 16-bit Windows, Windows CE, OpenVMS, TOPS-10, TOPS-20, RSX-11...
.html, .js, .css – suggest to use a web browser, but don't tell you whether they'll work with any particular one. Maybe they use the latest features but you use an old web browser which doesn't support them. Maybe they require deprecated proprietary extensions and so only work on some really old browser. Maybe this HTML page only works on Internet Explorer. Maybe instead of UTF-8 it is in some obscure legacy character set which your browser doesn't support.
.zip – supports extensible compression and encryption methods, your unzip utility might not support the methods used to compress/encrypt this particular zip file. This is actually normal for very old ZIP files (from the 1980s) – early versions of PKZIP used various deprecated compression mechanisms, which few contemporary unzip utilities support. The format was extended to 64-bit without changing the extension, there's still a lot of 32-bit only implementations out there. ZIP also supports platform-specific file attributes–e.g. PKZIP for z/OS creates ZIP files which contain metadata about mainframe data storage formats, unzip on another platform is going to have no idea what it means, but the metadata is actually essential to interpreting the data correctly (e.g. if RECFM=V you need to parse the RDWs, if RECFM=F there won't be any)
.xml - okay, it is XML – but that tells you nothing about the actual schema. Maybe you were expecting this xml file to contain historical stock prices, but instead it is DocBook XML containing product documentation, and your market data viewer app chokes on it. Or maybe it really is historical stock prices, but you are using an old version of the app which doesn't support the new schema, so you can't view it. Or maybe someone generated it on a mainframe, but due to a misconfiguration the file came out in EBCDIC instead of ASCII, and your app doesn't know how to read EBCDIC, yet the mainframe version of the same app reads it fine...
.doc - people assume it is legacy (pre-XML) Microsoft Word: every version of which changed the file format, old versions can't read files created with newer versions correctly or at all, conversely recent versions have dropped support for files created in older versions, e.g. current Office versions can't read DOC files created with Word for DOS any more... but back in the 1980s a lot of people used that extension for plain text files which contained documentation. And it was also used by incompatible proprietary word processors (e.g. IBM DisplayWrite) and also desktop publishing packages (e.g. FrameMaker, Interleaf)
.xmi – I've seen this extension used for both XML Model Interchange (XML-based standard for exchanging UML diagrams) and XMIT (IBM mainframe file archive format). Because extensions aren't guaranteed to be unique, many incompatible file formats share the same extension
.com - is it an MS-DOS program, or is it DCL (Digital Command Language)?
.pic - probably some obscure image format, but there are dozens of possibilities
.img – could be either a disk image or a visual image, either way dozens of incompatible formats which use that extension
.db – nowadays most likely SQLite, but a number of completely incompatible database engines have also used this extension. And even if it is SQLite, maybe your version of SQLite is too old to read this file because it uses some features only found in newer versions. And even if SQLite can read it, maybe it has the wrong schema for your app, or maybe a newer version of the same schema which your old version that app doesn't support, or an old version of the schema which the current version of the app has dropped support for...
Re: A new PNG spec
#175Not backwards compatible. We just add it to that nice cupboard "great advanced image formats we will forget about". Society doesn't need a new image format. I'd wager to say not any new multimedia format. Big corporate entites do, and have churning them out at a steady pace. Look at poor webp - a format pushed by the largest industry players - and the abysmal everyday use it gets, and the hate it generates.
> Momentum built, and additional parties became interested. […] we had representation from […] Adobe, Apple, BBC, Comcast / NBCUniversal, Google, MovieLabs, and […] W3C
> Many […] programs […] already support the new PNG spec: Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer...
> Plus, you saw some broadcast companies in that list above. Behind the scenes, hardware and tooling are being updated to support the new PNG spec.
Re: A new PNG spec
#176Earlier quoted context omitted.
> and the abysmal everyday use it gets Estimates are that 95% of Internet users have a browser that supports WebP and that ~25% of the top million websites serve WebP images. I wouldn't call that abysmal.
Great, so I can download it, but then I have to convert it to a different format before half my apps will be able to use it.
Maybe the issue is with your operating system then?
Re: A new PNG spec
#177If you wanted better compression, it's called Lossless WEBP. Lossless WEBP is such a nice codec. Compared with Lossless JXL, it decompresses many times more quickly, and while JXL usually produces a smaller file, it doesn't always. Lossless AVIF is not competitive. However, lossless WEBP does not support indexed color images. If you need palettes, you're stuck with PNG for now.
And the JXL api is a nightmare, compared to WEBP.
Re: A new PNG spec
#178Not backwards compatible. We just add it to that nice cupboard "great advanced image formats we will forget about". Society doesn't need a new image format. I'd wager to say not any new multimedia format. Big corporate entites do, and have churning them out at a steady pace. Look at poor webp - a format pushed by the largest industry players - and the abysmal everyday use it gets, and the hate it generates.
> and the abysmal everyday use it gets Estimates are that 95% of Internet users have a browser that supports WebP and that ~25% of the top million websites serve WebP images. I wouldn't call that abysmal.
You can't even upload webp to instagram.
Re: A new PNG spec
#179So animated GIFs can be replaced by Animated PNGs with alpha blending with transparent backgrounds and lossless compression! Some nostalgia from 2000s websites can be revived and relived :) Curious if Animated SVGs are also a thing. I remember seeing some Javascript based SVG animations (it was a animated chatbot avatar) - but not sure if there is any standard framework.
both GIF and PNG use zipping for compressing data, so APNG are not much better than GIF
(A)PNG supports semi-transparency. In GIF a pixel is either full transparent or full opaque.
Also while true color gifs seem to be possible it is usually limited to 256 colors per image.
For those reasons alone APNG is much better than GIF.
Re: A new PNG spec
#180> I know you all immediately wondered, better compression?. We're already working on that. This worries me. Because presumably, changing the compression algorithm will break backwards compatibility, which means we'll start to see "png" files that aren't actually png files. It'll be like USB-C but for images.
Old PNGs will work just fine. And forward compatibility is much less important. The main use case for PNG is web browsers and all of them seem to be on board. Using old web browsers is a bad idea. You do get these relics showing up using some old version of internet explorer. But some images not rendering is the least of their problems. The main challenge is actually going to be updating graphics tools to export the…
>The main use case for PNG is web browsers
This is news to me. I'm pretty sure the main use case for PNG is lossless transparent graphics.