7 ms·

CPNG, a backwards compatible fork of PNG

237 points by dirkf 3y ago

ericskiff 3y ago
This is wonderful. What a great way to continue innovation without facing the adoption hurdles of a new format
ebb_earl_co 3y ago
> 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.
- unconed 3y ago
  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.
  - solardev 3y ago
    They should just make a new format. It's not clear if this is an improvement over AVIF either.
  - Nyan 3y ago
    We've already got JPEG-XL as a good replacement format, but some feel that jeopardizing its adoption is a sensible cause.
brookst 3y ago
Very 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.
- lifthrasiir 3y ago
  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.
Voultapher 3y ago
That's really cool! I stumbled across libpng being 10+x slower to encode than jpg and tiff at work. The LOGLUV32 part is very clever. I particularly like the tonemapped fallback and general idea to build on top instead of reinventing. That said I hope these format extensions don't end up in compatibility hell, where viewing the full info image is hit or miss between different CPNG decoders.
vzaliva 3y ago
How this compares to WebP?
- kibwen 3y ago
  I didn't even realize that WebP had an optional lossless compression mode.
  - Dwedit 3y ago
    WebP's lossless compression mode usually beats PNG by a lot, and even decompresses faster. I consider lossless WebP to completely obsolete PNG. Lossless JXL often beats WebP in compression, but loses in decompression time. Except for indexed color images. PNG beats WebP on those images. Meanwhile JXL beats PNG on indexed color images.
notfed 3y ago
This sounds pretty amazing. For CPNG-aware libraries, the performance improvements sound impressive. For old (CPNG-unaware) libraries: should I expect any performance drop reading a CPNG image compared to if the image had remained PNG? Similarly, how much larger will a CPNG be than a PNG?
fbdab103 3y ago
What 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.
- solardev 3y ago
  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 https://docs.imgix.com/apis/rendering/auto/auto#format. Cloudinary too: https://cloudinary.com/documentation/image_optimization#how_to_optimize_image_format 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).
  - eyegor 3y ago
    The worst part about avif support in edge is it was added as an optional feature flag ~8 months ago but it still isn't enabled as a default. Nearly every other browser supports avif by default these days. https://winaero.com/avif-support-is-now-available-in-microsoft-edge/amp/ https://winaero.com/avif-support-is-now-available-in-microso...
  - ComputerGuru 3y ago
    WebP and AVIIF (and, to a much lesser extent, HEIC, which AVIF is basically a rip off of) absolutely suck for color management since they are a) virtually never original source formats, b) are video codecs. WebP technically supports two different color profile techniques (traditional embedded ICC - broken in every mainstream batch image processor I’ve tried - and nlx video-based color profiles). Unlike WebP and all the other image formats, untagged AVIF can’t be assumed to be sRGB (in part because there is no actual sRGB for video, though close variants exist) and every image processor or image editor will open it with a different base color profile assigned. WebP doesn’t even support exif, making it absolutely horrible for “lossless” operations that effectively aren’t lossless since they necessarily destroy metadata. HEIC is also a video codec at heart but has a default color space that also isn’t sRGB (which is a good thing; it’s about time we moved on), untagged HEIC images can (though often aren’t in any default workflow) be assigned Display P3. Assigning/assuming sRGB will absolutely break your images, of course.
gumby 3y ago
I loved reading this even though I personally have zero need myself. I enjoyed the rationale and he engineering. The world needs more work like this. I’m talking about the thoughtful image format but also that applies to the write up too.
topsycatt 3y ago
If only it was called GNP...
solardev 3y ago
What 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?
- zimbatm 3y ago
  He said that it would be backwards-compatible. It's in the name of the project.
  - solardev 3y ago
    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".
    - brookst 3y ago
KingLancelot 3y ago
[dead]
jbverschoor 3y ago
Why not just invest in jxl
TheFuzzball 3y ago
Maybe next we'll get eXtensible Compatible Network Graphics: XCPNG
- mkl 3y ago
  PNG is already extensible; that's part of how CPNG is working.
  - TheFuzzball 3y ago
    's a joke
jancsika 3y ago
How different can the fallback be? Could you do an image of SBF that falls back to an image of Madoff?
Retr0id 3y ago
I've also been pondering a backwards-compatible fork of PNG - but rather than a fork, mine would be a subset. Specifically, it would be an as-simple-as-possible uncompressed* bitmap format, suitable for use in low-complexity embedded systems etc. (e.g. bootloaders, wink wink). By being backwards compatible, you get the added benefit of retaining compatibility with existing image viewers, but without having to implement "all of PNG" in decoders and encoders. Now, the base PNG spec isn't even that big, but the more you constrain the spec, the easier it is to be sure you've implemented it securely. * If you're wondering how that works in a backwards-compatible way, DEFLATE already supports uncompressed blocks.
- colejohnson66 3y ago
  BMP already exists for uncompressed bitmap data.
  - Retr0id 3y ago
    This is true, but BMP became a bit of a kitchen-sink format, supporting all sorts of pixel formats, and optionally, compression. i.e. you'd still want to pick a subset to implement. To be honest, you're probably right - BMP would be more sensible starting point, but I'm interested to see how far PNG can be pushed.
- pwg 3y ago
  > I've also been pondering a backwards-compatible fork of PNG - but rather than a fork, mine would be a subset. Specifically, it would be an as-simple-as-possible uncompressed* bitmap format, suitable for use in low-complexity embedded systems etc. (e.g. bootloaders, wink wink). Look at the NetPBM formats (PPM, PGM, PGM). They are about as simple as they can possibly get (a tiny, ASCII, header, followed by binary bitmap data), and are also uncompressed. https://en.wikipedia.org/wiki/Netpbm https://en.wikipedia.org/wiki/Netpbm
  - Retr0id 3y ago
    They're simple, but they're nowhere near as widely supported as PNG (or BMP)
summerlight 3y ago
What does it exactly mean by "100% backward compatible"? It looks like some optimizations could be backported to the existing encoder/decoder without breaking the format but this is more of an optimization. My impression is that this is backward compatible in a way similar to APNG (it will return some reasonable images if the file is using a new functionality), but I'm not sure if I understand it correctly.
tedunangst 3y ago
No mention of JPEG XT or JPEG-HDR? https://en.wikipedia.org/wiki/JPEG_XT https://en.wikipedia.org/wiki/JPEG_XT
phront 3y ago
meet a new bunch of security holes
snshn 3y ago
If APNG couldn't pick up steam and get widespread adoption, not sure how this will. But hopefully I'm wrong.
- jeroenhd 3y ago
  APNG is supported in every browser and all the video encoding tools I've used. It's not used all that often, but support for it is built into many software libraries.
ComputerGuru 3y ago
There’s no mention of what effect these changes have on file size. It seems to me all the non-HDR changes will blow up file sizes for all but the largest of images.
Exoristos 3y ago
Seeping?

237 points by dirkf 3y ago

This is wonderful. What a great way to continue innovation without facing the adoption hurdles of a new format

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

unconed 3y ago
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.
- solardev 3y ago
  They should just make a new format. It's not clear if this is an improvement over AVIF either.
- Nyan 3y ago
  We've already got JPEG-XL as a good replacement format, but some feel that jeopardizing its adoption is a sensible cause.

brookst 3y ago

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

lifthrasiir 3y ago
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.

Voultapher 3y ago

That's really cool! I stumbled across libpng being 10+x slower to encode than jpg and tiff at work. The LOGLUV32 part is very clever. I particularly like the tonemapped fallback and general idea to build on top instead of reinventing. That said I hope these format extensions don't end up in compatibility hell, where viewing the full info image is hit or miss between different CPNG decoders.

vzaliva 3y ago

How this compares to WebP?

kibwen 3y ago
I didn't even realize that WebP had an optional lossless compression mode.
- Dwedit 3y ago
  WebP's lossless compression mode usually beats PNG by a lot, and even decompresses faster. I consider lossless WebP to completely obsolete PNG. Lossless JXL often beats WebP in compression, but loses in decompression time. Except for indexed color images. PNG beats WebP on those images. Meanwhile JXL beats PNG on indexed color images.

notfed 3y ago

This sounds pretty amazing. For CPNG-aware libraries, the performance improvements sound impressive. For old (CPNG-unaware) libraries: should I expect any performance drop reading a CPNG image compared to if the image had remained PNG? Similarly, how much larger will a CPNG be than a PNG?

fbdab103 3y ago

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

solardev 3y ago
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 https://docs.imgix.com/apis/rendering/auto/auto#format. Cloudinary too: https://cloudinary.com/documentation/image_optimization#how_to_optimize_image_format 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).
- eyegor 3y ago
  The worst part about avif support in edge is it was added as an optional feature flag ~8 months ago but it still isn't enabled as a default. Nearly every other browser supports avif by default these days. https://winaero.com/avif-support-is-now-available-in-microsoft-edge/amp/ https://winaero.com/avif-support-is-now-available-in-microso...
- ComputerGuru 3y ago
  WebP and AVIIF (and, to a much lesser extent, HEIC, which AVIF is basically a rip off of) absolutely suck for color management since they are a) virtually never original source formats, b) are video codecs. WebP technically supports two different color profile techniques (traditional embedded ICC - broken in every mainstream batch image processor I’ve tried - and nlx video-based color profiles). Unlike WebP and all the other image formats, untagged AVIF can’t be assumed to be sRGB (in part because there is no actual sRGB for video, though close variants exist) and every image processor or image editor will open it with a different base color profile assigned. WebP doesn’t even support exif, making it absolutely horrible for “lossless” operations that effectively aren’t lossless since they necessarily destroy metadata. HEIC is also a video codec at heart but has a default color space that also isn’t sRGB (which is a good thing; it’s about time we moved on), untagged HEIC images can (though often aren’t in any default workflow) be assigned Display P3. Assigning/assuming sRGB will absolutely break your images, of course.

gumby 3y ago

I loved reading this even though I personally have zero need myself. I enjoyed the rationale and he engineering. The world needs more work like this. I’m talking about the thoughtful image format but also that applies to the write up too.

topsycatt 3y ago

If only it was called GNP...

solardev 3y ago

What 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?

zimbatm 3y ago
He said that it would be backwards-compatible. It's in the name of the project.
- solardev 3y ago
  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".
  - brookst 3y ago

KingLancelot 3y ago

[dead]

jbverschoor 3y ago

Why not just invest in jxl

TheFuzzball 3y ago

Maybe next we'll get eXtensible Compatible Network Graphics: XCPNG

mkl 3y ago
PNG is already extensible; that's part of how CPNG is working.
- TheFuzzball 3y ago
  's a joke

jancsika 3y ago

How different can the fallback be? Could you do an image of SBF that falls back to an image of Madoff?

Retr0id 3y ago

I've also been pondering a backwards-compatible fork of PNG - but rather than a fork, mine would be a subset. Specifically, it would be an as-simple-as-possible uncompressed* bitmap format, suitable for use in low-complexity embedded systems etc. (e.g. bootloaders, wink wink). By being backwards compatible, you get the added benefit of retaining compatibility with existing image viewers, but without having to implement "all of PNG" in decoders and encoders. Now, the base PNG spec isn't even that big, but the more you constrain the spec, the easier it is to be sure you've implemented it securely. * If you're wondering how that works in a backwards-compatible way, DEFLATE already supports uncompressed blocks.

colejohnson66 3y ago
BMP already exists for uncompressed bitmap data.
- Retr0id 3y ago
  This is true, but BMP became a bit of a kitchen-sink format, supporting all sorts of pixel formats, and optionally, compression. i.e. you'd still want to pick a subset to implement. To be honest, you're probably right - BMP would be more sensible starting point, but I'm interested to see how far PNG can be pushed.
pwg 3y ago
> I've also been pondering a backwards-compatible fork of PNG - but rather than a fork, mine would be a subset. Specifically, it would be an as-simple-as-possible uncompressed* bitmap format, suitable for use in low-complexity embedded systems etc. (e.g. bootloaders, wink wink). Look at the NetPBM formats (PPM, PGM, PGM). They are about as simple as they can possibly get (a tiny, ASCII, header, followed by binary bitmap data), and are also uncompressed. https://en.wikipedia.org/wiki/Netpbm https://en.wikipedia.org/wiki/Netpbm
- Retr0id 3y ago
  They're simple, but they're nowhere near as widely supported as PNG (or BMP)

summerlight 3y ago

What does it exactly mean by "100% backward compatible"? It looks like some optimizations could be backported to the existing encoder/decoder without breaking the format but this is more of an optimization. My impression is that this is backward compatible in a way similar to APNG (it will return some reasonable images if the file is using a new functionality), but I'm not sure if I understand it correctly.

tedunangst 3y ago

No mention of JPEG XT or JPEG-HDR? https://en.wikipedia.org/wiki/JPEG_XT https://en.wikipedia.org/wiki/JPEG_XT

phront 3y ago

meet a new bunch of security holes

snshn 3y ago

If APNG couldn't pick up steam and get widespread adoption, not sure how this will. But hopefully I'm wrong.

jeroenhd 3y ago
APNG is supported in every browser and all the video encoding tools I've used. It's not used all that often, but support for it is built into many software libraries.

ComputerGuru 3y ago

There’s no mention of what effect these changes have on file size. It seems to me all the non-HDR changes will blow up file sizes for all but the largest of images.

Exoristos 3y ago

Seeping?