If only it was called GNP...
CPNG, a backwards compatible fork of PNG
11–20 of 122 posts
Re: CPNG, a backwards compatible fork of PNG
#12Very cool, and I hope it sees adoption. Also speaks to either wise or lucky design of PNG itself, that it can support these kinds of backwards-compatible extensions.
PNG had more focus on backward and forward compatibility, but the fact that PNG can be "extended" in this way is not that unusual for file formats composed of multiple sections (chunks in PNG). Especially considering that other aspects of PNG effectively failed, for example it is technically possible to add new compression method or color type to IHDR, but that would give you a file completely unreadable by existing decoders. CPNG essentially works by reinterpreting PNG in a different way when certain conditions are met.
Re: CPNG, a backwards compatible fork of PNG
#13What happens if this actually picks up steam, and suddenly PNG is no longer one format, but a bunch of incompatible ones that look somewhat similar, whose fidelity depends on your renderer?
Early in PNG's history, we already had this issue with alpha channels, progressive rendering, and hit-or-miss support for APNG (animated PNGs, meant to replace GIFs but never happened).
It was also an issue for a long time for PSDs and SVGs, where the same file never looked the same on two browsers/devices/apps/versions.
I would bet that these days, generating or decoding PNGs is the bottleneck almost nowhere, but extending the format would cause problems everywhere in real-world usage. Apps and companies can no longer tell whether there's something wrong with their image or if somewhere in the pipeline, some new graphics designer decided to use a bleeding-edge version of a 30-year-old graphics format that nobody else accounted for, and it looks "broken" in half the browsers now. A format can still look broken even if it's "backward compatible", just by virtue of having some features (like HDR) that are only displayable in some renderers but not others.
Why not just make a new format instead and have browsers & devices fall back as necessary, like we already do with webp and srcsets?
Re: CPNG, a backwards compatible fork of PNG
#14> Why continue messing with PNG at all? Because if you can figure out how to squeeze new features into PNG in a backwards compatible way, it's instantly compatible with all browsers, OS's, engines, etc. This is valuable What a brilliant paragraph. I wish this developer all the success in the world.
The backwards compatibility is okay, but the author should also plan a more optimal replacement encoding that ditches the legacy compatibility, and require new implementations to support both.
Otherwise there is no way to sunset the hacks.
Re: CPNG, a backwards compatible fork of PNG
#15What happens if this actually picks up steam, and suddenly PNG is no longer one format, but a bunch of incompatible ones that look somewhat similar, whose fidelity depends on your renderer? Early in PNG's history, we already had this issue with alpha channels, progressive rendering, and hit-or-miss support for APNG (animated PNGs, meant to replace GIFs but never happened). It was also an issue for a long time for PSD…
He said that it would be backwards-compatible. It's in the name of the project.
Re: CPNG, a backwards compatible fork of PNG
#16What happens if this actually picks up steam, and suddenly PNG is no longer one format, but a bunch of incompatible ones that look somewhat similar, whose fidelity depends on your renderer? Early in PNG's history, we already had this issue with alpha channels, progressive rendering, and hit-or-miss support for APNG (animated PNGs, meant to replace GIFs but never happened). It was also an issue for a long time for PSD…
He said that it would be backwards-compatible. It's in the name of the project.
Sorry, but did you read my post? It's only backward-compatible in the sense that existing renderers can display SOMETHING -- but it's not the same image.
From the article:
> [...] like how color TV was introduced but it still worked on B&W TV's. New features can be added, as long as existing decoders ignore them and return a viewable image
Keyword "ignore them". To my reading, this means that CPNGs will contain several images inside them: A full-featured version with "color" (or HDR, or or whatever) for newer renderers, and a fallback one (in "black and white" in his example) for existing renderers.
It's not really "backward compatible", but more like "fallback-able".
Re: CPNG, a backwards compatible fork of PNG
#17> Why continue messing with PNG at all? Because if you can figure out how to squeeze new features into PNG in a backwards compatible way, it's instantly compatible with all browsers, OS's, engines, etc. This is valuable What a brilliant paragraph. I wish this developer all the success in the world.
The backwards compatibility is okay, but the author should also plan a more optimal replacement encoding that ditches the legacy compatibility, and require new implementations to support both. Otherwise there is no way to sunset the hacks.
They should just make a new format. It's not clear if this is an improvement over AVIF either.
Re: CPNG, a backwards compatible fork of PNG
#18[dead]
Re: CPNG, a backwards compatible fork of PNG
#19What is the modern power ranking on image formats? For lossless, what is typically the most efficient size wise? Decompression speed? For lossy? I am not in a situation where these micro-optimizations mean much to me, and always default to png, but curious to know where the state of the art is today.
AVIF and WebP, two modern replacements for both JPEG and GIF on the web, both support lossy and lossless encoding.
WebP is mature and has more browser support, but AVIF is getting there (notably only lacking Edge support). Both can compress in either a lossy JPEG-like fashion or in a lossless PNG-like fashion.
If you use a image CDN like Imgix, it'll just auto-detect and serve whatever the most optimal format is anyway: https://docs.imgix.com/apis/rendering/auto/auto#format. Cloudinary too: https://cloudinary.com/documentation/image_optimization#how_...
For non-web, there's also JPEG XL to look at, but if you're not doing rendering an image for redistribution, it's probably better to keep it as raw as possible anyway (i.e. camera raw images plus photoshop layers, or whatever).
Re: CPNG, a backwards compatible fork of PNG
#20Earlier quoted context omitted.
He said that it would be backwards-compatible. It's in the name of the project.
Sorry, but did you read my post? It's only backward-compatible in the sense that existing renderers can display SOMETHING -- but it's not the same image. From the article: > [...] like how color TV was introduced but it still worked on B&W TV's. New features can be added, as long as existing decoders ignore them and return a viewable image Keyword "ignore them". To my reading, this means that CPNGs will contain sever…
> CPNGs will contain several images inside them
That was not my read. When discussing HDR it’s clear that ONLY the extra bits are stored in a new data structure and are applied to the base image at display time.
So that gets you a bit-for-bit compatible image on old systems and HDR on new systems without duplicating data.
I believe that pattern applies throughout: a baseline, standard PNG image plus extra instructions and data for adding information to it.