> 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.
Can't you improve a compression algorithm and still produce a still valid decompression input? PNG is based on zip, there's certainly ways to improve zip without breaking backwards compatibility.
That being said, they also can do dumb things however, right at the end of the sentence you quote they say:
> Can't you improve a compression algorithm and still produce a still valid decompression input? PNG is based on zip, there's certainly ways to improve zip without breaking backwards compatibility.
That's just changing an implementation detail of the encoder, and you don't need spec changes for that e.g. there are PNG compressors which support zopfli for extra gains on the DEFLATE (at a non-insignificant cost). This is transparent to the client as the output is still just a DEFLATE stream.
Better compression can also mean a new set of filter methods or a new interlacing algorithm. But yeah, any of them would cause an instant incompatibility. As noted in the relevant issue [1], we will need a new media type at the very least.
I don't see why? If your video output is plain old RGB (like the Amiga hardware), then an unmodified decoder will handle new files without a problem. You only need a new decoder if your video output can handle more vivid colours than RGB can express.
An image decoded in the wrong colour space for the output will look wrong. It is not using extra bits to express the increased dynamic range: the existing numeric range is stretched and warped.
It has fields to say what compression is used. Adding another compression form should be handled by existing software as recognizing it as a valid PNG that they can't decompress.
The PNG format is specifically designed to allow software to read the parts they can understand and to leave the parts they cannot. Having an extensible format and electing never to extend it seems pointless.
> 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, almost nobody fully implements MPEG-4 Part 3; the standard includes dozens of distinct codecs. Most software only targets a few profiles of AAC (specifically, the LC and HE profiles), and MPEG-1 Layer 3 audio. Next to no software bothers with e.g. ALS, TwinVQ, or anything else in the specification. Even libavcodec, if I recall correctly, does not implement encoders for MPEG-4 Part 3 formats like TwinVQ. GP's fear is exactly this -- that PNG ends up as a standard too large to fully implement and people have to manually check which subsets are implemented (or used at all).
JPEG is no different. Only the decoder is specified. As long as the decoder decodes what you give it to the image you wanted to see, you can implement anything. This is how imgoptim/squash/aerate/dietJPG works. By (ab)using this flexibility.
Same is also true for the most advanced codecs. MPEG-* family and MP3 comes to my mind.
Nothing stops PNG from defining a "set of decoders", and let implementers loose on that spec to develop encoders which generate valid files. Then developers can go to town with their creativity.
Video files aren't a good analogy. Before God placed VLC and ffmpeg on earth, you had to install a galaxy of codecs on your computer to get a chance to read a video file and you could never tell exactly what codec was stored in a container, nor if you had the right codec version. Unfortunately there is no vlc and ffmpeg for images (I mean there is, the likes of imagemagick, but the vast majority of software doesn't use them).
I lived through that era (first K-Lite Codec Pack, then CCCP came along), but still it holds.
Proprietary or open, any visual codec is a battleground. Even in commercial settings, I vaguely remember people saying they prefer the end result of one encoder over another, for the same video/image format, not unlike how photographers judge cameras by their colors.
So maybe, this flexibility to PNG will enable or encourage people to write better or at least unorthodox encoders which can be decoded by standard compliant ones.
I honestly don't see an issue with the mpeg-4 example.
Regarding the potential for fragmentation of the png ecosystem the alternative is a new file format which has all the same support issues. Every time you author something you make a choice between legacy support and using new features.
From a developer perspective, adding support for a new compression type is likely to be much easier than implementing logic for an entirely new format. It's also less surface area for bugs. In terms of libraries, support added to a dependency propagates to all consumers with zero additional effort. Meanwhile adding a new library for a new format is linear effort with respect to the number of programs.
I never once in 25 years encountered an issue with an mp4 Container that could Not be solved by installing either the divx or xvid codec. And I extensively used mp4's metatdat for music, even with esoteric Tags.
He's saying that in 25 years, you used only the LC and HE profiles, and didn't encounter TwinVQ even once. I looked at my thousand-odd MPEG-4 files. They're overwhelmingly AAC LC, a little bit of AAC LC SBR, no TwinVQ at all.
If you want to check yours: mediainfo **/*.mp4 | grep -A 2 '^Audio' | grep Format | sort | uniq -c
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 been trained to not even know what a file is. I remember this story about senior high school students failing their school tests during covid because the school software didn't support heif files and they were changing the file extension to jpg to attempt to convert them.
I have no trust the software ecosystem will adapt. For instance the standard libraries of the .net framework are fossilised in the world of multimedia as of 2008-ish. Don't believe heif is even supported to this day. So that's a whole bunch of code which, unless the developers create workarounds, will never support a newer png format.
> 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 ...
Way back when, my prof was using his Linux machine to demonstrate how to use GCC. He called the end result .exe but that might have been for the benefit of the Windows users in the room. (Though Linux users being considerate to Windows users, or vice versa, is admittedly a rarity)
Prior to Windows 95, the vast majority of PC games were MS-DOS exe files – so anyone who played any of those games (whether back in their heyday, or more recently through DOSBox) has run an MS-DOS exe. Most people who ever used Lotus 1-2-3 or WordPerfect were running an MS-DOS exe. Both products were eventually ported to Windows, but were far less popular under Windows than under DOS.
Under Windows 95/98/Me, most command line tools were MS-DOS executables. Their support for 32-bit Windows console apps was very poor, to the extent that the input and output of such apps was proxied through a 16-bit MS-DOS executable, conagent.exe
First time in my life I ever used GNU Emacs, it was an OS/2 exe. That's also true for bash, ls, cat, gcc, man, less, etc... EMX was my gateway drug to Slackware
> Has anyone ever used .exe for anything other than Windows?
Did you know that Microsoft Windows originally ran on top of the much older MS-DOS, which used EXE files as one of its two executable formats? Most Windows users had lots and lots of EXE files which were not Windows executables, but instead DOS executables. And then came Windows 95, which introduced 32-bit Windows executables, but kept the same file extension as 16-bit Windows executables and 16-bit DOS executables.
What about an extensible format that would have as part of header an algorithm (in some recognized DSL) of how to decompress it (or any other step required for image manipulation)? I know its not so much about PNG but some future format.
That's what I would call really extensible, but then there may be no limits and hacking/viruses could have easily a field day.
> What about an extensible format that would have as part of header an algorithm (in some recognized DSL) of how to decompress it (or any other step required for image manipulation)?
Will sooner or later be used to implement RCEs. Even if you could do a restriction as is done for eBPF, that code still has to execute.
> Adding another compression form should be handled by existing software
In an ideal world, yes. In practice however, if some field doesn't change often, then software will start to assume that it never changes, and break when it does.
TLS has learned this the hard way when they discovered that huge numbers of existing web servers have TLS version intolerance. So now TLS 1.2 is forever enshrined in the ClientHello.
The difference between valid PNG you can't decompress and invalid PNG is fairly irrelevant when your aim is to get an image onto the screen.
And considering we already have plenty of more advanced competing lossless formats, I really don't see why "feed a BMP to deflate" needs a new, incompatible spin in 2025.
> plenty of more advanced competing lossless formats
Other than JXL which still has somewhat spotty support in older software? TIFF comes to mind but AFAIK its size tends to be worse than PNG. Edit: Oh right OpenEXR as well. How widespread is support for that in common end user image viewer software though?
More generally, PNG has a simple feature to specify what's needed. A file consists of a number of chunks, and one bit in the chunk specifies whether that chunk is required for display. All of the extensions I've seen in the past decades set that bit to "optional".
For example, this update includes a chunk containing EXIF data. As you'd expect, the exif chunk sets that bit to "optional".
Extensibility of PNG has been amply used, as intended, for proprietary chunks that hold application specific data (e.g. PICO-8 games) without bothering other software.
One could imagine a PNG file which contains a low-resolution version of the image with a traditional compression algorithm, and encodes additional higher-resolution detail using a new compression algorithm.
I don’t know if it’s the spec or just a plethora of vendors that ignores it, but I have many things with a USB-C port that requires USB-A as source. USB-C to A to C works, yay dongles, but not just C to C.
So maybe it’s not really breaking backwards compatibility, just a weird mix of a port and the communication being separate standards.
it's vendors just changing the physical port but not updating the electronics. specifically, a 5.1kΩ pull-up resistors on the CC1 and/or CC pins is needed on the host (was usb-a) side in order for the c to c cable to work.
Some things don't work unless you use the right kind of USB-C cable.
EG your GPU and monitor both have a USB-C port. Plug them together with the right USB cable and you'll get images displayed. Plug them together with the wrong USB cable and you won't.
USB 3 didn't have this issue - every cable worked with every port.
That is not backward compatible problem. If a cable that does 100w charging when using pd2.0, but only 60w when using with pd3.1 device, then i would agree with you.
The problem is not backward compatibility but labeling. A USB-C cable looks universal but isn’t. Some of them just charge, some do data, some do PD, some give you access to high speed. But there is no way to know.
I believe the problem here is that you will have PNG images that “look” like you can open them but can’t.
the parent said "changing the compression algorithm will break backwards compatibility", which i assume is something works now won't work in the future. The usb-c spec is intentionally trying to avoid that.
Today, I can save a PNG file off a random website and then open it.
If PNG gets extended, it's entirely plausible that someone will view a PNG in their browser, save it, and then not be able to open the file they just saved.
There are those who claim "backwards compatibility" doesn't cover "how you use it" - but roughly none of the people who now have to deal with broken software care about such semantic arguments. It used to work, and now it doesn't.
which is what usb-c spec has been avoiding so far. Even in USB4 spec, there are a lot of mentioning the new spec should be compatible with TB3 devices.
USB-C spec is anything but breaking backward compatible.
The alternative is the website operator who wants to save on bandwidth instead adopts JXL or WEBP or what have you and ... the end user with old software still can't open it.
It's a dichotomy. Either the provider accommodates users with older software or not. The file extension or internal headers don't change that reality.
Another example, new versions of PDF can adopt all the bells and whistles in the world but I will still be saving anything intended to be long lived as 1/a which means I don't get to use any of those features.
Cable labeling could fix 99% of the issues with USB-C compat. The solution should never be blaming consumer for buying the wrong cable. Crappy two-wire charge-only cables are perfectly fine for something like a night desk lamp. Keep the poor cables, they are okay, just tell me if that's the case.
Same thing with PNG. Just call the format with new additions it PNGX, so the user can clearly see that the reason their software can’t display the image is not a file corruption.
This is just pretending that if you have a cat and a dog in two bags and you call it “a bag”, it’s one and the same thing…
> Cable labeling could fix 99% of the issues with USB-C compat.
Labelling is a poor band-aid on the root problem - consumer cables which look identical and fit identically should work wherever they fit.
There should never have been a power-only spec for USB-C socket dimensions.
If a cable supports both power and data, it must fit in all sockets. If a cable supports only power it must not fit into a power and data socket. If a cable supports only data, it should not fit into a power and data socket.
It is possible to have designed the sockets under these constraints, with the caveat that they only go in one way. I feel that that would have been a better trade-off. Making them reversible means that you cannot have a design which enforces cable type.
So since my vape (example, i dont vape) has a power and data slot for charging and firmware updates, i should be limited to only using dual purpose cables day to day rather than a power only cable?
> So since my vape (example, i dont vape) has a power and data slot for charging and firmware updates, i should be limited to only using dual purpose cables day to day rather than a power only cable?
Well, yes.
Why can't you use a power+data cable for the vape (or whichever appliance takes both)? What's the deal-breaker here?
The alternative is labeling, or plugging cables in to see if they do what you want them to do.
Is the same true for my laptop? Or soldering plate? Both take over 150w of power. Buying a power and data cable is expensive compared to just power, and the length of cable is severely limited...or the data speed impaired significantly. How slow does the data have to be for it to be non compliant?
> If a cable supports only power it must not fit into a power and data socket
That's even more confusing than the current state of affairs. If my phone has power and data socket, then I cannot use power only cable to only charge it? Presumably with the charger that has power only socket. So I need a cable with two different ends anyway. Just go micro-USB at this point :)
Funnily enough, there is a 100% overkill way to solve such issues. Just use super expensive certified TB cables. Well... plus a A-to-C adapter for noncompliant devices, I guess.
Two wire cables are not in the specification, just like A-to-A cables aren't. The whole charging above 100mA with resistor hacks wasn't in the standard either until they had to grandfather it in. The implementers forum isn't responsible for non-members breaking their spec.
That's not just an issue with usb-c. normal usb a and b cables can have data or no data depending on how stingy the company wants to be, and you can't know until you test it
Yeah, I also don't think they've broken backwards compat ever. Super high end charger from 2024 can charge old equipment from 2014 just fine with regular 5V.
What was broken was the promise of a "single cable to rule them all", partly due to manufacturers ignoring the requirements of USB-C (missing resistors or PD chips to negotiate voltages, requiring workarounds with A-to-C adapters), and a myriad of optional stuff, that might be supported or not, without a clear way to indicate it.
I think if they did that, nobody would use it. And anyway, from the article:
> Many of the programs you use already support the new PNG spec: Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer...
It might be too late to rename png to .png4 or something. It sounds like we're using the new png standard already in a lot of our software.
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 new files. And teaching people that sRGB maybe isn't good enough any more. That's going to be hard since most people have no clue about color spaces.
Anyway, that gives everybody plenty of time to upgrade. By the time this stuff is widely used, it will be widely supported. So, you kind of get forward compatibility that way. Your browser already supports the new format. Your image editor probably doesn't.
There are about 3.6 billion people surfing the web and experiencing PNGs. That use case, consuming PNGs, seems to dwarf the perhaps 100 million (somewhat wild guess) graphic designers, web developers, and photo editing professionals who manipulate images for publishing (in any medium) or archiving.
If, on the other hand, you're considering the use cases envisioned by PNG's creators, or the use cases that interest the people processing or publishing images, yes, these people are focused on format itself and its capabilities.
I suspect this particular use of "use case" isn't terribly clear. Also these two considerations are not incompatible.
It's not, most images you encounter on the web need better compression.
The main PNG use case is to store lossless images locally as master copies that are then compressed or in workflows where you intend to edit and change them where compressed formats would degrade the more they were edited.
What backward compatibility are we talking about here? Backwards compatibility of images will be fine, backwards compatibility of decoders might be impacted, but the article says the major image viewers (browsers) and image editors already support the 3rd version. Better compression is only planned for the 5th version of the spec.
Also if you forbid evolving existing formats, the only alternative to improve is to introduce a new format, and I argue that it would be causing even more fragmentation and be more difficult to adopt to. Look at all the drama surrounding JPEG XL.
They could, for example, use lossy compression for the compatibility layer and then fill it in the rest of the way to lossless using incompatible new compression objects. Legacy uses will see some fidelity degradation, but they are already being stuck with sRGB downmixes, so that’s fine — and those who are bothered by it can just emit a lossless-pixels (but lossy-color and lossy-range) compatibility layer and reserve the compression benefits for the color and dynamic range.
I’m not saying this is what will happen — but if I was able to construct a plausible approach to compression in ten minutes, then perhaps it’s a bit early to predict the doom of compatibility.
The first bit of our research is "What can we already make use of which requires no spec update? There are plenty of PNG optimizers. How much of that should go into the typical PNG libraries?"
Same with parallel encoding & decoding. An older image viewer will be able to decode it on one thread without ever knowing parallel decoding was an option.
Here's the worry-a-little part: Everybody immediately jumps to file size as to what image compression is better or worse. That isn't the best take, but it is what it is. So there is pressure to adopt newer technologies.
We often do have a way to maintain some degree of backwards compatibility even when we do this. For example, we can store a downsampled image for old viewers. Then extra, new chunks will know "Mix that with this full scale data, using a different compression".
As you can imagine, this mixing complicates things. It might not be the best option. Sooooo we're researching it :)
Reading the linked blog post on the new cICP chunk type [0], it looks like the "proper HDR support" isn't something that you couldn't already do with an embedded ICC profile, but instead a much-abbreviated form of the colorspace information suitable for small image files.
"common but not representable RGB spaces like Adobe 1998 RGB or ProPhoto RGB cannot use CICP and have to be identified with ICC profiles instead."
cICP is 16 bytes for identifying one out of a "list of known spaces" but they chose not to include a couple of the most common ones. Off to a great start...
I wonder if it's some kind of legal issue with Adobe. That would also explain why EXIF / DCF refer to Adobe RGB only by the euphemism "optional color space" or "option file". [1]
How so? As far as I can tell, the ICCv2 spec is very agnostic as to the gamut and dynamic range of the output medium. It doesn't say anything to the extent of "thou shalt not produce any colors outside the sRGB gamut, nor make the white point too bright".
Unless HDR support is supposed to be something other than just the primaries, white point, and transfer function. All the breathless blogspam about HDR doesn't make it very clear what it means in terms of colorspaces.
IIRC (been a while), the reason was ICCv2/v4 still requires a gamma function. And PQ is not a gamma function. Maybe they can cover HLG, but if we want to represent any given HDR content, we needed something more than ICCv2/v4.
That doesn't sound quite right to me. ICCv2's 'curveType' gives the option of a full lookup table instead of a simple gamma function. Maybe it has to do with ICCv2 saying that the reference viewing condition has an illumination level of 500 lx for the perceptual intent? (But how does that apply to non-reflective media?)
I don't doubt that there's lots of problems in the chain from RGB samples to display output, but I'm finding this whole thing horribly confusing. Wikipedia tries to distinguish 'HDR' transfer functions like PQ [0] from 'SDR' transfer functions in terms of their absolute luminance, but the ICC specs are just filled with relative values all the way down.
(Not to mention how much these things get fiddled with in practice. Once, I had the idea of writing a JPEG decoder, so I looked into how exactly to convert between sRGB and Rec. 601 YCbCr coordinates. I thought, "I know, I'll just use the standard-defined XYZ conversions to bridge between them!" But psych, the ICC sRGB profile has its own black point scaling that the standards don't tell you about. I'm still not sure what the correct answer is for "these sRGB coordinates represent the exact same color as these Rec. 601 YCbCr coordinates".)
Agreed that it gets confusing. That's a piece of why I'm unable to give you a solid answer. This isn't my area of expertise.
Here is what I can tell you confidently:
The original plan was to provide an ICC profile that approximates PQ as best as we could. But it wasn't enough. So the proposal was to force the profile name to be a special string. When a PNG decoder saw that name, it would ignore the ICC profile and do actual PQ.
Possibly more context (I just found this) from Apple. I'm not sure of date: https://www.color.org/hdr/02-Luke_Wallis.pdf
Slide 29:
"HDR parametric transfer functions not in ICC spec
Parametric 3D tone mapping functions not in ICC spec
- Neither can be approximated by 1-D or 3-D LUTs"
I'm not sure why they cannot be approximated by LUT. Maybe because of the inversion problem?
Thanks for that proposal link. The email thread starting at [0] seems to explain some of the challenges. My understanding:
- In ICC-land, all luminances are relative to the display's (or reflective medium's) black and white points. So for an HDR-capable display, all content, HDR or SDR, would be naturally displayed at the full 10k nits or whatever the actual number is. This is obviously not how things work in practice: OSes and/or displays really want a signal as to whether the full HDR luminance is actually desired. (This reminds me of an earlier HN thread where people complained about HDR video forcing up the brightness on Apple devices.)
- PQ (but not HLG) specifies everything in terms of absolute luminance, but this gets confusing when people want to adjust their display brightness and have everything work relatively in practice.
- Due to lack of support for "overrange" behavior [1], 1D LUTs + matrices are insufficient for representing PQ at all, so you need a 3D LUT just to approximate it. This needs ICCv4, since ICCv2 only supports 3D LUTs for non-display profiles.
- But 3D LUTs are big and fat, and can only give a few bits of accuracy across some parts of the full HDR range. (It seems like there's no form of delta compression?) Most people really hate this. iccMAX can allegedly use 3D parametric formulas, but literally no one implements it since it has a million bells and whistles.
- More importantly, GPUs especially hate big fat LUTs, and everyone uses GPU rendering. In the worst case, some implementations will do everything they can to ignore LUTs in ICC profiles, and instead try to guesstimate some simple-gamma or linear-gamma approximation, which won't end well.
So it does seem to be a combination of "the HDR stack is a mess and needs its own special signaling" and practical concerns about avoiding overly huge profiles.
> How so? As far as I can tell, the ICCv2 spec is very agnostic as to the gamut and dynamic range of the output medium. It doesn't say anything to the extent of "thou shalt not produce any colors outside the sRGB gamut, nor make the white point too bright".
That’s precisely what makes it unsuitable for HDR. With PQ, (1, 1, 1) means 10 000 cd/m² – if you simply create an ICC profile with the PQ transfer function, an image that looks right on a hypothetical 10 000 cd/m² monitor will look way too dim when naïvely scaled down (as ICC-type colour management would have you do) to the 300 cd/m² of a typical monitor. HLG, meanwhile, has a transfer function that depends on the peak luminance, which is not possible to do with ICC (the profile would have to assume a specific peak luminance), and the reason that it does that is to preserve the subjective perception of the image.
So, sure, you can prepare an HDR image so that it looks right on a monitor with a 1000 cd/m² peak luminance, describe the colorspace in relative terms using an ICC profile, and you will have “done HDR using ICC”, but that’s arguably a very low bar for “supporting HDR”.
So 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.
Hyphenation of multi-word nouns is a process in English that usually happens after some time of usage as separate words. It often happens before eventually merger into a single compound word noun. Such as: "Electronic Mail" to "E Mail" to "e-mail" to "email".
Given how often it is used as a jargon term in software development, I can absolutely see this usage of "use-case" here as a "vote" for the next step in the process. Will we eventually see "usecase" become common? It's possible. I think it might even be a good idea. I'm debating adding my own "votes" for the hyphen moving forward.
It supports JavaScript when used as a document, but when used as an "image" by a browser (IMG tag, CSS features) JavaScript and the loading of external resources are disabled.
APNG would be for lossless compression, and probably especially for animations without a constant frame rate. Similar to the original GIF format, with APNG you explicitly specify the duration of each individual frame, and you can also explicitly specify looping. This isn’t for video, it’s more for Flash-style animations, animated logos/icons [0], or UI screen recordings.
All valid points, however AV1 also supports lossless compression and is almost certainly going to win the file size competition against APNG every time.
8-bit YCoCg (even when using the reversible YCoCg-R [1] scheme) cannot represent 8-bit RGB losslessly. The chroma channels would need 9 bits of precision to losslessly recover the original 8-bit RGB values.
Show me any of the popular image conversion tools (avifenc, imagemagick, photoshop, ffmpeg, whatever...) that does the identity matrix hack when asking for lossless AVIF. None of them do it. Many people have been burned by "lossless" AVIF, where they converted their images in the mistaken belief that the result will be bit-identical to the original, only to find out that this wasn't the case, after they've deleted the original files.
That's shifting the goalposts from what the standard supports to the current state of the ecosystem. It's certainly an interesting point though. If common implementations all have bugs regarding lossless encoding that's a pretty bad situation.
Once you add more than 256 different colours in total, GIF explodes in terms of file size. It's great for small, compact images with limited colour information, but it can't compete with APNG when the image becomes more detailed than what you'd find on Geocities.
In APNG it's either the same 256 colors for the whole animation, or you have to use 24-bit color. That makes the pixel data 3 times larger, which makes zlib's compression window effectively 3 times smaller, hurting compression.
OTOH GIF can add 256 new colors with each frame, so it can exceed 256 colors without the cost of switching all the way to 16.7 million colors.
> Animated PNGs can't beat GIF nevermind video compression algorithms.
Not entirely true, it depends on what's being displayed, see a few simple tests specifically constructed to show how much better APNG can be vs GIF and {,lossy} webp:
http://littlesvr.ca/apng/gif_apng_webp.html
Of course I don't think it generalizes all that well…
I tried these examples on ezgif, and indeed apng manages to be smaller than webp every single time. Weird, I was under the impression that webp was almost always smaller? Is this because GIF images are already special, or apng uses better compression than png?
edit: using the same ezgif webp and apng on a H.264 source, apng is suddenly 10x the size than webp. It seems apng is only better if the source is gif
You're correct and I was considering adding a footnote that if you use indexed colors like a GIF then PNG can beat GIF due to better compression algorithms. But when most people think of APNG they think of lossless compression rather than lossy compression.
Indexed can be lossless when the source already uses few colors, e.g. because you want to improve the compression of an existing GIF or limit colors for stylistic choice (common in pixel art).
> many gifs these days are actually served as soundless videos
That's not really true. Some websites lie to you by putting .gif in the address bar but then serving a file of a different type. File extensions are merely a convention and an address isn't a file name to begin with so the browser doesn't care about this attempt at end user deception one way or the other.
I parsed the comment as something along the lines of clever hackers somehow stuffing soundless videos into gif containers which is most certainly not what is going on. I was attempting to convey that they have nothing to do with gifs. Gifs are not involved anywhere in the process.
I'm not sure why people disagree so strongly with what I wrote. Worst case scenario is that it's a slightly tangential but closely related rant about deceptive web design practices. Best case scenario is that someone who thought some sort of fancy trick involving gifs was in use learns something new.
It's absolutely possible. Browsers even routinely pause playback when images aren't visible on screen.
They just don't have a proper UI and JS APIs exposed, and there's nothing stopping them from adding that.
IMO browsers are just stuck with tech debt, and maintainin a no-longer-relevant distinction between "animations" and "videos". Every supported codec should work wherever GIF/APNG work and vice versa.
It's not even a performance or complexity issue, e.g. browsers support AVIF "animations" as images, even though they're literally fully-featured AV1 videos, only wrapped in a "pretend I'm an image" metadata.
I wish browsers still paused all animations when the user hits the Esc key. It's hard to read when there are distracting animations all over most pages.
SVG is just html5, it has full support for CSS, javascript with buttons, web workers, arbitrary fetch requests, and so on (obviously not supported by image viewers or allowed by browsers).
Browsers support all that sort of thing, as long as you use an iframe. (Technically there are sone subtle differences between that and html5, but you are right its mostly the same)
If you use an <img> tag, svgs are loaded in "restricted" mode. This disables scripting and external resources. However animation via either SMIL or CSS is still supported.
And non-browser image renders support almost none of those advanced totally-still-SVG features (and I don't blame them) while they often do support animated GIFs.
When it comes to converting small video snippets to animated graphics, I think WEBP was much better than APNG from the beginning. Only if you use GIF as intermediate format then APNG was competitive.
webm or any other non-gimped video codec would be a much better format for that use case. Unfortunately browsers don't allow those in image contexts so we are stuck with an inferior "state of the art" literally-webm-with-deliberately-worse-compression webp standard.
AVIF is only starting to become widespread so can't be used without fallback if you care about your users. Not sure how it compares to AV1 quality/compression wise but hopefully its not as gimped as webp and there will encoders that aren't as crap as libwebp that almost everyone uses.
> Unfortunately browsers don't allow those in image contexts
The fact that we have the <img> element at all is bad. HTML has since the early days a perfectly capable <object> which can even be nested to provide fallback, but browser support was always spotty.
The Acid2 test famously used <object> to shame browser vendors into supporting it at least to some extent.
ZIP is theoretically a generic container and theoretically supports a number of different compression formats. Stored (no compression) and deflate are the only ones you can count on being supported everywhere though so in practice you're not wrong.
Some years ago I've used the Lottie (Bodymovin?) library. It worked great and had a nice integration: you compose your animation in Adobe After Effects, export it to an svg plus some json, and the lottie JS script would handle the animation for you. Anything else with (vector, web) animations I've tried is missing the tools or the DX for me to adopt. Curious to hear if there are more things like this.
I'm not sure about the tools and DX around animated PNGs. Is that a thing?
Almost nowhere that supports uploading GIFs supports APNG or animated WEBP. The back end support is so low it's close to zero. Which is really frustrating.
Do you mean services that reencode gif files to webm/mp4? apng just works everywhere that png works, and will remain animated as long as it's not re-encoded.
You can even have one frame that gets shown if and only if animation is not supported.
That's not the first frame, it's the fallback image that png decoders which are unaware of apng decode.
It is never shown by compliant apng decoders. You can make it the first frame of the animation, or any other image you want. e.g. some text saying "APNG unsupported"
Firefox is there to prevent/delay the forced breakup of Googles monopoly no to provide any real competition, thanks for showing another example of that.
Probably the best news here. While you already can write custom data into a header, having Exif is good.
BTW: Does Exif have a magnetometer (rotation) and acceleration (gravity) field? I often wonder about why Google isn't saving this information in the images which the camera app saves. It could help so much with post-processing, like with leveling the horizon or creating panoramas.
Exif can also cause confusion for how to render the image: should its rotation be applied or not?
Old decoders and new decoders now could render an image with exif rotation differently since it's an optional chunk that can be ignored, and even for new decoders, the spec lists no decoder recommendations for how to use the exif rotation
It does say "It is recommended that unless a decoder has independent knowledge of the validity of the Exif data, the data should be considered to be of historical value only.", so hopefully the rotation will not be used by renderers, but it's only a vague recommendation, there's no strict "don't rotate the image" which would be the only backwards compatible way
With jpeg's exif, there have also been bugs with the rotation being applied twice, e.g. desktop environment and underlying library both doing it independently
The stupid thing is that any device with an orientation sensor is still writing images the wrong way and then setting a flag, expecting every viewing application to rotate the image.
The camera knows which way it's oriented, so it should just write the pixels out in the correct order. Write the upper-left pixel first. Then the next one. And so on. WTF.
Most modern camera modules have built in hardware codecs like mjpeg, region of interest selection, and frame mirror/flip options.
This is particularly important on smartphones and battery operated devices. However, most smartphone devices simply save the photo the same way regardless of orientation, and simply add a display-rotated flag to the metadata.
It can be super annoying sometimes, as one can't really disable the feature on many devices. =3
Rotation for speed/efficiency/compression reasons (indeed with PNG's horizontal line filters it can have a compression reason too) should have been a flag part of the compressed image data format and for use by the encoder/decoder only (which does have caveats for renderers to handle partial decoding though... but the point is to have the behavior rigorously specified and encoded in the image format itself and handled by exactly one known place namely the decoder), not part of metadata
It's basically a shame that the exif metadata contains things that affect the rendering
the main reason is probably that the chip is already outputting the image in a lossy format, and if you reorder the pixels you must reencode the image which means degrading the image, so it's much better to just change the exif orientation.
JPEG can be rotated losslessly. `jpegtran` can do it, for example (and comes with a script called `exifautotran` to automatically normalise the orientation of a bunch of JPEG files at once).
Burst mode in cameras means the sensor is readout is buffered in RAM while the encoding and writing to persistent storage catches up. Rotating the buffer would be part of the latter and not affect burst speed - and is an insignificant cost anyway.
One interesting thing about JPEG is that you can rotate an image with no quality loss. You don't need to convert each 8x8 square to pixels, rotate and convert back, instead you can transform them in the encoded form. So, rotating each 8x8 square is easy, and then rotating the image is just re-ordering the rotated squares.
I'm not sure if this is how JPEG implements it, but in H.264, you just have metadata which specifies a crop (since H.264 also encodes in blocks). From some quick Googling, it seems like JPEG also has EXIF data for cropping, so if that's the mechanism that's used to crop off the bottom and right portions today, there's no reason it couldn't also be used to crop off the top and left portions when losslessly rotating an image's blocks.
Indeed. Whenever I'm using an image browser/manager application that supports rotating images, I wonder if it's doing JPEG rotation properly (as you describe) or just flipping the dumb flag.
> What are the arguments for this? It would seem easier for everyone to rotate and then store exif for the original rotation if necessary.
Performance. Rotation during rendering is often free, whereas the camera would need an intermediate buffer + copy if it's unable to change the way it samples from the sensor itself.
Pretty much every pixel rendered these days was generated by a shader so gpu side you probably already have way more translation options than just a 90° rotation (likely already being used for a rotation of 0°). You'd likely have to write more code cpu side to handle the case of tell the gpu to rotate this please and handle the UI layout diffrence. Honestly not a lot of code.
For anything GPU-rendered, applying a rotation matrix to a texture sample and/or frame-buffer write is trivially cheap (see also why Vulkan prerotation exists on Android). Even ignoring GPU-rendering, you always are doing a copy as part of rendering and often have some sort of matrix operation anyway at which point concatenating a rotation matrix often doesn't change much of anything.
The cost is paid in different memory access patterns which may or may not be mitigated by the GPU scheduler. It's an insignificant cost either way though, both for the encoder and the renderer. Also depending on the pixel order in sensor, file or frame buffer "rotated" might actually be the native way and the default is where things get flipped around from source to destination.
Access pattern is mitigated by texture swizzling which will happen regardless of how it's ultimately rendered. So even if drawn with an identity matrix you're still "paying" for it regardless just due to the underlying texture layout. GPUs can sample from linear textures, but often it comes with a significant performance penalty unless you stay on a specific, and undefined, path.
Given that rotation sensors have been standard equipment on most cameras (AKA phones) for many years now, I would expect pixel-reordering to be built into supporting ASICs and to impose negligible performance penalties.
> The camera knows which way it's oriented, so it should just write the pixels out in the correct order. Write the upper-left pixel first. Then the next one. And so on. WTF.
The hardware likely is optimized for the common case, so I would think that can be a lot slower. It wouldn’t surprise me, for example, if there are image sensors out there that can only be read out in top to bottom, left to right order.
Also, with RAW images and sensors that aren’t rectangular grids, I think that would complicate RAW images parsing. Code for that could have to support up to four different formats, depending on how the sensor is designed,
At this point I expect any camera ASICs to be able to incorporate this logic for plenty-fast processing. Or to do it when writing out the image file, after acquiring it to a buffer.
Your raw-image idea is interesting. I'm curious as to how photosites' arrangement would play into this.
Yes, but websites frequently strip all or almost all Exif data from uploaded images because some fields are used by stalkers to track people down to their real address.
That makes sense to me for any image you want to share publicly, but for private images having the location and capture time embedded in the image is incredibly useful.
If you are uploading it to a website you are sharing it. Even if the image is supposedly "private" you have to assume it will be leaked at some point. Remember, the cloud is just someone else's computer, and they can do what they want with their computer. They may also not be entirely competent at their job.
Yes, once something has been shared (or stolen), you lost control over it, be it information or an image. EXIF data is fine, if it never leaves your device or if your device is not compromised.
There is an acceleration field (Exif.Photo.Acceleration) and (Exif.Photo.CameraElevationAngle) for elevation but oddly not 3 axes. Similarly there are fields for ambient environmental conditions, but only whatever specific things the spec-writers considered.
You could store this in Exif.Photo.MakerNote: "A tag for manufacturers of Exif writers to record any desired information. The contents are up to the manufacturer." I think it can be pretty big, certainly more than enough for 9 DoF position data.
Ages ago I worked on photogrammetry software, and the lack of such information was indeed painful for us. One of the most important parts of the processing pipeline is calculation the position and orientation of each camera; having at least the orientation would have made our life much easier.
The issue that gets me is that Google Photos and Apple photos will let you manually pick a date, but they won't actually set it in the photo EXIF, so when you move platforms. All of the images that came from scans/sent without EXIF lose their dates.
EXIF inside of PNGs is new. You can make it work by embedding structured chunks into the file, but it's not official in any way (well, not until the new spec, at least). Sidecar files have some kind of interoperable format that at least don't break buggy PNG parsers when you open the image file. The sidecar files themselves differ in format, but at least they're usually formatted according to their extension.
The usual sidecar files, XMP files, are standardised (in that they follow a certain extensible XML structure) and can (and often do) include EXIF file information.
Pretty much all the photos in Apple/Google photos are going to be JPEG and HEIF which do support EXIF. But both services basically will not touch what came out of the camera at all. If you add a description or date, it gets stored externally to the image so when you export your data, those changes are lost. Or they get dumped in a JSON file requiring you to use some custom script to handle it.
Not touching the image for metadata changes is a good thing as that makes backups more efficient/simpler. Embedded metadata is also a security issue as users may share more information than they realize which is why it is common to strip it automatically in many places.
XMP [0] is a standard but no idea of Google and Apple use it (Darktable does). You could also store EXIF data as sidecar files but I don't think that has better support.
I remember reading about this in a web forum mainly for dublin core fanatics. Metadata is fascinating.
Different software reacts in different ways to partial specifications of yyyy/mm/dd such that you can try some of the cute tricks but probably only one s.w. package honours it.
And the majors ignore almost all fields other than a core set of one or two, disagree about their semantics, and also do wierd stuff with file name and atime/mtime.
Animation was an early feature, actually. It was called "MNG" and was developed alongside PNG. I don't know the details of why but it never really saw adoption outside of Firefox and was eventually removed even from there. APNG is different from MNG and came much later.
DaVinci Resolve also supports OpenEXR format with the added magic of LUT.
PNG is popular with some Commercial Application developers, but the exposure and color problems still look 1980's awful in some use-cases.
Even after spending a few grand on seats for a project, one still gets arrogant 3D clown-ware vendors telling people how they should run their pipeline with PNG hot garbage as input.
People should choose EXR more often, and pick a consistent color standard. PNG does not need yet another awful encoding option. =3
The calibration workflows also depend heavily on what is being rendered, source application(s), and the desired content look. There were some common free packs on github for popular programs at one time. Should still be around someplace... good luck. =3
In general, with some applications people hit the limits pretty quickly with PNG and JPG. In our use-case, the EXR format essentially meant a rendered part of the source image wouldn't be "overexposed" by the render pipeline, and layers could be later adjusted to better match in Resolve. Example: your scenes fireball simulation won't look like a fried egg photo from 1980 due to hitting 0xFF.
If you've never encountered the use-case, than don't worry about the aesthetics. Seriously, many vendors also just don't care... especially after they already were paid. Best of luck =3
I'm trying to follow your point. But...there are problems with your claims.
Yes, EXR stores color-space differently than PNG. Because EXR doesn't store color space at all.
In the first video, the person loads the image and manually chooses a gamma transfer function with 2.2. If that was then saved, it would produce the washed-out fireball you mentioned.
In the second video, the person loads the image and manually chooses rec.709, which is also gamma tf and also produces washed-out fireball. In fact, the EXR image he loads literally has a bright fireball and you see it get washed out.
If you want to make claims about EXR being better than PNG, you need to say why storing the values as floating point is better than integer. But the blown-out fireball example is just incorrect. As evidence, I'll point to HDR. ANYTHING you see in an HDR movie is now 100% losslessly reproducible in a PNG.
There is a lot of conflated contexts to unpack there...
However, I still trust the ILM engineers over your pet project, and maligned post that reeks of LLM slop.
The argument of making cow from hamburger doesn't hold true under our use-cases. You were shown the path, and it is your choice to put in the work to learn something important.
Without the new HDR and color profile handling, PNG was still useful but significantly obsolete. Display hardware has progressed over a few decades, raising the bar for image files.
It has, but WWW is still de facto sRGB, and will be for a long time still. But again, I'm not strictly opposed to evolving PNG, I just hope they don't ruin it in the process, because that's usually what happens when something gets update for a modern audience. I'll be watching with mixed optimism and concern.
The continued popularity of non-HDR 1080p screens on laptops is a bleak reminder that most people would rather save a couple hundred bucks than buy HDR capable hardware.
HDR is great for TVs and a nice-to-have on phones (who mostly get it for free because OLEDs are the norm these days), but display technology only advances as much as its availability in low-cost devices.
Or maybe the advantage isn't that big for most uses (images with super bright highlights are a nice novelty but not fun to look at all the time) and people don't want to deal with the clusterfuck that is HDR software support.
PNG already supports color profiles, but probably not HDR. I would say that the gamut argument in the article is misleading, you can already encode a wider gamut.
Not sure how HDR encoding works, but my impression is that you can set a nominal white point other than (1, 1, 1) in your specified colorspace. This is an extension, but orthogonal to specifying the colorspace itself and the gamut.
You are correct. I designed the article to be very approachable and understandable for the normal person. As such, I took some liberties like only showing HDR primaries and ignoring transfer function. I linked to Chris Lilley's post to give experts a more correct answer.
But wide color gamut was already possibly in PNG via ICC profiles (HDR was not). And those primaries I showed could have been used in a wide color image.
So the image is a bit misleading or red-flag-y to experts who know. But to the average person, I think it is as truthful as I can be without getting too deep in the weeds.
There is nothing in display hardware today that TIFF couldn't handle already.
For example 16bit (integer) TIFF files 'with headroom', i.e. where some bits were used to represent data over 1.0 (HDR) was a common approach for VFX work in the 90's.
16bit float TIFF is also thing since 33 years. Adobe DNG is modeled after TIFF. High end offline renderers have traditionally been using TIFF (with mip-maps) to store textures.
TIFF supports tags so primaries and white point or a known color space name can be stored in the file.
The format is so versatile, it is used everywhere.
And of course it also supports indexed color, i.e. a non-negotiable feature at the time PNG was introduced.
PNG was meant to replace GIF. Instead of looking what was already there some group of "experts" and "enthusiasts" (quote Wikipedia) succumbed to their NIH complexes.
If licensing/patent woes over compression algorithms had been a motivator, why not just add a new one to TIFF?
The fact that PNG stores straight/unpremultiplied alpha says everything if you know anything about imaging in computer graphics.
And the fact that the updated format spec just released didn't address this tells you everything you need to know about the group in charge of that, today.
PNG is the VHS of image formats. It should have never seen the light day of in the first place nor the adoption it did.
> The fact that PNG stores straight/unpremultiplied alpha says everything if you know anything about imaging in computer graphics.
> And the fact that the updated format spec just released didn't address this tells you everything you need to know about the group in charge of that, today.
You can't represent additive pixels (i.e. glowing pixels) with non-associated alpha. That's why this is used in exactly zero image processing software, internally.
E.g. an associated pixel with the 8bit/channel RGBA value 255, 0, 0, 0 (glowing red).
Because PNG can only store associated data a reader must associate before displaying. And that will give you a value of 0, 0, 0 after (black instead of additive red).
See e.g. [1] why this matters.
Additionally the PNG spec does not specify if the alpha is linear. Some PNG readers/writer assume it is, some assume it has gone through/should go through an sRGB transfer curve instead. It mostly works until it doesn't.
The fact that the spec. doesn't specify which one it should be is another telltale sign that it was written by people unaware of the subtleties of image processing.
I understand that unassociated alpha gives you more precision in 8bit and since people wanted to e.g. store color ramps (with alpga) in PNG at the time (pre-SVG) and most image processing software (i.e. mainly Photoshop then) would not dither gradients for 8bit, this really mattered.
But it's 2025. And when 16bit PNG got introduced this should have definitely had associated (and explicitly linear) alpha.
> I understand that unassociated alpha gives you more precision in 8bit and since people wanted to e.g. store color ramps (with alpga) in PNG at the time…
They do not mention precision at all in their rationale for that: “We standardized on non-premultiplied alpha as being the lossless and more general case.”
> And when 16bit PNG got introduced...
PNG has supported 16-bits per component since it was first introduced (see version 1.0 of the spec or RFC 2083).
> “We standardized on non-premultiplied alpha as being the lossless and more general case.”
How is this "more general"? Unpremultiplied is actually lossy (not so as far as precision goes but critically so if you talk about meaning/information).
> PNG has supported 16-bits per component since it was first introduced (see version 1.0 of the spec or RFC 2083).
True, my bad. But there have been many updates to the spec over the years.
I btw found a mention of alpha to be assumed to be linear in [1] but in a comment in a sample code snippet.
Quote:
/*
* Compositing is necessary.
* Get floating-point alpha and its complement.
* Note: alpha is always linear; gamma does not
* affect it.
*/
On the note of alpha: [2] is a good piece to read to understand why this matters, specifically the section "PNG cannot store all clamped linear values…".
Yes, plenty of tech garbage floats at the top, the question is why would you argue that lack of basic fixes over decades is not stagnation, but something positive
Official support for animations, yes! This feels so nostalgic to me, I have written an L-system generator with support for exporting animated PNGs 11 years ago! They were working only in Firefox, and Chrome used to have an extension for them. Too bad I had to take the website down.
Back then, there were no libraries in C# for it, but it's actually quite easy to make APNG from PNGs directly by writing chunks with correct headers, no encoders needed (assuming PNGs are already encoded as input).
While I welcome that there is now PNG with animations, I am less impressed about how Mozilla chose to push for it.
Using PNG's magic numbers and pretend to existing software that it is just normal PNG? That is the same mindset that lead to HTML becoming tag soup. After all, HTML with a <blink> tag is still HTML, no?
I think they could have achieved animated PNG standardization much faster with a more humble and careful approach.
What about implementations? libpng seems pretty dead, 1.7 has been in development forever but 1.6 is still considered the stable version. Is there a current "canonical" png C/C++ library?
I mean, if the spec has been stable for two decades then maybe there just hasn't been much to fix? Especially since PNG is a relatively simple image format.
For modern C/C++ PNG implementations, consider lodepng (header-only), stb_image/stb_image_write (single-file), or libspng (active fork focused on performance and security) as more actively maintained alternatives to libpng.
it's more to do with the obvious economic layer underneath. you give a format new life only if there's tooling and distribution muscle behind it. adobe, apple, chrome, ffmpeg etc may not get aligned at the same time. someone somewhere wants apng/hdr/png to be a standard pipe again for creative chains; maybe because video formats are too bulky for microinteraction or maybe because svg is too unsafe in sandboxed renderers. and think onboarding of animations, embedded previews, rich avatars, system wide thumbs ; all without shipping a separate codec or runtime. every time a 'dead' format comes back, it's usually because someone needed a way around a gate
In general, I support the "follow the money" idea. But I don't think it applies here.
I'm retired and making zero money here. (I'm actually losing money on it. Wish I had a company sponsoring me for the flights and hotels for meetups.)
All participants are required to not patent any piece of it. We work hard to make sure we only reference open standards. (This one is quite tricky. We have to convince other standard orgs to make their stuff free.)
I could see the argument for getting around a gate. But fwiw I don't think that's the case :)
If 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.
Yeah, the whole "subscribe to events then check a status result" thing is pretty bad. This is compounded by "Box" behaving differently than everything else. When I made JxlSharp (C# JXL library wrapper), I had to add a workaround in there to force Box to behave like all the other event subscriptions.
And buffer sizes aren't handled in a good way. You have to provide pre-allocated memory, guessing how big it is supposed to be. Then you get a "not big enough" error. This is a guessing game, not a good design. You're forced to overshoot, then shrink the buffer afterwards.
---
In different APIs, there tends to be a function you call to get the required buffer size. For example, many Win32 API functions make you call them with a buffer size of 0, then you get the actual required size back. Another possibility is having the library allocate the memory, and return the allocated buffer to you. Since cross-module memory management is hairy (different `malloc` implementations can't interoperate), some APIs let you provide the `malloc`, `realloc`, and `free` functions.
Until everything new is "optional". Hopefully PNG won't be the target of "enshitification". We all know that for file formats, there is a very strong pressure from developers and vendors for that to happen since it favors, hard, vendor and developer lock-in. If not careful, even with a team of PHD devs won't be able to write alternatives encoders/decoders that "reasonbly" and the world will end-up with very few alternatives implementations, if not only one.
I did skim through the specs, it seems most of it is related to cleanup and optional blocks, so it seems PNG is still safe, am I wrong? (asking those who did dive into the new specs deeply).
Everything new is optional. This is not a breaking change.
Old PNGs and software continue to work just fine.
And these new changes are backwards-compatible as much as they can be. So old software can display a new PNG and be mostly correct. By that I mean, the user will still say "it is a picture of a red apple". But if the software isn't HDR, they might not get the bright highlights and inky blacks of the HDR PNG.
Not 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.
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.
Could it be a lack of resources? Or some missing expertise? Maybe they could find some interns who are familiar with it? Maybe the entire world is so obsessed w AI, we don't even care about image formats anymore.
Honestly this kind of stuff happens all the time in large companies.
Interns won't want to work on a dead end like this. Moreso they need to be supervised by someone that doesn't want to get removed by being the lowest X% usefulness in a company. So all these existing tools that aren't primary revenue generators just sit on coast mode.
If you are using an image optimization service like Imgix / Cloudflare Image Resizing then it doesn't really matter, image can be uploaded as any supported format and will be sent to the end user according to their "Accept" header
Sure, ur then it’s my image viewer, my phones image viewer, the website I try and upload pictures to. This isn’t a problem you can solve by patching one application, and it’s not one the world as a whole cares about.
Better image formats serve entities who store images at scale, not end users.
> 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.
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.
File extensions are just a hint about what the file might be and have nothing to do with what the file actually is. If the server sets the MIME type, the browser will use that as the hint.
But even beyond that, most file formats have a bit of a header at the start of the file that declares the actual format of the file. Browsers already can understand that and use the correct render for a file without an extension.
Images are often at different resolutions too, that way, depending on the pixel density of the device, and the physical size, the browser can select the photo that has high enough resolution, but not one that is needlessly large, while also selecting the preferred image format.
I can tell you, I have personally worked with a global corporation and we estimated that for one of their websites, supporting the 3% that we exclude by using “modern standards” would be more costly than the amount of revenue they get from them. So in that case, it was a rational decision. And up to the 10% cut, management just didn’t want to do the extra investment. So if something falls below that 10% threshold, they just don’t care to get it fixed.
> it was a rational decision. And up to the 10% cut, management just didn’t want to do the extra investment
Rational, or economical? I find it rational to help someone in need since I'd want others to do the same to me, even if it's not financially profitable for me. Imo more factors flow into what's rational, but I understand what you mean by corporate greed working this way (less than 10% of people are blind, neither male nor female, run a free operating system or can't afford a new computer, etc., so yep they're not profitable groups and for-profits don't optimise for that)
You are using the notion of rationality wrong. Rational reasoning can only help you find how to achieve goals that align with your values. It is strictly worthless in choosing your values.
If a corporation has determined that profit maximization is their core tenet, excluding the needs of a minority of users can likely be deduced in a rational manner from that tenet. That is precisely why values need to be forced onto corporate actors through regulation, e.g. in this case through mandatory accessibility guidelines like EU directive 2019/882 that enters into force this very week.
Rational reasoning also takes into account long-term and second and higher order effects which quarterly profit-driven reasoning often ignores. If you support 95% of users and your competitor supports 100% then that may help your competitor getting 100% of them while you get none.
Something is off in this calculation, how did they get to such a high cost for such a simple thing as an alternative image format when the web supports multiple???
My guess would be that the users hitting different types of issues are mostly the same; someone who can't view an alternative image format is using an obscure old browser or obscure OS that will inevitably have a ton of other issues too, and fixing only a subset of the issues would not make much difference.
No, this was not about the alternative image format. This was about the browsers and screen resolutions that we choose to fully support.
We took the data directly from the website visitors analytics.
Basically .. resolutions under 1024px and anything older than edge 11 was left out of the scope.
In my experience, accessibility features are needed by about 1.5% of users (E-commerce and some internal business tools). So by your logic, the rational choice is to exclude accessibility?
Or Linux users? Or even Firefox users in our market?
Thanks for demonstrating why laws like ADA are needed to force companies to not be bad citizens. We desperately need similar laws to force compatibility with older hardware - one could even champion it under environmental protection.
I agree with the point you're trying to make, but your examples are terrible. Music industry doesn't have too much to do to help deaf people. It's not like they're deliberately making deaf-inaccessible music instead of relying on the old good deaf-accessible music formats.
(Also, the parent comment's example is also not so good because as someone else pointed just because the top 25% websites are serving webp it does mean they're not serving alternative formats for those who does not support it, as this is quite trivial to setup)
on the contrary. on macOS apps don't have to support image (or movie) formats. it is done by the system and transparently handled by the APIs. apps automatically gain new formats when the system adds it.
And having to bring in support for formats that are deprecated by the OS, if they decide to keep supporting that format as there is sufficient demand from their users, is worse than having to bring in support for all formats rather than getting support from the OS?
Having ask that in a slightly confrontational way, one of the reasons I started using VLC all those years ago, and still use it to this day, was having trouble with other media players that relied on OS support fail to work well (or at all) with some codecs, while VLC brought support for them, and their dog, built-in and reliable. Dragging your own format support libraries with you can be beneficial.
I meant Windows, as macOS and Linux are usually good with modern things. It’s trivial to add the support if you don’t have it. I have no idea about Windows, but I got this vibe of someone using Win7 in 2025 and complaining the world moved on and keeps moving on.
That doesn’t mean it’s dead, it rather shows sheer incompetence of the web dev departments of these wonderful companies for whom webp or avif aren’t images, I guess.
I'm convinced that this is because of the prevalent MVP culture in modern software engineering. Instead of holistically looking at a new feature request such as "support webp images" we break it down into parts (e.g. "serve webp" "accept webp upload here" "accept webp upload there") and then we call it a MVP when only the highest priority items are done.
Or convert before you upload because the image host has delusions about fighting the Google monoculture by refusing WebP support. Even more of a head scratcher when WebM is their only video format.
Not sure if that's version specific, but my one can (version 26.7.0) without any issues or warnings. Tried with this sample file: https://www.gstatic.com/webp/gallery/1.webp
I was about to write that Slack doesn't support webp but I just tested it and it does. For years I have been typing "convert file.webp file.jpg" and then posting that in slack but it looks like they have added support.
I could save my photos as BMPs like early digital cameras did but that doesn't make it practical or reasonable. My camera takes pictures as RAW or HEIF files. Why would I save my photos to a primarily lossy codec that's optimized and designed for distribution rather than preserving fidelity?
We used to do this with JPEG, in fact. And that's why many pictures on Facebook from pre-2018 or so all have a distinctive grainy look. It's artifacts on top of artifacts. Storage on phones isn't tight anymore, we don't need to store photos in a format meant to minimize bytes at the expense of quality.
There's more on Instagram than photos. Lotta meme pages, lot of people just uploading random screenshots and photos they downloaded that have been turned over a million times. Heck, all it takes is someone downloading their own photo from SocialMediaX to reupload on SocialMediaY, or just uploading a the WebP that they exported for their website.
Instagram hasn't even been primarily or even secondarily about photos for a long time. Indeed trying to "just" upload a photo is made super inconvenient these days.
Unless you're uploading memes you've downloaded from elsewhere, this strictly isn't true. I'd consider myself an Instagram power user and the only thing that I and all the people I interact with is photos and videos. None of those are webp, or would have been worthwhile to save as webp as an intermediate format.
Tangentially related but Instagram is really the worst plattform for photos. I don't understand why they crop and downsize (!) pictures. Not even Twitter does this, it's unironically a better photo plattform.
Maybe using VLC Media Player from an early age has left me with too high expectations.
But if I have a program designed to view or edit a certain class of file, and it doesn't support a certain file format, I will blame that program.
GIMP and Gwenview have supported webp (the latter via platform image plugins that add support to other applications as well) since before you encountered them online. Maybe choose better tools.
I don't really think this is the case here. All major browsers already support the new spec for example. This isn't a case of oh we'll have support for it eventually, it's already there.
> 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.
There's a big issue that all old popular image formats are 8-bits. 10-bits or even 12-bits would help a lot with storing more information and maintaining editability.
If adding more bits to an image format, please make it 'n bit'. Ie. the file could be 8 bit, it could be 10, it could be 12, it could be 60 bit!
Whilst we're at it, please get rid of RGB and make it N channels too.
Libraries can choose to render that into a 3 channel, 8 bit buffer for legacy applications - but the data will be there for CMYK or HDR, or depth maps, or transparency, or focus stacking, or any other future feature!
They say it's technically compatible since older image decoders should recognize the PNG file is using a different compression algorithm than the default.
> Many programs already support the new PNG spec: Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer...
This is intentionally ignoring the fact that there are countless PNG decoders out in the wild, many using libpng the standard decoder last updated 6 years ago; and they will not be able to read the new PNG v2 files.
They should have used a different file extension, PNG2, to distinguish this incompatible format. Otherwise, users will be confused why their newly saved PNG file cannot be read by certain existing programs.
Many Mac apps do not consider the file extension but instead look for marker bytes within the file. While the Finder might use the extension to determine which app to launch ("Oh, an image file, let's open Preview") the app that is passed the file (Preview) will then look for various marker bytes to decide if it is a JPEG, PNG, etc.
(I am told by a certain LLM that the first 8 bytes of a PNG are the marker bytes: "89 50 4E 47 0D 0A 1A 0A". This is apparently in libpng itself ... so perhaps any OS or tool updating to a newer pnglib will get the new format for free?)
Those are indeed the "magic" bytes of PNG. It's a very clever choice meant to ensure the transport layer didn't mess with it.
To start, there's a byte with the upper bit set which ensures an "8-bit clean" transport. If it's stripped, it becomes a harmless tab. Then the literal "PNG" text so you can see it in a text editor. Then a CR-LF pair to check for CR-LF to LF translations. Then, a CTRL-Z to stop display on DOS-like systems. And finally, another LF to check for LF to CR-LF translations.
It's a clever "magic" that basically ensures a binary transport layer. Things that mattered back in 1996.
It's clever but I'm not so sure it actually mattered - other formats have done just as well with simpler magic numbers. All it does in the end is that you get something that doesn't identify as a PNG file rather than a PNG file with bad data when a non-binary transport is used - both results are bad and immediately apparent.
Yes and no. It wasn't just about telling you a problem occurred, but failing early and being able to say exactly why. A "something in the chain is running in 7-bit mode" is more helpful than "CRC error in IDAT". Maybe the developers were being a bit too ambitious/hopeful, but an eight byte "magic" over a "simpler" four byte one isn't really worth crying over, even with 1996 download speeds.
The problem is when "HDR" images that would perfectly fit into the sRGB color space are not rendered correctly on non-HDR systems. This PNGv2 fails that which means it isn't really any more useful and one of the existing (and much better) HDR-supporting formats like JPEG-XL or the video codec based ones pushed by the big guys.
Someone who is aware of this issue can do that. Someone who just uses the standard export might not notice that their files are not backwards compatible. It might also be that most of the image fits into sRGB but a few highlights do not - having the whole image washed out because of those is also not good.
I miss the days of old Amiga OS 3.x, where you had installable "DataTypes" that any program could make use of. If we had that, then all such programs could at least be updated to basic compatibility by simply updating the datatype.
"Lossless WebP is typically 26% smaller than PNG, while lossy WebP can be 25-34% smaller than JPEG at equivalent quality levels"
This literally saves houndred of thousand of cost, bandwith, electricity every month on the internet. In fact, I strongly belive that this is one of the greatest contributions from Google to society just like ZSTD from Facebook.
"WebP is used by 16.7% of all websites. This means that while it's a popular image format, it's not yet the dominant format, with JPEG still holding the majority share at 73.0%, according to W3Techs. However, WebP offers significant advantages in terms of compression and file size, making it a preferred choice for many web developers. "
Image and video compression comparisons are like statistics with the right corpus and evaluation criteria you can should whatever narrative you want to push.
There are some applications for a new image format, but I agree that what we have is generally good enough.
We need good video formats however. Video makes up most of the global internet traffic, probably accounts for a good part of global storage capacity too. Even slightly better compression will have a massive impact.
It is very backwards compatible. I'm not sure why you thought that.
We jumped through quite a lot of hoops to make sure old software will be able to display new images. They simply won't display them optimally. But for the most part, that would be because the old software wouldn't display images optimally anyway. So the limit was the software, not the format.
What I mean by this is old software that treats everything as sRGB wouldn't correctly show a Display P3 image anyway. But we made sure it will still display the image as correctly as it could.
The sample HDR images don't show correctly in image viewers even though the colors used fit into the sRGB gamut (or at least have good approximations in there). That's not really backwards compatibility.
621 comments
[ 2.4 ms ] story [ 338 ms ] threadThis 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.
That being said, they also can do dumb things however, right at the end of the sentence you quote they say:
> we want to make sure we do it right.
So there's hope.
That's just changing an implementation detail of the encoder, and you don't need spec changes for that e.g. there are PNG compressors which support zopfli for extra gains on the DEFLATE (at a non-insignificant cost). This is transparent to the client as the output is still just a DEFLATE stream.
[1] https://github.com/w3c/png/issues/39#issuecomment-2674690324
Now, PNG datatype for AmigaOS will need upgrading.
It could be horrible in principle, but actually isn't.
https://svgees.us/blog/img/revoy-cICP-bt.2020.png uses the new colour space. If your software and monitor can handle it, you see better colour than I, otherwise, you see what I see.
The PNG format is specifically designed to allow software to read the parts they can understand and to leave the parts they cannot. Having an extensible format and electing never to extend it seems pointless.
Yeah, we know. That's terrible.
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, almost nobody fully implements MPEG-4 Part 3; the standard includes dozens of distinct codecs. Most software only targets a few profiles of AAC (specifically, the LC and HE profiles), and MPEG-1 Layer 3 audio. Next to no software bothers with e.g. ALS, TwinVQ, or anything else in the specification. Even libavcodec, if I recall correctly, does not implement encoders for MPEG-4 Part 3 formats like TwinVQ. GP's fear is exactly this -- that PNG ends up as a standard too large to fully implement and people have to manually check which subsets are implemented (or used at all).
Same is also true for the most advanced codecs. MPEG-* family and MP3 comes to my mind.
Nothing stops PNG from defining a "set of decoders", and let implementers loose on that spec to develop encoders which generate valid files. Then developers can go to town with their creativity.
Proprietary or open, any visual codec is a battleground. Even in commercial settings, I vaguely remember people saying they prefer the end result of one encoder over another, for the same video/image format, not unlike how photographers judge cameras by their colors.
So maybe, this flexibility to PNG will enable or encourage people to write better or at least unorthodox encoders which can be decoded by standard compliant ones.
Regarding the potential for fragmentation of the png ecosystem the alternative is a new file format which has all the same support issues. Every time you author something you make a choice between legacy support and using new features.
From a developer perspective, adding support for a new compression type is likely to be much easier than implementing logic for an entirely new format. It's also less surface area for bugs. In terms of libraries, support added to a dependency propagates to all consumers with zero additional effort. Meanwhile adding a new library for a new format is linear effort with respect to the number of programs.
Not Sure what youre talking abouz.
If you want to check yours: mediainfo **/*.mp4 | grep -A 2 '^Audio' | grep Format | sort | uniq -c
https://en.wikipedia.org/wiki/TwinVQ#TwinVQ_in_MPEG-4 tells the story of TwinVQ in MPEG-4.
And now think of the younger generation that has grown up with smartphones and have been trained to not even know what a file is. I remember this story about senior high school students failing their school tests during covid because the school software didn't support heif files and they were changing the file extension to jpg to attempt to convert them.
I have no trust the software ecosystem will adapt. For instance the standard libraries of the .net framework are fossilised in the world of multimedia as of 2008-ish. Don't believe heif is even supported to this day. So that's a whole bunch of code which, unless the developers create workarounds, will never support a newer png format.
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 ...
Has anyone ever used .exe for anything other than Windows?
Under Windows 95/98/Me, most command line tools were MS-DOS executables. Their support for 32-bit Windows console apps was very poor, to the extent that the input and output of such apps was proxied through a 16-bit MS-DOS executable, conagent.exe
First time in my life I ever used GNU Emacs, it was an OS/2 exe. That's also true for bash, ls, cat, gcc, man, less, etc... EMX was my gateway drug to Slackware
Did you know that Microsoft Windows originally ran on top of the much older MS-DOS, which used EXE files as one of its two executable formats? Most Windows users had lots and lots of EXE files which were not Windows executables, but instead DOS executables. And then came Windows 95, which introduced 32-bit Windows executables, but kept the same file extension as 16-bit Windows executables and 16-bit DOS executables.
If you've created an extensible file format, but you never need to extend it, you've done everything right, I'd say.
That's what I would call really extensible, but then there may be no limits and hacking/viruses could have easily a field day.
Will sooner or later be used to implement RCEs. Even if you could do a restriction as is done for eBPF, that code still has to execute.
Best would be not to extend it.
So then it was pointless for PNG to be extensible? Not sure what your argument is.
In an ideal world, yes. In practice however, if some field doesn't change often, then software will start to assume that it never changes, and break when it does.
TLS has learned this the hard way when they discovered that huge numbers of existing web servers have TLS version intolerance. So now TLS 1.2 is forever enshrined in the ClientHello.
And considering we already have plenty of more advanced competing lossless formats, I really don't see why "feed a BMP to deflate" needs a new, incompatible spin in 2025.
Other than JXL which still has somewhat spotty support in older software? TIFF comes to mind but AFAIK its size tends to be worse than PNG. Edit: Oh right OpenEXR as well. How widespread is support for that in common end user image viewer software though?
More generally, PNG has a simple feature to specify what's needed. A file consists of a number of chunks, and one bit in the chunk specifies whether that chunk is required for display. All of the extensions I've seen in the past decades set that bit to "optional".
For example, this update includes a chunk containing EXIF data. As you'd expect, the exif chunk sets that bit to "optional".
https://pico-8.fandom.com/wiki/P8PNGFileFormat
Actual cases of proprietary chunks include iDOT from Apple (apparently a performance optimization for plain images)
https://www.hackerfactor.com/blog/index.php?/archives/895-Co...
and the Macromedia Fireworks save files
https://stackoverflow.com/questions/4242402/the-fireworks-pn...
EG your GPU and monitor both have a USB-C port. Plug them together with the right USB cable and you'll get images displayed. Plug them together with the wrong USB cable and you won't.
USB 3 didn't have this issue - every cable worked with every port.
I believe the problem here is that you will have PNG images that “look” like you can open them but can’t.
If PNG gets extended, it's entirely plausible that someone will view a PNG in their browser, save it, and then not be able to open the file they just saved.
There are those who claim "backwards compatibility" doesn't cover "how you use it" - but roughly none of the people who now have to deal with broken software care about such semantic arguments. It used to work, and now it doesn't.
Do they mention which C libraries use this spec?
USB-C spec is anything but breaking backward compatible.
It's a dichotomy. Either the provider accommodates users with older software or not. The file extension or internal headers don't change that reality.
Another example, new versions of PDF can adopt all the bells and whistles in the world but I will still be saving anything intended to be long lived as 1/a which means I don't get to use any of those features.
This is just pretending that if you have a cat and a dog in two bags and you call it “a bag”, it’s one and the same thing…
Labelling is a poor band-aid on the root problem - consumer cables which look identical and fit identically should work wherever they fit.
There should never have been a power-only spec for USB-C socket dimensions.
If a cable supports both power and data, it must fit in all sockets. If a cable supports only power it must not fit into a power and data socket. If a cable supports only data, it should not fit into a power and data socket.
It is possible to have designed the sockets under these constraints, with the caveat that they only go in one way. I feel that that would have been a better trade-off. Making them reversible means that you cannot have a design which enforces cable type.
Well, yes.
Why can't you use a power+data cable for the vape (or whichever appliance takes both)? What's the deal-breaker here?
The alternative is labeling, or plugging cables in to see if they do what you want them to do.
Both are a poor user interface.
That's even more confusing than the current state of affairs. If my phone has power and data socket, then I cannot use power only cable to only charge it? Presumably with the charger that has power only socket. So I need a cable with two different ends anyway. Just go micro-USB at this point :)
Funnily enough, there is a 100% overkill way to solve such issues. Just use super expensive certified TB cables. Well... plus a A-to-C adapter for noncompliant devices, I guess.
What was broken was the promise of a "single cable to rule them all", partly due to manufacturers ignoring the requirements of USB-C (missing resistors or PD chips to negotiate voltages, requiring workarounds with A-to-C adapters), and a myriad of optional stuff, that might be supported or not, without a clear way to indicate it.
You don't follow spec, you're on your own.
> Many of the programs you use already support the new PNG spec: Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer...
It might be too late to rename png to .png4 or something. It sounds like we're using the new png standard already in a lot of our software.
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 new files. And teaching people that sRGB maybe isn't good enough any more. That's going to be hard since most people have no clue about color spaces.
Anyway, that gives everybody plenty of time to upgrade. By the time this stuff is widely used, it will be widely supported. So, you kind of get forward compatibility that way. Your browser already supports the new format. Your image editor probably doesn't.
This is news to me. I'm pretty sure the main use case for PNG is lossless transparent graphics.
There are about 3.6 billion people surfing the web and experiencing PNGs. That use case, consuming PNGs, seems to dwarf the perhaps 100 million (somewhat wild guess) graphic designers, web developers, and photo editing professionals who manipulate images for publishing (in any medium) or archiving.
If, on the other hand, you're considering the use cases envisioned by PNG's creators, or the use cases that interest the people processing or publishing images, yes, these people are focused on format itself and its capabilities.
I suspect this particular use of "use case" isn't terribly clear. Also these two considerations are not incompatible.
It's not, most images you encounter on the web need better compression.
The main PNG use case is to store lossless images locally as master copies that are then compressed or in workflows where you intend to edit and change them where compressed formats would degrade the more they were edited.
Also if you forbid evolving existing formats, the only alternative to improve is to introduce a new format, and I argue that it would be causing even more fragmentation and be more difficult to adopt to. Look at all the drama surrounding JPEG XL.
I’m not saying this is what will happen — but if I was able to construct a plausible approach to compression in ten minutes, then perhaps it’s a bit early to predict the doom of compatibility.
The first bit of our research is "What can we already make use of which requires no spec update? There are plenty of PNG optimizers. How much of that should go into the typical PNG libraries?"
Same with parallel encoding & decoding. An older image viewer will be able to decode it on one thread without ever knowing parallel decoding was an option.
Here's the worry-a-little part: Everybody immediately jumps to file size as to what image compression is better or worse. That isn't the best take, but it is what it is. So there is pressure to adopt newer technologies.
We often do have a way to maintain some degree of backwards compatibility even when we do this. For example, we can store a downsampled image for old viewers. Then extra, new chunks will know "Mix that with this full scale data, using a different compression".
As you can imagine, this mixing complicates things. It might not be the best option. Sooooo we're researching it :)
[0] https://svgees.us/blog/cICP.html
cICP is 16 bytes for identifying one out of a "list of known spaces" but they chose not to include a couple of the most common ones. Off to a great start...
I wonder if it's some kind of legal issue with Adobe. That would also explain why EXIF / DCF refer to Adobe RGB only by the euphemism "optional color space" or "option file". [1]
[1] https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_sy...
Maybe iccMAX supports HDR. I'm not sure. In either case, that isn't what PNG supported.
So something new was required for HDR.
How so? As far as I can tell, the ICCv2 spec is very agnostic as to the gamut and dynamic range of the output medium. It doesn't say anything to the extent of "thou shalt not produce any colors outside the sRGB gamut, nor make the white point too bright".
Unless HDR support is supposed to be something other than just the primaries, white point, and transfer function. All the breathless blogspam about HDR doesn't make it very clear what it means in terms of colorspaces.
I don't doubt that there's lots of problems in the chain from RGB samples to display output, but I'm finding this whole thing horribly confusing. Wikipedia tries to distinguish 'HDR' transfer functions like PQ [0] from 'SDR' transfer functions in terms of their absolute luminance, but the ICC specs are just filled with relative values all the way down.
(Not to mention how much these things get fiddled with in practice. Once, I had the idea of writing a JPEG decoder, so I looked into how exactly to convert between sRGB and Rec. 601 YCbCr coordinates. I thought, "I know, I'll just use the standard-defined XYZ conversions to bridge between them!" But psych, the ICC sRGB profile has its own black point scaling that the standards don't tell you about. I'm still not sure what the correct answer is for "these sRGB coordinates represent the exact same color as these Rec. 601 YCbCr coordinates".)
[0] https://en.wikipedia.org/wiki/Perceptual_quantizer
Here is what I can tell you confidently: The original plan was to provide an ICC profile that approximates PQ as best as we could. But it wasn't enough. So the proposal was to force the profile name to be a special string. When a PNG decoder saw that name, it would ignore the ICC profile and do actual PQ.
Here is that original proposal: https://w3c.github.io/png-hdr-pq/
Possibly more context (I just found this) from Apple. I'm not sure of date: https://www.color.org/hdr/02-Luke_Wallis.pdf Slide 29: "HDR parametric transfer functions not in ICC spec Parametric 3D tone mapping functions not in ICC spec - Neither can be approximated by 1-D or 3-D LUTs"
I'm not sure why they cannot be approximated by LUT. Maybe because of the inversion problem?
- In ICC-land, all luminances are relative to the display's (or reflective medium's) black and white points. So for an HDR-capable display, all content, HDR or SDR, would be naturally displayed at the full 10k nits or whatever the actual number is. This is obviously not how things work in practice: OSes and/or displays really want a signal as to whether the full HDR luminance is actually desired. (This reminds me of an earlier HN thread where people complained about HDR video forcing up the brightness on Apple devices.)
- PQ (but not HLG) specifies everything in terms of absolute luminance, but this gets confusing when people want to adjust their display brightness and have everything work relatively in practice.
- Due to lack of support for "overrange" behavior [1], 1D LUTs + matrices are insufficient for representing PQ at all, so you need a 3D LUT just to approximate it. This needs ICCv4, since ICCv2 only supports 3D LUTs for non-display profiles.
- But 3D LUTs are big and fat, and can only give a few bits of accuracy across some parts of the full HDR range. (It seems like there's no form of delta compression?) Most people really hate this. iccMAX can allegedly use 3D parametric formulas, but literally no one implements it since it has a million bells and whistles.
- More importantly, GPUs especially hate big fat LUTs, and everyone uses GPU rendering. In the worst case, some implementations will do everything they can to ignore LUTs in ICC profiles, and instead try to guesstimate some simple-gamma or linear-gamma approximation, which won't end well.
So it does seem to be a combination of "the HDR stack is a mess and needs its own special signaling" and practical concerns about avoiding overly huge profiles.
[0] https://lists.w3.org/Archives/Public/public-colorweb/2017May...
[1] https://lists.w3.org/Archives/Public/public-colorweb/2017May...
That’s precisely what makes it unsuitable for HDR. With PQ, (1, 1, 1) means 10 000 cd/m² – if you simply create an ICC profile with the PQ transfer function, an image that looks right on a hypothetical 10 000 cd/m² monitor will look way too dim when naïvely scaled down (as ICC-type colour management would have you do) to the 300 cd/m² of a typical monitor. HLG, meanwhile, has a transfer function that depends on the peak luminance, which is not possible to do with ICC (the profile would have to assume a specific peak luminance), and the reason that it does that is to preserve the subjective perception of the image.
So, sure, you can prepare an HDR image so that it looks right on a monitor with a 1000 cd/m² peak luminance, describe the colorspace in relative terms using an ICC profile, and you will have “done HDR using ICC”, but that’s arguably a very low bar for “supporting HDR”.
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.
Yes. Relevant animation elements:
• <set>
• <animate>
• <animateTransform>
• <animateMotion>
See https://www.w3schools.com/graphics/svg_animation.asp
Given how often it is used as a jargon term in software development, I can absolutely see this usage of "use-case" here as a "vote" for the next step in the process. Will we eventually see "usecase" become common? It's possible. I think it might even be a good idea. I'm debating adding my own "votes" for the hyphen moving forward.
Most other SVG renderers don't support much CSS.
This could possibly be used to build full fledged games like pong and breakout :)
https://shkspr.mobi/blog/2025/06/an-annoying-svg-animation-b...
Can animated PNG beat av1 or whatever?
[0] like for example these old Windows animations: https://www.randomnoun.com/wp/2013/10/27/windows-shell32-ani...
https://trac.ffmpeg.org/wiki/Encode/AV1#Losslessencoding
The AV1 spec [1] does not allow RGB color spaces, therefore AV1 cannot preserve RGB animations in a bit-identical fashion.
[1] https://aomediacodec.github.io/av1-spec/av1-spec.pdf
It is a bit-reversible rotation of the RGB cube. It makes the channels look more like luma and chroma that the codec expects.
8-bit YCoCg (even when using the reversible YCoCg-R [1] scheme) cannot represent 8-bit RGB losslessly. The chroma channels would need 9 bits of precision to losslessly recover the original 8-bit RGB values.
[1] https://www.microsoft.com/en-us/research/wp-content/uploads/...
It's also possible to directly encode RGB (channels ordered as GBR) when you set identity matrix coefficients, it's just less efficient.
I've implemented this in my AVIF encoder, so I know what I'm saying.
For video content maybe. Pixel-art gifs are not something video codecs do well at without introducing lots of artifacts.
Animated PNGs can't beat GIF nevermind video compression algorithms.
In APNG it's either the same 256 colors for the whole animation, or you have to use 24-bit color. That makes the pixel data 3 times larger, which makes zlib's compression window effectively 3 times smaller, hurting compression.
OTOH GIF can add 256 new colors with each frame, so it can exceed 256 colors without the cost of switching all the way to 16.7 million colors.
Not entirely true, it depends on what's being displayed, see a few simple tests specifically constructed to show how much better APNG can be vs GIF and {,lossy} webp: http://littlesvr.ca/apng/gif_apng_webp.html
Of course I don't think it generalizes all that well…
edit: using the same ezgif webp and apng on a H.264 source, apng is suddenly 10x the size than webp. It seems apng is only better if the source is gif
That's not really true. Some websites lie to you by putting .gif in the address bar but then serving a file of a different type. File extensions are merely a convention and an address isn't a file name to begin with so the browser doesn't care about this attempt at end user deception one way or the other.
I'm not sure why people disagree so strongly with what I wrote. Worst case scenario is that it's a slightly tangential but closely related rant about deceptive web design practices. Best case scenario is that someone who thought some sort of fancy trick involving gifs was in use learns something new.
They just don't have a proper UI and JS APIs exposed, and there's nothing stopping them from adding that.
IMO browsers are just stuck with tech debt, and maintainin a no-longer-relevant distinction between "animations" and "videos". Every supported codec should work wherever GIF/APNG work and vice versa.
It's not even a performance or complexity issue, e.g. browsers support AVIF "animations" as images, even though they're literally fully-featured AV1 videos, only wrapped in a "pretend I'm an image" metadata.
Browsers should just allow animated gifs and apngs in <video>
It's a shame that browser vendors didn't add silent looping video support to the img tag over (imo) baseless concerns.
SVG is just html5, it has full support for CSS, javascript with buttons, web workers, arbitrary fetch requests, and so on (obviously not supported by image viewers or allowed by browsers).
If you use an <img> tag, svgs are loaded in "restricted" mode. This disables scripting and external resources. However animation via either SMIL or CSS is still supported.
Nowadays, AVIF serves that purpose best I think.
AVIF is only starting to become widespread so can't be used without fallback if you care about your users. Not sure how it compares to AV1 quality/compression wise but hopefully its not as gimped as webp and there will encoders that aren't as crap as libwebp that almost everyone uses.
The fact that we have the <img> element at all is bad. HTML has since the early days a perfectly capable <object> which can even be nested to provide fallback, but browser support was always spotty.
The Acid2 test famously used <object> to shame browser vendors into supporting it at least to some extent.
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.
No, it's limited to 256 colors per frame and frames can have duration 0 which allows you to combine multiple frames into more than 256 color images.
I'm not sure about the tools and DX around animated PNGs. Is that a thing?
You can even have one frame that gets shown if and only if animation is not supported.
It is never shown by compliant apng decoders. You can make it the first frame of the animation, or any other image you want. e.g. some text saying "APNG unsupported"
Not progressively though unless browsers add a new mime type for it which they did not bother to do with animated webp.
Probably the best news here. While you already can write custom data into a header, having Exif is good.
BTW: Does Exif have a magnetometer (rotation) and acceleration (gravity) field? I often wonder about why Google isn't saving this information in the images which the camera app saves. It could help so much with post-processing, like with leveling the horizon or creating panoramas.
Old decoders and new decoders now could render an image with exif rotation differently since it's an optional chunk that can be ignored, and even for new decoders, the spec lists no decoder recommendations for how to use the exif rotation
It does say "It is recommended that unless a decoder has independent knowledge of the validity of the Exif data, the data should be considered to be of historical value only.", so hopefully the rotation will not be used by renderers, but it's only a vague recommendation, there's no strict "don't rotate the image" which would be the only backwards compatible way
With jpeg's exif, there have also been bugs with the rotation being applied twice, e.g. desktop environment and underlying library both doing it independently
The camera knows which way it's oriented, so it should just write the pixels out in the correct order. Write the upper-left pixel first. Then the next one. And so on. WTF.
If a smartphone camera is doing it, then bad camera app!
This is particularly important on smartphones and battery operated devices. However, most smartphone devices simply save the photo the same way regardless of orientation, and simply add a display-rotated flag to the metadata.
It can be super annoying sometimes, as one can't really disable the feature on many devices. =3
It's basically a shame that the exif metadata contains things that affect the rendering
Could you explain this one?
What are the arguments for this? It would seem easier for everyone to rotate and then store exif for the original rotation if necessary.
Performance. Rotation during rendering is often free, whereas the camera would need an intermediate buffer + copy if it's unable to change the way it samples from the sensor itself.
The hardware likely is optimized for the common case, so I would think that can be a lot slower. It wouldn’t surprise me, for example, if there are image sensors out there that can only be read out in top to bottom, left to right order.
Also, with RAW images and sensors that aren’t rectangular grids, I think that would complicate RAW images parsing. Code for that could have to support up to four different formats, depending on how the sensor is designed,
Your raw-image idea is interesting. I'm curious as to how photosites' arrangement would play into this.
RAW images aren't JPEGs so not relevant to the discussion.
Exif fields: https://exiv2.org/tags.html
And is being able to read an image without an opt-in tag something that has to be explicitly enabled in the reference implementation's API?
You could store this in Exif.Photo.MakerNote: "A tag for manufacturers of Exif writers to record any desired information. The contents are up to the manufacturer." I think it can be pretty big, certainly more than enough for 9 DoF position data.
"photo scanned in 2025, is about something in easter, before 1940 and after 1920"
The usual sidecar files, XMP files, are standardised (in that they follow a certain extensible XML structure) and can (and often do) include EXIF file information.
[0] https://en.wikipedia.org/wiki/Extensible_Metadata_Platform
For ambiguous dates there is the EDTF Spec[1] which would be nice to see more widely adopted.
[0] https://www.media.mit.edu/pia/Research/deepview/exif.html
[1] https://www.loc.gov/standards/datetime/
Different software reacts in different ways to partial specifications of yyyy/mm/dd such that you can try some of the cute tricks but probably only one s.w. package honours it.
And the majors ignore almost all fields other than a core set of one or two, disagree about their semantics, and also do wierd stuff with file name and atime/mtime.
Pleasantly surprised.
PNG is popular with some Commercial Application developers, but the exposure and color problems still look 1980's awful in some use-cases.
Even after spending a few grand on seats for a project, one still gets arrogant 3D clown-ware vendors telling people how they should run their pipeline with PNG hot garbage as input.
People should choose EXR more often, and pick a consistent color standard. PNG does not need yet another awful encoding option. =3
A very basic rec.709 workflow tutorial:
https://www.youtube.com/watch?v=lf8COHAgHJs
The Andreas Dürr LUT pack:
https://www.youtube.com/watch?v=dDKK54CeXgM
https://cinematiccookie.gumroad.com/l/bseftb?layout=profile
The calibration workflows also depend heavily on what is being rendered, source application(s), and the desired content look. There were some common free packs on github for popular programs at one time. Should still be around someplace... good luck. =3
What are you talking about? It's a bitmap. It has nothing to do with "exposure and color problems."
If you've never encountered the use-case, than don't worry about the aesthetics. Seriously, many vendors also just don't care... especially after they already were paid. Best of luck =3
I think your experience is with some tool that made bad PNGs. That is a problem with the tool, not the format.
Have a look at a tutorial that dives into the basic details, and consider learning something:
https://www.youtube.com/watch?v=pLt1230dtYE
https://www.youtube.com/watch?v=mb0b83MML78
https://www.youtube.com/watch?v=egtnkhuUe_E
PNG has its use-cases, and some people do expect that baked color-space garbage look given it dominates a lot of low-end media. Have a great day =3
In the first video, the person loads the image and manually chooses a gamma transfer function with 2.2. If that was then saved, it would produce the washed-out fireball you mentioned.
In the second video, the person loads the image and manually chooses rec.709, which is also gamma tf and also produces washed-out fireball. In fact, the EXR image he loads literally has a bright fireball and you see it get washed out.
If you want to make claims about EXR being better than PNG, you need to say why storing the values as floating point is better than integer. But the blown-out fireball example is just incorrect. As evidence, I'll point to HDR. ANYTHING you see in an HDR movie is now 100% losslessly reproducible in a PNG.
However, I still trust the ILM engineers over your pet project, and maligned post that reeks of LLM slop.
The argument of making cow from hamburger doesn't hold true under our use-cases. You were shown the path, and it is your choice to put in the work to learn something important.
Best of luck kid =3
After 20 years of success, we can't resist the temptation to mess with what works.
It has, but WWW is still de facto sRGB, and will be for a long time still. But again, I'm not strictly opposed to evolving PNG, I just hope they don't ruin it in the process, because that's usually what happens when something gets update for a modern audience. I'll be watching with mixed optimism and concern.
The continued popularity of non-HDR 1080p screens on laptops is a bleak reminder that most people would rather save a couple hundred bucks than buy HDR capable hardware.
HDR is great for TVs and a nice-to-have on phones (who mostly get it for free because OLEDs are the norm these days), but display technology only advances as much as its availability in low-cost devices.
Not sure how HDR encoding works, but my impression is that you can set a nominal white point other than (1, 1, 1) in your specified colorspace. This is an extension, but orthogonal to specifying the colorspace itself and the gamut.
But wide color gamut was already possibly in PNG via ICC profiles (HDR was not). And those primaries I showed could have been used in a wide color image.
So the image is a bit misleading or red-flag-y to experts who know. But to the average person, I think it is as truthful as I can be without getting too deep in the weeds.
For example 16bit (integer) TIFF files 'with headroom', i.e. where some bits were used to represent data over 1.0 (HDR) was a common approach for VFX work in the 90's.
16bit float TIFF is also thing since 33 years. Adobe DNG is modeled after TIFF. High end offline renderers have traditionally been using TIFF (with mip-maps) to store textures.
TIFF supports tags so primaries and white point or a known color space name can be stored in the file.
The format is so versatile, it is used everywhere.
And of course it also supports indexed color, i.e. a non-negotiable feature at the time PNG was introduced.
PNG was meant to replace GIF. Instead of looking what was already there some group of "experts" and "enthusiasts" (quote Wikipedia) succumbed to their NIH complexes. If licensing/patent woes over compression algorithms had been a motivator, why not just add a new one to TIFF?
The fact that PNG stores straight/unpremultiplied alpha says everything if you know anything about imaging in computer graphics.
And the fact that the updated format spec just released didn't address this tells you everything you need to know about the group in charge of that, today.
PNG is the VHS of image formats. It should have never seen the light day of in the first place nor the adoption it did.
Yeah, I love the fact that you can embed a PDF file inside a TIFF.
> And the fact that the updated format spec just released didn't address this tells you everything you need to know about the group in charge of that, today.
What does it say? That they are naive or have the wrong priorities? Their rationale for this seems quite reasonable to me: https://www.w3.org/TR/PNG-Rationale.html#R.Non-premultiplied...
E.g. an associated pixel with the 8bit/channel RGBA value 255, 0, 0, 0 (glowing red).
Because PNG can only store associated data a reader must associate before displaying. And that will give you a value of 0, 0, 0 after (black instead of additive red). See e.g. [1] why this matters.
Additionally the PNG spec does not specify if the alpha is linear. Some PNG readers/writer assume it is, some assume it has gone through/should go through an sRGB transfer curve instead. It mostly works until it doesn't.
The fact that the spec. doesn't specify which one it should be is another telltale sign that it was written by people unaware of the subtleties of image processing.
I understand that unassociated alpha gives you more precision in 8bit and since people wanted to e.g. store color ramps (with alpga) in PNG at the time (pre-SVG) and most image processing software (i.e. mainly Photoshop then) would not dither gradients for 8bit, this really mattered.
But it's 2025. And when 16bit PNG got introduced this should have definitely had associated (and explicitly linear) alpha.
[1] https://academysoftwarefdn.slack.com/archives/C05782U3806/p1...
Quote the relevant section, Slack requires a log-in.
> Additionally the PNG spec does not specify if the alpha is linear.
Section 12.1 of the PNG spec seems to specify exactly that: “gamma does not apply to alpha samples; alpha is always represented linearly.”
They do not mention precision at all in their rationale for that: “We standardized on non-premultiplied alpha as being the lossless and more general case.”
> And when 16bit PNG got introduced...
PNG has supported 16-bits per component since it was first introduced (see version 1.0 of the spec or RFC 2083).
How is this "more general"? Unpremultiplied is actually lossy (not so as far as precision goes but critically so if you talk about meaning/information).
> PNG has supported 16-bits per component since it was first introduced (see version 1.0 of the spec or RFC 2083).
True, my bad. But there have been many updates to the spec over the years.
I btw found a mention of alpha to be assumed to be linear in [1] but in a comment in a sample code snippet.
Quote:
/*
* Compositing is necessary.
* Get floating-point alpha and its complement.
* Note: alpha is always linear; gamma does not
* affect it.
*/
On the note of alpha: [2] is a good piece to read to understand why this matters, specifically the section "PNG cannot store all clamped linear values…".
[1] https://www.w3.org/TR/PNG-Encoders.html#E.Alpha-channel-crea...
[2] https://www.realtimerendering.com/blog/png-srgb-cutoutdecal-...
How can you call this basic fail a success?
Back then, there were no libraries in C# for it, but it's actually quite easy to make APNG from PNGs directly by writing chunks with correct headers, no encoders needed (assuming PNGs are already encoded as input).
https://github.com/NightElfik/Malsys/blob/master/src/Malsys....
https://marekfiser.com/projects/malsys-mareks-lsystems/
While I welcome that there is now PNG with animations, I am less impressed about how Mozilla chose to push for it.
Using PNG's magic numbers and pretend to existing software that it is just normal PNG? That is the same mindset that lead to HTML becoming tag soup. After all, HTML with a <blink> tag is still HTML, no?
I think they could have achieved animated PNG standardization much faster with a more humble and careful approach.
I'm retired and making zero money here. (I'm actually losing money on it. Wish I had a company sponsoring me for the flights and hotels for meetups.)
All participants are required to not patent any piece of it. We work hard to make sure we only reference open standards. (This one is quite tricky. We have to convince other standard orgs to make their stuff free.)
I could see the argument for getting around a gate. But fwiw I don't think that's the case :)
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 buffer sizes aren't handled in a good way. You have to provide pre-allocated memory, guessing how big it is supposed to be. Then you get a "not big enough" error. This is a guessing game, not a good design. You're forced to overshoot, then shrink the buffer afterwards.
---
In different APIs, there tends to be a function you call to get the required buffer size. For example, many Win32 API functions make you call them with a buffer size of 0, then you get the actual required size back. Another possibility is having the library allocate the memory, and return the allocated buffer to you. Since cross-module memory management is hairy (different `malloc` implementations can't interoperate), some APIs let you provide the `malloc`, `realloc`, and `free` functions.
I did skim through the specs, it seems most of it is related to cleanup and optional blocks, so it seems PNG is still safe, am I wrong? (asking those who did dive into the new specs deeply).
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.
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.
Edit: and good luck uploading the format to the majority of webforms that aren’t faang.
Interns won't want to work on a dead end like this. Moreso they need to be supervised by someone that doesn't want to get removed by being the lowest X% usefulness in a company. So all these existing tools that aren't primary revenue generators just sit on coast mode.
Let’s also not forget the dependency mess that leaves in applications before we do though..
Better image formats serve entities who store images at scale, not end users.
In what other industry would it be considered acceptable to exclude 5% of visitors/users/clients?
https://caniuse.com/webp
Note that I'm looking at "all tracked," which excludes 2% "other" browsers in the data whose featureset is not known.
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:
Will say though that it's not universal, it depends heavily on the corner of the internet you're on.
But even beyond that, most file formats have a bit of a header at the start of the file that declares the actual format of the file. Browsers already can understand that and use the correct render for a file without an extension.
Images are often at different resolutions too, that way, depending on the pixel density of the device, and the physical size, the browser can select the photo that has high enough resolution, but not one that is needlessly large, while also selecting the preferred image format.
See CSS image-set : https://developer.mozilla.org/en-US/docs/Web/CSS/image/image...
Rational, or economical? I find it rational to help someone in need since I'd want others to do the same to me, even if it's not financially profitable for me. Imo more factors flow into what's rational, but I understand what you mean by corporate greed working this way (less than 10% of people are blind, neither male nor female, run a free operating system or can't afford a new computer, etc., so yep they're not profitable groups and for-profits don't optimise for that)
If a corporation has determined that profit maximization is their core tenet, excluding the needs of a minority of users can likely be deduced in a rational manner from that tenet. That is precisely why values need to be forced onto corporate actors through regulation, e.g. in this case through mandatory accessibility guidelines like EU directive 2019/882 that enters into force this very week.
Or Linux users? Or even Firefox users in our market?
As for Linux users… I do recall they were even less than the 3%. Firefox users were more tho.
In any case, I’m almost sure most Linux users were fine. We just didn’t wanted to support old browsers.
e.g. cars - not everyone is physically able to drive books - blind people can't read music - deaf people can't hear
It is a form of 80/20 or 90/10 rule the last small percentage costs as much as the majority.
(Also, the parent comment's example is also not so good because as someone else pointed just because the top 25% websites are serving webp it does mean they're not serving alternative formats for those who does not support it, as this is quite trivial to setup)
One example is Sony's SRF camera raw format.
Programs like Photoshop and Affinity have to bring their own decoders where previously none were required.
Having ask that in a slightly confrontational way, one of the reasons I started using VLC all those years ago, and still use it to this day, was having trouble with other media players that relied on OS support fail to work well (or at all) with some codecs, while VLC brought support for them, and their dog, built-in and reliable. Dragging your own format support libraries with you can be beneficial.
It doesn't matter if the alternative is technically superior once the majority use the mainstream thing.
There are so many uneven areas of Reddit where WebP doesn't work. Old reddit, profile support, mod tools, etc.
My webcrawler sucks down a lot of WebP images, at least it did before it got the smackdown from Cloudflare.
Hell, for some software features (like stickers in some chat apps), WebP is mandatory.
HEIFF files, on the other hand...
We used to do this with JPEG, in fact. And that's why many pictures on Facebook from pre-2018 or so all have a distinctive grainy look. It's artifacts on top of artifacts. Storage on phones isn't tight anymore, we don't need to store photos in a format meant to minimize bytes at the expense of quality.
Photoshop still won’t open it, MacOS preview opens it but then demands to convert it to tiff when you try to edit it
> 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.
Whilst we're at it, please get rid of RGB and make it N channels too.
Libraries can choose to render that into a 3 channel, 8 bit buffer for legacy applications - but the data will be there for CMYK or HDR, or depth maps, or transparency, or focus stacking, or any other future feature!
They say it's technically compatible since older image decoders should recognize the PNG file is using a different compression algorithm than the default.
> Many programs already support the new PNG spec: Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer...
This is intentionally ignoring the fact that there are countless PNG decoders out in the wild, many using libpng the standard decoder last updated 6 years ago; and they will not be able to read the new PNG v2 files.
They should have used a different file extension, PNG2, to distinguish this incompatible format. Otherwise, users will be confused why their newly saved PNG file cannot be read by certain existing programs.
(I am told by a certain LLM that the first 8 bytes of a PNG are the marker bytes: "89 50 4E 47 0D 0A 1A 0A". This is apparently in libpng itself ... so perhaps any OS or tool updating to a newer pnglib will get the new format for free?)
To start, there's a byte with the upper bit set which ensures an "8-bit clean" transport. If it's stripped, it becomes a harmless tab. Then the literal "PNG" text so you can see it in a text editor. Then a CR-LF pair to check for CR-LF to LF translations. Then, a CTRL-Z to stop display on DOS-like systems. And finally, another LF to check for LF to CR-LF translations.
It's a clever "magic" that basically ensures a binary transport layer. Things that mattered back in 1996.
https://www.libpng.org/pub/png/spec/1.2/PNG-Rationale.html#R...
There's a PR for APNG: https://github.com/pnggroup/libpng/pull/706 – it seems there was some work for HDR in e.g. https://github.com/pnggroup/libpng/pull/635 as well. Related: https://github.com/pnggroup/libpng/issues/507
https://www.libpng.org/pub/png/libpng.html
Looks like this is the proper location for the project.
https://libpng.sourceforge.io/
You'll never be able to faithfully represent an HDR image on a non-HDR system, but you'll still see an image.
What about it?
"Lossless WebP is typically 26% smaller than PNG, while lossy WebP can be 25-34% smaller than JPEG at equivalent quality levels"
This literally saves houndred of thousand of cost, bandwith, electricity every month on the internet. In fact, I strongly belive that this is one of the greatest contributions from Google to society just like ZSTD from Facebook.
https://developers.google.com/speed/webp/docs/webp_study
"WebP is used by 16.7% of all websites. This means that while it's a popular image format, it's not yet the dominant format, with JPEG still holding the majority share at 73.0%, according to W3Techs. However, WebP offers significant advantages in terms of compression and file size, making it a preferred choice for many web developers. "
¯\_(ツ)_/¯
Therein lies the lie.
Image and video compression comparisons are like statistics with the right corpus and evaluation criteria you can should whatever narrative you want to push.
We need good video formats however. Video makes up most of the global internet traffic, probably accounts for a good part of global storage capacity too. Even slightly better compression will have a massive impact.
We jumped through quite a lot of hoops to make sure old software will be able to display new images. They simply won't display them optimally. But for the most part, that would be because the old software wouldn't display images optimally anyway. So the limit was the software, not the format.
What I mean by this is old software that treats everything as sRGB wouldn't correctly show a Display P3 image anyway. But we made sure it will still display the image as correctly as it could.