- It isn't really a "new format". It's an update to the existing format. - It is very backwards compatible. -- Old programs will load new PNGs to the best of their capability. A user will still know "that is a picture of a red apple".
There also seems to be some confusion about how PNGs work internally. Short and sweet: - There are chunks of data. -- Chunks have a name, which says what data it contains. A program can skip a chunk it doesn't recognize. - There is only one image stream.
Chris Lilley--one of the original PNG co-authors--has a post with an example HDR image: https://svgees.us/blog/cICP.html It is about half way down, with the birthday cake. Generally, us tech nerds have phones that are capable of displaying it well. So perhaps view the page on your phone.
What you should look for is the cake, the pink tips in her hair, and the background being more vivid. For me, the pink in the cake was the big give-away.
There is also the Web Platform Tests (WPT) which we use to validate browser support: https://wpt.fyi/results/png/cicp-chunk.html?label=master&lab...
Although, that image is just a boring teal. See it live in your browser here: https://wpt.live/png/cicp-chunk.html
For an example of APNG, you can use Wikipedia's images: https://en.wikipedia.org/wiki/APNG
But you have a bigger point: I should have live demonstrations of those things to help people understand.
Sooooo file some bugs :D
Also, be kind to them. This literally launched yesterday.
Pink can pose problems for individuals with red-green color blindness (or more exactly: color vision deficiency). So make sure that examples work for these people too. Otherwise the examples might not work for about 8% of your male viewers.
There was nothing you could do about the TV, the screen couldn't show all the colors that you needed.
This is great but also has the issue that users might not notice that their setup is giving them a less than optimal result. Of course that is probably still better than not having backwards compatibility.
Edit: Seems the backwards compatibility isn't as great as it could be. Old programs show a washed out image instead which sucks. This should have been avoidable in the same way JPG gain maps work so that you only need updated programs to take advantage of the increased gamut on more-than-sRGB screens and not to correctly show colors that fit into sRGB.
However, gain maps are extra data. So there is a trade off.
The reason gain maps didn't make it into Third Edition is it isn't yet a formal standard. We have a bunch of the work ready to go once their standard launches.
The big one is adoption. I love JPEG XL and hope it becomes more widely adopted. It is very scary to add a format to a browser because you can never remove it. Photoshop and MSPaint no longer support ICO files, but browsers do. So it makes sense for browsers to add support last, after it is clearly universal. I think JPEG XL is well on their way using this approach. But they aren't there yet and PNG is.
There is also longevity and staying power. I can grab an ancient version of Photoshop off eBay and it'll support PNG. This also benefits archivists.
As a quick side note on that: I want people to think about their storage and bandwidth. Have they ever hit storage/bandwidth limits? If so, were PNGs the cause? Was their site slow to load because of PNGs? I think we battle on file size as an old habit from the '90s image compression wars. Back then, we wanted pixels on the screen quickly. The slow image loads were noticeable on dial-up. So file size was actually important then. But today?? We're being penny-wise and pound-foolish.
What sort of improvements might we expect? Is there a chance of it rivalling lossless WebP and JPEG XL?
You can see this with PNG optimizers like OptiPNG and pngcrush.
So step 1 is to improve libpng. This requires no spec change.
Step 2 is to enable parallel encoding and decoding. We expect this to increase the file size, but aren't sure how much. It might be surprisingly small (a few hundred bytes?). It will be optional.
Step 3 is the major changes like zstd. This would prevent a new PNG from being viewable in old software, so there is a considerably higher bar for adoption. If we find step 1 got us within 1% of zstd, it might not be worth such a major change.
I don't yet know what results we'll find or if all the work will be done in time. So please don't take this as promises or something to expect. I'm just being open and honest about our intentions and goals.
For the lifetime of PNG so far, a PNG file has almost, but just barely not, been a valid Interchange File Format (IFF) file.
IFF is a great (simple to understand, simple to implement support for, easy to generate, easy to decode, memory-efficient, IO-efficient, relatively compact, highly compressible) metaformat, that more people should be aware of.
However, up to this point, the usage of IFF has consisted of:
• some old proprietary game-data and image formats from the 1980s that no modern person has heard of
• some popular-yet-proprietary AV formats [AIFF, RIFF] that nobody would write a decoder for by hand anyway (because they would need a DSP library to handle the resulting sample-stream data anyway, and that library may as well offer container-format support too)
• The object files of an open but uncommon language runtime (Erlang .beam files), where that runtime exposes only high-level domain-specific parsing tooling (`beam_lib`) rather than IFF-general decoding tooling
• An "open-source but corporate-steered" image format that people are wary of allowing to gain ecosystem traction (WebP — which is more-specifically a document in a RIFF container)
• And PNG... but non-conformantly, such that any generic IFF decoder that could decode the other things above, would choke on a PNG file.
IMHO, this is a major reason that there is no such thing as "generalized IFF tooling" today, despite the IFF metaformat having all the attributes required to make it the "JSON of the binary world". (Don't tell me about CBOR; ain't nobody hand-rolling a CBOR encoder out of template strings.)
If you can't guess by now, my wishlist item for PNGv3, is for PNG files to somehow become valid/conformant IFF files — such that the popularity of PNG could then serve as the bootstrap for a real IFF tooling ecosystem, and encourage awareness/use of IFF in new greenfield format-definition use-cases.
---
Now, I've written PNG parsers, and generic IFF parsers too. I've even tried this exact unification trick before (I wanted an Erlang library that could parse both .beam files and PNG files. $10 if you can guess the use-case for that!)
Because of this, I know that "making PNG valid per IFF" isn't really possible by modifying the PNG format, while ensuring that the resulting format is decodable by existing PNG decoders. If you want all the old [esp. hardware] PNG parsers to be compatible with PNGv3s, then y'all can't exactly do anything in PNGv3 like "move the 4-byte CRC inside the chunk as measured by the 4-byte chunk length" or "make the CRCs into their own chunks that reference the preceding record".
But I'm not proposing that. I'm actually proposing the opposite.
Much of what PNGv2 did in contravention of the IFF spec, is honestly a pretty good idea in general. It's all stuff that could be "upstreamed" — from the PNG level, to the IFF level.
I propose: formalizing "the variant of IFF used in PNG" as its own separate metaformat specification — breaking this metaformat out from the PNG spec itself into its own standards document.
This would then be the "Interchange File Format specification, version 2.0" (not that there was ever a formal IFFv1 spec; we all just kind of looked at what EA/Commodore had done, and copied it in our own code since it was so braindead-easy to implement.)
This IFF 2.0 spec would formalize, at least, a version or "profile" of IFF for which PNGv2 images are conformant files. It would have chunk CRCs; chunk attribute bits encoded for purposes of decoders + editors via meaningful chunk-name letter-casing; and an allowance for some number of garbage bytes before the first valid chunk begins (for PNG's leading file signature that is not itself a valid IFF chunk.)
This could be as far as the IFF 2.0 spec goes — leaving IFFv1 files non-decodable in IFFv2 parsers. But that'd be a shame.
I would suggest going further — formalizing a second IFFv2 "profile" against which IFFv1 documents (like AIFF or RIFF files) are conformant; and then specifying that "generic" IFFv2-conformant decoders (i.e. a hypothetical "libiff", not a format-specific libpng) MUST implement support for decoding both the IFFv1-conforming and the PNGv2-conforming profiles of IFF.
It could then be up to the IFF-decoding-tooling user (CLI command user, library caller) to determine which IFFv2 "profile" to apply to a given document... or the IFFv2 spec could also specify some heuristic algorithm for input-document "profile" detection. (I think it'd be pretty easy; find a single chunk, and if what follows its chunk-length is a CRC that validates that chunk, then you have the PNGv2-like profile. Whereas if it's not that, but is instead four bytes of chunk-name-valid character ranges, then you've got the IFFv1-like profile. [And if it's neither, then you've got a file with a corrupted first chunk.])
---
And, if you want to go really far, you could then specify a third entirely-novel "profile", for use in greenfield IFF applications:
• A few bytes of space aren't so precious; we can hash things much faster these days, with hardware-accelerated hashing instructions; and those instructions are also for hashes that do much better than CRC to ensure integriaty. So either replace the inline CRCs with CRC chunks, or with nested FORM-like container records (WCRC [len] [CRC4] [interior chunk]). Or just skip per-chunk CRCs and formalize a fHsh chunk for document-level integrity, embedding the output of an arbitrary hash algorithm specified by its registered https://github.com/multiformats/multihash "hash function code".
• Re-widen the chunk-name-valid character set to those valid in IFFv1 documents, to ensure those can be losslessly re-encoded into this profile. To allow chunks with non-letter characters to have a valid attribute decoding, specify a document-level per-chunk-name "attributes of all chunks of this type" chunk, that can either be included into a given concrete format's header-chunk specification, or allowed at various points in the chunk stream per a concrete format's encoding rules (where it would then be expected to apply to any successor + successor-descendant chunks within its containing chunk's "scope.") Note that the goal here is to keep the attribute bits in some way or another — they're very useful IMHO, and I would expect an IFF decoder lib to always be emitting these boolean chunk-attribute fields as part of each decoded chunk.
• Formalize the magic signature at the beginning into a valid chunk, that somehow encodes 1. that this is an IFF 2.0 "greenfield profile" document (bytes 0-3); 2. what the concrete format in use is (bytes 4-7). (You could just copy/generalize what RIFF does here [where a RIFF chunk has the semantics of a LIST chunk but with a leading 4-byte chunk-name type], such that the whole document is enclosed by a root chunk — though this is painful in that you need to buffer the entire document if you're going to calculate the root-chunk length.)
I'm just spitballing; the concrete details of such a greenfield profile don't matter here, just the design goal — having a profile into which both IFFv1 and PNGv2 documents could be losslessly transcoded. Ideally with as minimal change to the "wider and weirder/more brittle ecosystem" side [in this case that's IFFv1] as possible. (Compare/contrast: how HTML5 documents are a profile of HTML that supersedes both HTML4 and XHTML1.1 — supporting both unclosed tags and XML-namespaced element names — allowing HTML4 documents to parse "as" HTML5 without rewrites, and XHTML1.1 documents to be transcoded to HTML5 by just stripping some root-level xmlns declarations and changing the doctype.)
W3C requires that we do not break old, conformant specs. Meaning if the next PNG spec would invalidate prior specs, they won't approve it. By extension, an old, conformant program will not suddenly become non-conformant.
I could see a group of people formalizing IFFv2, and adapting PNG to it. But that would effectively be PNGIFF, not PNG. It would be a new spec. Because we cannot break the old one.
That might be fine. But it comes with a new set of problems, like adoption.
Soooo I like the idea but it would probably be a separate thing. FWIW, it would actually be nice to make a formal IFF spec. If there was no governing body that owns it, we can find an org and gather interest.
I doubt W3C would be the right org for it. ISO subgroup??
It's also questionable how much you actually benefit from common container formats like this since you need to know the application specific format contained anyway in order to do anything useful with it. It also causes problems where "smart" programs treat files in ways that make no sense, e.g. by offering to extract a .docx file just because it looks like a .zip
One neat thing about IFF is that all of its "container" chunk types (LIST, FORM, CAT) are part of the standard; the expectation is that domain-specific chunk types should [mostly] be leaf nodes. As such, IFF is at least "legible" in the same way that XML or JSON or Lisp is legible (and more than e.g. ELF is legible): you're meant to decompose an object graph into individual IFF chunks for each object in the graph. Which translates to IFF files being "browseable", rather than dead-ending in opaque tables that require some other standard to tell how how they're even row-delimited.
Another neat thing is that, like with namespaced XML element names, chunk names — at least the "public" ones — are meant to have globally-unique meanings, being registered in a global registry (https://wiki.amigaos.net/wiki/IFF_FORM_and_Chunk_Registry). This means that IFF tooling can "browse" an arbitrary unknown IFF document, find a chunk it does understand the meaning of, and usefully decode it (and maybe its descendants) for you.
Many more-complex IFF formats (e.g. the AV containers like RIFF) embed data of other media types as chunks of these registered types. Think "thumbnail in a video file" or "texture in a scene file." Your tooling doesn't need to know the semantics of the outer format, to be able to discover these registered inner chunks inside it, and browse/preview/extract them. (Or replace them one-for-one with another asset of the same type; or even, if they're inside a simple LIST chunk, add or remove instances of the asset from the list!)
Also, somewhat interestingly, given the way IFF is structured, there is no inherent difference between embedding a sub-resource "opaquely" vs embedding it "legibly" — i.e. if you embed a [headerless] IFF document as the value of a chunk in another IFF document, then that's exactly the same thing as nesting the root-level chunk(s) of that sub-document within the parent chunk. It's like how an SVG sub-document inside an XHTML document isn't a separate serialized blob that gets sucked out and parsed, but rather just additional tags in the XHTML document-string, around which a boundary of "this is a separate XML sub-document" gets drawn by some "DOM document builder" code downstream of the actual XML parser.
---
But besides the technical "it can be done" points, let me also speak more in terms of the motivation. Why would you want to?
Well, have you ever wanted to open up a complex file and pull its atomic-level assets out? Your first thought when hearing that was probably "that sounds like a nightmare" — and yes, today, it is.
But back in the 1980s, with the original growth of IFF-based formats, we temporarily lived in this wonderland where there were all these different browseable / explorable file formats, that could be cracked open with exactly the same tools.
Do you wonder how and why the game modding scene first came into existence? It was basically the result of games storing their asset packs in these simple-to-parse/generate file formats — where people could easily drop-in replace one of those assets with a new one with simple command-line tools, or even with a GUI, without worrying about matching asset sizes / binary offset patching / etc — let alone with any knowledge of how the container file format works.
Do you appreciate how macOS app bundles just have a browseable, hierarchical Resources directory inside them? Before app bundles, macOS applications held their resources in a "resource fork" — essentially a set of FourCC-tagged file extended-attributes (though actually, a single on-disk packfile that acted as a random-access key-value store of those xattrs). And both of these approaches (bundle Resources dirs, and resource forks) provided the same explorability / moddability as IFF files do. People would throw a macOS program into ResEdit and pull out its icons, its fonts, its strings, whatever — where those weren't program-domain-specific things, but rather were effectively items with standardized media types (their FourCC codes being effectively the predecessor of modern MIME types.)
For that matter, consider this quote from the IFF wiki page:
> There are standard chunks that could be present in any IFF file, such as AUTH (containing text with information about author of the file), ANNO (containing text with annotation, usually name of the program that created the file), NAME (containing text with name of the work in the file), VERS (containing file version), (c) (containing text with copyright information).
Now, remember that IFF decoders are almost always expected / coded to ignore chunks they don't understand. (Especially for IFF files encoded as a toplevel stream of heterogeneous chunk types.)
That means that not only can various format authors decide to use these standard chunks... but third-party editors can also just drop chunks like this into the things they edit! You know how Windows has that "name, author, version" etc info on the Properties sheet for some file types? That info could show up and be editable for any IFF-based file format — whether the particular format has an "allowance" for it or not.
(There's nothing special about IFF here, by the way. You could just as well drop "foreign-namespaced attributes" like this into an e.g. XML-based document format. The difference is a cultural one: the developers of XML-based document formats tend to have their XML decoders validate their documents for strict conformance to an XML schema; and XML schemas tend to be [but don't have to be!] designed as whitelists of the possible tags that can be used within any given parent nesting path. IFF, meanwhile, has never had anything like a schema-based document validation. Every document was best-effort parsed, like HTML4; and so every IFF-based format decoder is a best-effort decoder, like a web browser parsing HTML4. That very lack of schema-based validation, actually opens up a lot of use-cases for IFF.)
> We really shouldn't be making new standards with big endian byte order.
IFF isn't a wire protocol standard for efficient zero-copy; and nor is it intended for file formats amenable to being streaming-parsed.
And that's okay! Not every format needs to be suited to efficient, scalable, concurrent, [other lovely words] message passing!
IFF has two major use-cases:
1. documents that are "loaded" in some program, where "loading" is expected to occur against a random-access block device; where each chunk will be visited in turn, with either its contents being parsed into an in-memory representation; its contents' slicing bounds being stored to later stream or random-access within (or the part of the file within those bounds being mmap(2)ed — same thing); or that chunk discarded, thus allowing the load operation to skip issuing any read ops for it or its descendants entirely.
This is the PNG use-case.
(Though, interestingly enough, since PNG has only one large chunk — the image data — PNG can be made into an "effectively-streamed format" simply by keeping that big chunk at the end of the IFF document. Presuming the stream length of the PNG file is known [as in a regular HTTP fetch], the "skeleton load" process for PNG can terminate after just having parsed its way through all the other tiny chunks — perhaps with a few minimal buffer waits to skip over unknown chunks — but with no need to buffer the entire image data chunk. [It adds the image-data-chunk length to the file pointer, realizes there's no more room for chunks in the stream, and so doesn't bother to buffer+seek past that final chunk.] The IFF parser then returns to the caller, passing it the slicing bounds of [among other things] the (still not-yet-fully-received) image-data chunk. And the caller can then turn around, and hand the same FILE pointer and those slicing bounds to its streaming renderer, letting it go to town consuming the stream as needed.)
IFF in its skeleton-loading model, would also be ideal for something like e.g. a font file (which has lots of little tables, which are either eagerly parsed, or ignored, by any given renderer.)
2. simple "read-rarely" packfile documents, that act sort of like little databases, but without any sort of TOC header part; where, when you want to grab something from the packfile, you re-navigate down through it from the root, taking the IOPS hit from all the seeks to each nesting-parent chunk's preceeding sibling chunks before hitting the descendant you want to navigate into.
This is the use-case of most IFFv1 file formats — most of them were made for use by programs that would grab this or that for the program's use either once at startup, or when the thing became relevant. (Think of the types of things a Windows executable embeds as "resources" — icons, translated strings, XAML declarative-MVC-view documents, etc.)
For a parallel, IFF here is to "using an entire archive-format library like tar or zip to store these assets for random access", as "spitting CSV/XML out using template strings" is to using a library to encode a table to a Parquet/ORC/etc. table.
The parallel is that in both cases, you're trading some performance and robustness, for massively reduced complexity and ease of implementation. Like with emitting CSV, you can slop together an IFF encoder right there inside your data-emitting logic — in any language that can write out binary files, and without even having access to the Internet, let alone adding a dependency on an encoder package in some package ecosystem. You can do it in C; you can do it in assembly; you can do it in a bash script; you can do it in BASIC; you can do it in a Windows batch file; you can do it in your single-file Python or Ruby or Perl script that lives in your repo. You can probably do it in a Makefile!
(Also, given how IFF parsing works [i.e. given that any given chunk's contents is in superposition of being either an opaque binary slice or a potential stream of child chunks, with a streaming event-based parser able to decide at each juncture whether to take that step of decoding the child chunks or to leave them as an undecoded binary for now], if you start to care about performance, you can just stick some memoization in front of your "fetch a key-path-lens KP from document D" function, and now you're building a just-in-time TOC. And obviously you can put TOC chunks in your IFF-based file formats if you want — though IMHO doing so kind of goes against the spirit of IFF.)
---
In neither of those use-cases does it really matter that lengths require reading four bytes one-at-a-time with left-shifts, rather than being able to just plop the four bytes into a register. These aren't cases where the parse overhead of the the structural glue between the data, will ever be non-trivial relative to the time it takes to consume the data itself.
And even if you did want to use IFF for something crazy, like as a substitute for Protobuf: did you know that most modern CPU ISAs have a byte-shuffle instruction that can transform big-endian into little-endian [among an unbounded number of other potential transformations] in a single cycle? Endian-ness did matter in protocol design for a while... but these days, unless you're e.g. a Google engineer designing a new SAN protocol, and optimizing it for message-handling overhead on your custom SDN L7 network-switch silicon that doesn't have a shuffle op... endian-ness is mostly irrelevant again!
[1] - https://github.com/Draneria/Metallics-by-Draneria_Krita-Brus...
[2] - https://krita-artists.org/t/memileo-impasto-brushes/92952/11...
But you did need to remember to export if you didn't want the extra fields increasing the file size. I remember finding fireworks pngs on web pages many times back then.
Also, Adobe saves AI files into a PDF (every AI file is a PDF file), and Photoshop can save PSD files into TIFF files (people wonder why these TIFFs have several layers in Photoshop, but just one layer in all other software).
Fireworks was my favorite image editor, I don't know that I've ever found one I love as much as I loved Fireworks. I'm not a graphics guy, but Fireworks was just fantastic.
https://community.adobe.com/t5/fireworks-discussions/open-fi...
(Not many things handle .ai so well either!!)
https://dev.exiv2.org/projects/exiv2/wiki/The_Metadata_in_PN...
This is similar to HTTP request headers, if you're familiar with that. There are a set of standard headers (User-Agent, ETag etc) but nobody is stopping you from inventing x-tomtom and sending that along with HTTP request. And on the receiving end, you can parse and make use of it. Same thing with PNG here.
Yes, a hypothetical user's sprinker layout "map" or whatever they're working on is actually composed of a few rectangles that represent their house, and a spline representing the garden border, and a circle representing the tree in the front yard, and a bunch of line segments that draw the pipes between the sprinkler heads. Yes, each of those geometric elements can be concisely defined by JSON text that defines the X and Y location, the length/width/diameter/spline coordinates or whatever, the color, etc. of the objects on the map. And yes, OP has a rendering engine that can turn that JSON back into an image.
But when the user thinks about the map, they want to think about the image. If a landscaping customer is viewing a dashboard of all their open projects, OP doesn't want to have to run the rendering engine a dozen times to re-draw the projects each time the page loads just to show a bunch of icons on the screen. They just want to load a bunch of PNGs. You could store two objects on disk/in the database, one being the icon and another being the JSON, but why store two things when you could store one?
Really, I think its pretty common for tools that work with images generally.
Can you compress it? I mean, theoretically there is this 'zTXt' chunk, but it never worked for me, therefore I'm asking.
Assuming Next gen PNG will still require new decoder. They could just call it PNG2.
JPEG-XL already provides everything most people asked for a lossless codec. If there are any problems it is its encoding and decoding speed and resources.
Current champion of Lossless image codec is HALIC. https://news.ycombinator.com/item?id=38990568
[1] https://encode.su/threads/4025-HALIC-(High-Availability-Loss...
It looks like LEA 0.5 is the champion.
And HALIC is not even close to ten in this [2] lossless image compression benchmark.
[2] https://github.com/WangXuan95/Image-Compression-Benchmark
And this will improve over time, like jpg encoders and decoders did.
When it comes to hardware encoding/decoding, I am not following your point I think. The fact that some are already looking at hardware implementation for JPEG XL means that….?
I just know JPEG hardware acceleration is quite common, hence I am trying to understand how that makes JPEG XL different/better/worse?
Hardware acceleration for lossless makes more sense for JPEG XL because it is currently very slow. As the author of HALIC posted some results below, JPEG XL is about 20 - 50x slower while requiring lots of memory after memory optimisation. And about 10 - 20 times slower compared to other lossless codec. JPEG XL is already used by Camera and stored as DNG, but encoding resources is limiting its reach. Hence hardware encoder would be great.
For lossy JPEG XL, not so much. Just like video codec, hardware encoder tends to focus on speed and it takes multiple iteration or 5 - 10 years before it catches up on quality. JPEG XL is relatively new with so many tools and usage optimisation which even current software encoder is far from reaching the codec's potential. And I dont want crappy quality JPEG XL hardware encoder, hence I much prefer an upgradeable software encoder for JPEG XL lossy and hardware encoder for JPEG XL Lossless.
WebP is amazing. But if I were going to label something "state of the art" I would go with JPEGXL :)
Are there usecases for lossless other than archival?
A lot of images should be lossless. Icons/pictograms/emoji, diagrams and line drawings (when rasterized), screenshots, etc. You can sometimes get away with large-resolution lossy for some of these if you scale it down, but that doesn't necessarily translate into a smaller file size than a lossless image at the intended resolution.
There's another problem with lossy images, which is re-encoding. Any app/site that lets you upload/share an image but also insists on re-encoding it can quickly turn it into pixelated mush.
For myself, I use PNG only for computer-generated still images. I tend to use good ol' JPEG for photos.
Apart from the widespread support in codecs, there are 3 important elements: processing speed, compression ratio and memory usage. These are taken into account when making a decision (pareto limit). In other words, the fastest or the best compression maker alone does not matter. Otherwise, the situation can be interpreted as insufficient knowledge and experience about the subject.
HALIC is very good in lossless image compression in terms of speed/compression ratio. It also uses a comic amount of memory. No one mentioned whether this was necessary or not. However, low memory usage negatively affects both the processing speed and the compression ratio. You can see the real performance of HALIC only on large-sized(20 MPixel+) images(single and multi-thread). An example current test is below. During operations, HALIC uses only about 20 MB of memory, while JXL uses more than 1 GB of memory.
https://www.dpreview.com/sample-galleries/6970112006/fujifil...
June 2025, i7 3770k, Single Thread Results
----------------------------------------------------
First 4 JPG Images to PPM, Total 1,100,337,479 bytes
HALIC NORMAL: 5.143s 6.398s 369,448,062 bytes
HALIC FAST : 3.481s 5.468s 381,993,631 bytes
JXL 0.11.1 -e1: 17.809s 28.893s 414,659,797 bytes
JXL 0.11.1 -e2: 39.732s 26.195s 369,642,206 bytes
JXL 0.11.1 -e3: 81.869s 72.354s 371,984,220 bytes
JXL 0.11.1 -e4: 261.237s 80.128s 357,693,875 bytes
----------------------------------------------------
First 4 RAW Images to PPM, Total 1.224.789.960 bytes
HALIC NORMAL: 5.872s 7.304s 400,942,108 bytes
HALIC FAST : 3.842s 6.149s 414,113,254 bytes
JXL 0.11.1 -e1: 19.736s 32.411s 457,193,750 bytes
JXL 0.11.1 -e2: 42.845s 29.807s 413,731,858 bytes
JXL 0.11.1 -e3: 87.759s 81.152s 402,224,531 bytes
JXL 0.11.1 -e4: 259.400s 83.041s 396,079,448 bytes
----------------------------------------------------
I had a very busy time with HALAC. Now I've given him a break, too. Maybe I can go back to HALIC, which I left unfinished, and do better. That is, more intense and/or faster. Or I can make it work much better in synthetic images. I can also add a mode that is near-lossless. But I don't know if it's worth the time I'm going to spend on it.
Strictly true, but e.g. for archival or content delivered to many users compression speed and memory needed for compression is an afterthought compared to compressed size.
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.
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.
If a smartphone camera is doing it, then bad camera app!
It's basically a shame that the exif metadata contains things that affect the rendering
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
Could you explain this one?
Exif fields: https://exiv2.org/tags.html
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.
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?
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>
https://shkspr.mobi/blog/2025/06/an-annoying-svg-animation-b...
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 :)
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...
The AV1 spec [1] does not allow RGB color spaces, therefore AV1 cannot preserve RGB animations in a bit-identical fashion.
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.
It's a shame that browser vendors didn't add silent looping video support to the img tag over (imo) baseless concerns.
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…
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
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.
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>
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.
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.
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.
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.
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.
There is just no need for a PNG update, just adopt JPEG XL.
No one can afford to "just". Five years later and it's only one browser! Crazy.
Browser vendors must deliver, only then it's okay to admonish an end user or Web developer to adopt the format.
JPEG-XL's lossy modular mode is a very unique feature which needs a lot more exposure than it has. It is well-suited to non-photographic drawings or images that aren't continuous, and have never touched any JPEG-like codecs. It has different kinds of artifacts than what you typically see in a DCT image codec. Rather than ringing, you get slight pixellation.
JPEG XL has an edge-preserving filter ("EPF") for the purpose of reducing ringing.
I've not tried it on images, but wouldn't zstandard be exceedingly bad at gradients? It completely fails to compress numbers that change at a fixed rate
Bzip2 does that fine, not sure why https://chaos.social/@luc/114531687791022934 The two variables (inner and outer loop) could be two color channels that change at different rates. Real-world data will never be a clean i++ like it is here, but more noise surely isn't going to help the algorithm compared to this clean example
Maybe I sounded too critical of zstd. To be clear: I use it for general-purpose compression where available, the only exception would be where eeking out the last % gain is important and slow decompression is acceptable and it has one of these patterns that Bzip2 does better in the first place
That it's better than deflate (afaik aka gzip and zlib, just with different header fields) is not surprising since that was iirc the defined goal of Zstandard project
Tell that to Google. They gave up on XL in Chrome[1] and essentially killed its adoption.
It is only a matter of time until the Chrome team has to reverse their decision.
It also has pretty much every feature desired in an image standard. It is future-proofed.
You can losslessly re-compress a JPEG into a JPEG-XL file and gain space.
It is a worthy successor (while also being vastly superior to) JPEG.
Is that gained space enough to account for the fact you now have 2 files? Sure, you can delete the original jpg on the local system, but are you going to purge your entire set of backups?
Unless serving jxl and saving bandwidth, while increasing your total storage, is worth it to you.
Also backup storage is usually cheaper than something that needs to have fast access speeds.
You'll know JPEG-XL if real when camera manufactures allow for XL acquisition instead of legacy JPEG only.
Not sure what the previous poster meant with “backward compatible” here. jxl is a different format. It can include every information a jpeg includes, which then maybe qualifies as “backward compatible” but it still is a different format.
Original JPEG -> JPEG XL -> Recreated JPEG.
Sha256(Original JPEG) == Sha256(Recreated JPEG).
That's what people meant by "backward compatible".
So backwards-compatible in the sense that the jpeg-xl algorithm spec can read jpg and store the same pixel data more efficiently as jxl if you like. You gain space and lose nothing (except perhaps encode/decode speed).
Try opening a HEIC or AV1 or something on a machine that doesn't natively support it down to the OS-level, and you're in for a bad time. This stuff needs to work everywhere—in every app, in the OS shell for quick-looking at files, in APIs, on Linux, etc. If a codec does not function at that level, it is not functional for wider use and should not be a default for any platform.
But this is a feature. Think about all those exploits made possible by this feature. Sincerely, the CIA, the MI-6, the FSB, the Mossad, etc.
"photo scanned in 2025, is about something in easter, before 1940 and after 1920"
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
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.
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
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".)
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...
> Many of the programs you use already support the new PNG spec: ... Photoshop, ...
Photoshop does NOT support APNGs. The PR calls out APNg recognition as the 2nd bullet point of "What's new?"
Am I missing something? Seems like a pretty big mistake. I was excited that an art tool with some marketshare finally supported it.