[razorfen]

Can anyone explain how they maintain backwards compatibility on formats like this when adding features? I assume there are byte ranges managed in the format, but with things like compression, wouldn’t compressed images be unrenderable on clients that don’t support it? I suppose it would behoove servers to serve based on what the client would support.

[gmueckl]

In mynunderstanding, the actual image data encoding isn't altered in this update. It only introduces an extended color space definition for the encoded data.

PNG is a highly structured file format internally. It borrows design ideas from formats like EA's Interchange File Format in that it contains lists of chunks with fixed headers encoding chunk type amd length. Decoders are expected to parse them and ignore chunk types they do not support.

[joquarky]

The Amiga was quite a platform. Glad to know that it had some long term influence.

[joshmarinacci]

The PNG format has chunks with types. So you can add an additional chunk with a new type and existing decoders will ignore it.

There is also some leeway for how encoding is done as long as you end up with a valid stream of bits at the end (called the bit stream format), so encoders can improve over time. This is common in video formats. I don’t know if a lossless image format would benefit much from that.

[gmueckl]

PNG is a bit unusual in that it allows a couple of alternate compressed encodings for the data that are all lossless. It is up to the encoder to choose between them (scanline by scanline, IIRC). So.this encoding algorithm leeway is implicit in a way.

[jdhsddh]

PNG is specifically designed to support this. Clients will simply skip chunks they do not understand.

In this case there could be an embedded reduced colour space image next to an extended color space one