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.

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!

https://community.adobe.com/t5/fireworks-discussions/open-fi...

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?

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.

What are the arguments for this? It would seem easier for everyone to rotate and then store exif for the original rotation if necessary.

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,

If a smartphone camera is doing it, then bad camera app!

Most other SVG renderers don't support much CSS.

https://trac.ffmpeg.org/wiki/Encode/AV1#Losslessencoding

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…

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.

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.

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

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?

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.

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.

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.

That's what I would call really extensible, but then there may be no limits and hacking/viruses could have easily a field day.

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".

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?

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.

You don't follow spec, you're on your own.

People believed me. Still funny.

And if they pick something dumb enough other people get to ignore them.

You'll commonly call someone by their pronounced name out of respect, forced or given.

In a situation where someone does something really stupid or annoying and the forced respect isn't there, most people don't.

On inanimate objects: Aluminium was first ratified by the IUPAC as aluminium⁰, with the agreement of its discoverer Sir Humphrey Davy¹, yet one huge nation calls it something else…

On people: nicknames are a thing, are you saying those are universally wrong? But yes, when a person tells me that they'd prefer their name pronounced a different way, or that they'd prefer a different name entirely, or that they don't like the nickname other use for them, you can bet your arse that I'll make the effort to use their preferred name+pronunciation in future.

------

[0] Though it should be noted that aluminum was, a few years after, officially accepted as an alternate form.

[1] He initially called it aluminum in the first paper.

But also, no, not universally even for babies, especially when the name is something ridiculous like X Æ A-Xii where even parents disagree on pronunciation, or when the person himself uses a "non-specced" variant

Wrt/ communication, aside from personal preference, one can either respect the creator, or the audience. If I stand in front of 10 colleagues, 10 out of them would not understand jif, or would only get it because this issue has some history now. gif on the other hand has no friction.

Ghengis Khan for example sounds very different from its original Mongolian pronunciation. And there is a myriad others as well.

https://www.libpng.org/pub/png/libpng.html

Looks like this is the proper location for the project.

https://libpng.sourceforge.io/

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...

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...

See CSS image-set : https://developer.mozilla.org/en-US/docs/Web/CSS/image/image...

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:

    <picture>
        <source srcset="a.webp" type="image/webp">
        <img src="fallback.jpg">
    </picture>

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.

"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. "

¯\_(ツ)_/¯

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.

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.

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.

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.

I think your experience is with some tool that made bad PNGs. That is a problem with the tool, not the format.