Kind of wish this site went to more effort to explain some of the details. I'm a graphics programmer so I can guess why PNG is bad at alpha, but they've done nothing to convince me that EXR gets it right other than show one or two comparison screenshots.
If the alpha and forground is stored in the same image, you can notice that we can pre compute forground * alpha. This is known as pre-multiplication, and is a very common techniqe. An added benefit of this is that we get more dynamic range, and can add to the composit, without removing the background.
This is possible in both PNG and EXR. HOWEVER, if you dont intend to pre-multiply, then the forground is not used if alpha is zero. The people who implemented LibPNG, the most common implementation of PNG, figured that they could make an optimization by throwing away the forground and just store black if alpha is zero. This improves file sizes since run length encoding is used.
This means that while, PNG the format, can store forground data with zero alpha, any application using LibPNG or other implementation with the same optimization may throw away the data. Photohop is a prime example of this. This makes PNG very unreliable when working with alpha.
Sorry, but this looks like opinionated nonsense. There's an underlined and bolded "PNG is a forbidden file format" that is in fact not a link, without explaining how and why it is forbidden.
I think a missing context here is that this is aimed at people who work with VFX and other forms of computer-made images; and even more in context of "what should your authoritative master format for archival purposes be".
Which also makes the line about JPEG noise make a lot more sense.
AFAICT, this is not a generic "PNG always bad and you should never use it to display images on the web" screen.
JPEG is unacceptable for screenshots of text, unless you can disable chroma subsampling, which isn't always an exposed option.
As a quick test, I took a screenshot of this comment, and saved it as both a PNG and 100% quality 444 JPEG, exported from GIMP. The JPEG is 81477 bytes, and the PNG is 44212.
Note that sometimes text is not rendered as 1D monochromatic but with some kind of slight pixel-level chromatic abberation. In this case I'm not sure PNG will do so well
It would make the compression take a (tiny) hit. In your test case being dominated by a solid color patch (which describes many screen shots), it would make no practical difference.
I was surprised and confused about this, specially because I take certain care on the screenshots I paste on technical docs everyday, using PNG and a quantizer to reduce color depth.
But on second read I think we're making a mistake because we work on a different domain. I think the article exclusively refers to images produced I'm the workflow of video/CGI/3D rendering and generation for the motion films/multimedia industry. And there it can probably make sense to use a format like that, same as when I use a DNG or similar for storage of my photos.
I think when he said "screen-grab" he wasn't referring to an screenshot of a computer app or desktop, but to a frame of a video or something similar.
This page makes no sense: e.g. proposing (uncompressed) jpeg over png for screenshots without any explanation why (note that even uncompressed jpeg doesn't necessarily store the exact original rgb color values but is likely ok for 8-bit rgb). Calls png "forbidden" but lists a bunch of other formats (without listing an actually good one like jpeg xl) as a valid replacement without saying what those (like webp which in its lossy version cannot even encode color at full resolution) formats do that png doesn't.
Complains something about alpha channels but doesn't explain what (and the mentioned jpeg has no alpha support)
PNG supports 16 bit per channel and ICC color profiles so can do HDR.
PNG can display HDR, but the lack of floating-point support does put it at a disadvantage as an intermediate format (there's a demo about half way down the page comparing 16-bit PNG against fp16 EXR, during exposure adjustment)
This is the first time I've heard about (Open)EXR, and it honestly sounds like a pretty neat format. But this article lacks context, and it sorely needs it. PNG has many good uses. Apparently not in the author's chosen domain, and yet they condemn PNG entirely.
Which makes this a highly opinionated piece. And why should I listen to the opinion of somebody who thinks it's necessary to disable context menus on their website?
PNG not using premultiplied alpha does mean that it is not great as an intermediary format in certain scenarios, but saving the final result as a PNG should not be an issue.
that file format is mainly used in professional settings and yes, it is good.
but saying that png is bad is nonsense. png has been designed to REPLACE GIF
that was the target : do what GIF does, without the Lempel-Ziv patent issue. and drop a few improvements... that's it.
comparing something that was designed to replace GIF for Internet use to a professional-level image format designed for specific industrial (as in cinema) work... what the hell ?
if you/they want to push for EXR, make a proposal to the browser developers. and in the end, the website developers and public will choose.
how big those pictures are, how fast they load, how costly it is on the CPU (we are going in a world where how much power you use IS going to be important, and on fixed machines as much as phones).
24 comments
[ 3.5 ms ] story [ 61.7 ms ] threadAlpha can be used in multiple ways, most commonly as a blend:
result = background * (1.0 - alpha) + forground * alpha;
If the alpha and forground is stored in the same image, you can notice that we can pre compute forground * alpha. This is known as pre-multiplication, and is a very common techniqe. An added benefit of this is that we get more dynamic range, and can add to the composit, without removing the background.
This is possible in both PNG and EXR. HOWEVER, if you dont intend to pre-multiply, then the forground is not used if alpha is zero. The people who implemented LibPNG, the most common implementation of PNG, figured that they could make an optimization by throwing away the forground and just store black if alpha is zero. This improves file sizes since run length encoding is used.
This means that while, PNG the format, can store forground data with zero alpha, any application using LibPNG or other implementation with the same optimization may throw away the data. Photohop is a prime example of this. This makes PNG very unreliable when working with alpha.
1: https://web.archive.org/web/20160112000701/http://www.timecu...
Which also makes the line about JPEG noise make a lot more sense.
AFAICT, this is not a generic "PNG always bad and you should never use it to display images on the web" screen.
> Never ever PNG, not even for web
JPEG is unacceptable for screenshots of text, unless you can disable chroma subsampling, which isn't always an exposed option.
As a quick test, I took a screenshot of this comment, and saved it as both a PNG and 100% quality 444 JPEG, exported from GIMP. The JPEG is 81477 bytes, and the PNG is 44212.
But on second read I think we're making a mistake because we work on a different domain. I think the article exclusively refers to images produced I'm the workflow of video/CGI/3D rendering and generation for the motion films/multimedia industry. And there it can probably make sense to use a format like that, same as when I use a DNG or similar for storage of my photos.
I think when he said "screen-grab" he wasn't referring to an screenshot of a computer app or desktop, but to a frame of a video or something similar.
original - ~200kB png. oxiPNG - ~107kB.
Browser Jpeg - 604kB, MozJPEG 100 - 538kB, MozJPEG 100 RGB - 669kB.
JpegXL lossless - 26kB.
AVIF lossless max effort - 306kB
Complains something about alpha channels but doesn't explain what (and the mentioned jpeg has no alpha support)
PNG supports 16 bit per channel and ICC color profiles so can do HDR.
Which makes this a highly opinionated piece. And why should I listen to the opinion of somebody who thinks it's necessary to disable context menus on their website?
There are advantages to use EXR as listed on the website, but imo they are more geared toward people working in 3D/CGI/VFX
comparing something that was designed to replace GIF for Internet use to a professional-level image format designed for specific industrial (as in cinema) work... what the hell ?
if you/they want to push for EXR, make a proposal to the browser developers. and in the end, the website developers and public will choose.
how big those pictures are, how fast they load, how costly it is on the CPU (we are going in a world where how much power you use IS going to be important, and on fixed machines as much as phones).