6 ms·

> I know you all immediately wondered, better compression?. We're already working on that. This worries me. Because presumably, changing the compression algori

> I know you all immediately wondered, better compression?. We're already working on that. This worries me. Because presumably, changing the compression algorithm will break backwards compatibility, which means we'll start to see "png" files that aren't actually png files. It'll be like USB-C but for images.

skywal_l 1y ago
Can't you improve a compression algorithm and still produce a still valid decompression input? PNG is based on zip, there's certainly ways to improve zip without breaking backwards compatibility. That being said, they also can do dumb things however, right at the end of the sentence you quote they say: > we want to make sure we do it right. So there's hope.
- masklinn 1y ago
  > Can't you improve a compression algorithm and still produce a still valid decompression input? PNG is based on zip, there's certainly ways to improve zip without breaking backwards compatibility. That's just changing an implementation detail of the encoder, and you don't need spec changes for that e.g. there are PNG compressors which support zopfli for extra gains on the DEFLATE (at a non-insignificant cost). This is transparent to the client as the output is still just a DEFLATE stream.
- vhcr 1y ago
  That's what OptiPNG already does.
  - josefx 1y ago
    Doesn't OptiPNG just brute force various settings and pick the best result?
lifthrasiir 1y ago
Better compression can also mean a new set of filter methods or a new interlacing algorithm. But yeah, any of them would cause an instant incompatibility. As noted in the relevant issue [1], we will need a new media type at the very least. [1] https://github.com/w3c/png/issues/39#issuecomment-2674690324 https://github.com/w3c/png/issues/39#issuecomment-2674690324
- snvzz 1y ago
  I am hopeful whatever better compression doesn't end up multiplying memory requirements, or increase burden on cpu, especially on decompression. Now, PNG datatype for AmigaOS will need upgrading.
  - clownpenis_fart 1y ago
    [dead]
  - Arnt 1y ago
    I don't see why? If your video output is plain old RGB (like the Amiga hardware), then an unmodified decoder will handle new files without a problem. You only need a new decoder if your video output can handle more vivid colours than RGB can express.
    - Findecanor 1y ago
      An image decoded in the wrong colour space for the output will look wrong. It is not using extra bits to express the increased dynamic range: the existing numeric range is stretched and warped.
      - Arnt 1y ago
        Yes. But how bad? AIUI the way it's done is more or less the best that can be done with old video hardware, like mine and like the Amiga. It could be horrible in principle, but actually isn't.
- Arnt 1y ago
  We would need a new media type. But the actual new features don't need one, because the news don't break compatibility. https://svgees.us/blog/img/revoy-cICP-bt.2020.png https://svgees.us/blog/img/revoy-cICP-bt.2020.png uses the new colour space. If your software and monitor can handle it, you see better colour than I, otherwise, you see what I see.
Lerc 1y ago
It has fields to say what compression is used. Adding another compression form should be handled by existing software as recognizing it as a valid PNG that they can't decompress. The PNG format is specifically designed to allow software to read the parts they can understand and to leave the parts they cannot. Having an extensible format and electing never to extend it seems pointless.
- mort96 1y ago
  > Adding another compression form should be handled by existing software as recognizing it as a valid PNG that they can't decompress. Yeah, we know. That's terrible.
- koito17 1y ago
  > Having an extensible format and electing never to extend it seems pointless. This proves OP analogy regarding USB-C. Having PNG as some generic container for lossless bitmap compression means fragmentation in libraries, hardware support, etc. The reason being that if the container starts to support too many formats, implementations will start restricting to only the subsets the implementers care about. For instance, almost nobody fully implements MPEG-4 Part 3; the standard includes dozens of distinct codecs. Most software only targets a few profiles of AAC (specifically, the LC and HE profiles), and MPEG-1 Layer 3 audio. Next to no software bothers with e.g. ALS, TwinVQ, or anything else in the specification. Even libavcodec, if I recall correctly, does not implement encoders for MPEG-4 Part 3 formats like TwinVQ. GP's fear is exactly this -- that PNG ends up as a standard too large to fully implement and people have to manually check which subsets are implemented (or used at all).
  - bayindirh 1y ago
    JPEG is no different. Only the decoder is specified. As long as the decoder decodes what you give it to the image you wanted to see, you can implement anything. This is how imgoptim/squash/aerate/dietJPG works. By (ab)using this flexibility. 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.
colanderman 1y ago
One could imagine a PNG file which contains a low-resolution version of the image with a traditional compression algorithm, and encodes additional higher-resolution detail using a new compression algorithm.
mrheosuper 1y ago
Does usb-c spec break backward compatibility ?, a 2018 macbook work perfectly fine with 2025 usb c charger
- techpression 1y ago
  I don’t know if it’s the spec or just a plethora of vendors that ignores it, but I have many things with a USB-C port that requires USB-A as source. USB-C to A to C works, yay dongles, but not just C to C. So maybe it’s not really breaking backwards compatibility, just a weird mix of a port and the communication being separate standards.
  - mrheosuper 1y ago
    because those usb-c ports do not follow the spec. If they had followed the spec from 1st day there would be no problem even now.
  - fragmede 1y ago
    it's vendors just changing the physical port but not updating the electronics. specifically, a 5.1kΩ pull-up resistors on the CC1 and/or CC pins is needed on the host (was usb-a) side in order for the c to c cable to work.
- danielheath 1y ago
  Some things don't work unless you use the right kind of USB-C cable. EG your GPU and monitor both have a USB-C port. Plug them together with the right USB cable and you'll get images displayed. Plug them together with the wrong USB cable and you won't. USB 3 didn't have this issue - every cable worked with every port.
  - mrheosuper 1y ago
    That is not backward compatible problem. If a cable that does 100w charging when using pd2.0, but only 60w when using with pd3.1 device, then i would agree with you.
bmacho 1y ago
+1 why not name it png4 or something. It's better if compatibility is obvious upfront
- josephg 1y ago
  I think if they did that, nobody would use it. And anyway, from the article: > Many of the programs you use already support the new PNG spec: Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer... It might be too late to rename png to .png4 or something. It sounds like we're using the new png standard already in a lot of our software.
jillesvangurp 1y ago
Old PNGs will work just fine. And forward compatibility is much less important. The main use case for PNG is web browsers and all of them seem to be on board. Using old web browsers is a bad idea. You do get these relics showing up using some old version of internet explorer. But some images not rendering is the least of their problems. The main challenge is actually going to be updating graphics tools to export the new files. And teaching people that sRGB maybe isn't good enough any more. That's going to be hard since most people have no clue about color spaces. Anyway, that gives everybody plenty of time to upgrade. By the time this stuff is widely used, it will be widely supported. So, you kind of get forward compatibility that way. Your browser already supports the new format. Your image editor probably doesn't.
- deleted 1y ago
  [deleted]
- hnlmorg 1y ago
  Browsers aren't the only software that work with PNGs. Far from it in fact.
- AlienRobot 1y ago
  >The main use case for PNG is web browsers This is news to me. I'm pretty sure the main use case for PNG is lossless transparent graphics.
  - asadotzler 1y ago
    Depends on whose use cases you're considering. 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.
ajnin 1y ago
What backward compatibility are we talking about here? Backwards compatibility of images will be fine, backwards compatibility of decoders might be impacted, but the article says the major image viewers (browsers) and image editors already support the 3rd version. Better compression is only planned for the 5th version of the spec. Also if you forbid evolving existing formats, the only alternative to improve is to introduce a new format, and I argue that it would be causing even more fragmentation and be more difficult to adopt to. Look at all the drama surrounding JPEG XL.
altairprime 1y ago
They could, for example, use lossy compression for the compatibility layer and then fill it in the rest of the way to lossless using incompatible new compression objects. Legacy uses will see some fidelity degradation, but they are already being stuck with sRGB downmixes, so that’s fine — and those who are bothered by it can just emit a lossless-pixels (but lossy-color and lossy-range) compatibility layer and reserve the compression benefits for the color and dynamic range. I’m not saying this is what will happen — but if I was able to construct a plausible approach to compression in ten minutes, then perhaps it’s a bit early to predict the doom of compatibility.
bawolff 1y ago
I don't think that will super be an issue. How often has "progressive jpeg" ever caused problems? That's the same thing.
ProgramMax 1y ago
Worry not! (Well, worry a little.) The first bit of our research is "What can we already make use of which requires no spec update? There are plenty of PNG optimizers. How much of that should go into the typical PNG libraries?" Same with parallel encoding & decoding. An older image viewer will be able to decode it on one thread without ever knowing parallel decoding was an option. Here's the worry-a-little part: Everybody immediately jumps to file size as to what image compression is better or worse. That isn't the best take, but it is what it is. So there is pressure to adopt newer technologies. We often do have a way to maintain some degree of backwards compatibility even when we do this. For example, we can store a downsampled image for old viewers. Then extra, new chunks will know "Mix that with this full scale data, using a different compression". As you can imagine, this mixing complicates things. It might not be the best option. Sooooo we're researching it :)
- ori_b 1y ago
  My strong vote is to just not touch it. Stability is a feature.
- HexDecOctBin 1y ago
  Downsampling will make PNG not be a lossless format. Just leave it alone, and work on a separate PNG2 or PNGX or whatever.

skywal_l 1y ago

Can't you improve a compression algorithm and still produce a still valid decompression input? PNG is based on zip, there's certainly ways to improve zip without breaking backwards compatibility. That being said, they also can do dumb things however, right at the end of the sentence you quote they say: > we want to make sure we do it right. So there's hope.

masklinn 1y ago
> Can't you improve a compression algorithm and still produce a still valid decompression input? PNG is based on zip, there's certainly ways to improve zip without breaking backwards compatibility. That's just changing an implementation detail of the encoder, and you don't need spec changes for that e.g. there are PNG compressors which support zopfli for extra gains on the DEFLATE (at a non-insignificant cost). This is transparent to the client as the output is still just a DEFLATE stream.
vhcr 1y ago
That's what OptiPNG already does.
- josefx 1y ago
  Doesn't OptiPNG just brute force various settings and pick the best result?

lifthrasiir 1y ago

Better compression can also mean a new set of filter methods or a new interlacing algorithm. But yeah, any of them would cause an instant incompatibility. As noted in the relevant issue [1], we will need a new media type at the very least. [1] https://github.com/w3c/png/issues/39#issuecomment-2674690324 https://github.com/w3c/png/issues/39#issuecomment-2674690324

snvzz 1y ago
I am hopeful whatever better compression doesn't end up multiplying memory requirements, or increase burden on cpu, especially on decompression. Now, PNG datatype for AmigaOS will need upgrading.
- clownpenis_fart 1y ago
  [dead]
- Arnt 1y ago
  I don't see why? If your video output is plain old RGB (like the Amiga hardware), then an unmodified decoder will handle new files without a problem. You only need a new decoder if your video output can handle more vivid colours than RGB can express.
  - Findecanor 1y ago
    An image decoded in the wrong colour space for the output will look wrong. It is not using extra bits to express the increased dynamic range: the existing numeric range is stretched and warped.
    - Arnt 1y ago
      Yes. But how bad? AIUI the way it's done is more or less the best that can be done with old video hardware, like mine and like the Amiga. It could be horrible in principle, but actually isn't.
Arnt 1y ago
We would need a new media type. But the actual new features don't need one, because the news don't break compatibility. https://svgees.us/blog/img/revoy-cICP-bt.2020.png https://svgees.us/blog/img/revoy-cICP-bt.2020.png uses the new colour space. If your software and monitor can handle it, you see better colour than I, otherwise, you see what I see.

Lerc 1y ago

It has fields to say what compression is used. Adding another compression form should be handled by existing software as recognizing it as a valid PNG that they can't decompress. The PNG format is specifically designed to allow software to read the parts they can understand and to leave the parts they cannot. Having an extensible format and electing never to extend it seems pointless.

mort96 1y ago
> Adding another compression form should be handled by existing software as recognizing it as a valid PNG that they can't decompress. Yeah, we know. That's terrible.
koito17 1y ago
> Having an extensible format and electing never to extend it seems pointless. This proves OP analogy regarding USB-C. Having PNG as some generic container for lossless bitmap compression means fragmentation in libraries, hardware support, etc. The reason being that if the container starts to support too many formats, implementations will start restricting to only the subsets the implementers care about. For instance, almost nobody fully implements MPEG-4 Part 3; the standard includes dozens of distinct codecs. Most software only targets a few profiles of AAC (specifically, the LC and HE profiles), and MPEG-1 Layer 3 audio. Next to no software bothers with e.g. ALS, TwinVQ, or anything else in the specification. Even libavcodec, if I recall correctly, does not implement encoders for MPEG-4 Part 3 formats like TwinVQ. GP's fear is exactly this -- that PNG ends up as a standard too large to fully implement and people have to manually check which subsets are implemented (or used at all).
- bayindirh 1y ago
  JPEG is no different. Only the decoder is specified. As long as the decoder decodes what you give it to the image you wanted to see, you can implement anything. This is how imgoptim/squash/aerate/dietJPG works. By (ab)using this flexibility. 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.

colanderman 1y ago

One could imagine a PNG file which contains a low-resolution version of the image with a traditional compression algorithm, and encodes additional higher-resolution detail using a new compression algorithm.

mrheosuper 1y ago

Does usb-c spec break backward compatibility ?, a 2018 macbook work perfectly fine with 2025 usb c charger

techpression 1y ago
I don’t know if it’s the spec or just a plethora of vendors that ignores it, but I have many things with a USB-C port that requires USB-A as source. USB-C to A to C works, yay dongles, but not just C to C. So maybe it’s not really breaking backwards compatibility, just a weird mix of a port and the communication being separate standards.
- mrheosuper 1y ago
  because those usb-c ports do not follow the spec. If they had followed the spec from 1st day there would be no problem even now.
- fragmede 1y ago
  it's vendors just changing the physical port but not updating the electronics. specifically, a 5.1kΩ pull-up resistors on the CC1 and/or CC pins is needed on the host (was usb-a) side in order for the c to c cable to work.
danielheath 1y ago
Some things don't work unless you use the right kind of USB-C cable. EG your GPU and monitor both have a USB-C port. Plug them together with the right USB cable and you'll get images displayed. Plug them together with the wrong USB cable and you won't. USB 3 didn't have this issue - every cable worked with every port.
- mrheosuper 1y ago
  That is not backward compatible problem. If a cable that does 100w charging when using pd2.0, but only 60w when using with pd3.1 device, then i would agree with you.

bmacho 1y ago

+1 why not name it png4 or something. It's better if compatibility is obvious upfront

josephg 1y ago
I think if they did that, nobody would use it. And anyway, from the article: > Many of the programs you use already support the new PNG spec: Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer... It might be too late to rename png to .png4 or something. It sounds like we're using the new png standard already in a lot of our software.

jillesvangurp 1y ago

Old PNGs will work just fine. And forward compatibility is much less important. The main use case for PNG is web browsers and all of them seem to be on board. Using old web browsers is a bad idea. You do get these relics showing up using some old version of internet explorer. But some images not rendering is the least of their problems. The main challenge is actually going to be updating graphics tools to export the new files. And teaching people that sRGB maybe isn't good enough any more. That's going to be hard since most people have no clue about color spaces. Anyway, that gives everybody plenty of time to upgrade. By the time this stuff is widely used, it will be widely supported. So, you kind of get forward compatibility that way. Your browser already supports the new format. Your image editor probably doesn't.

deleted 1y ago
[deleted]
hnlmorg 1y ago
Browsers aren't the only software that work with PNGs. Far from it in fact.
AlienRobot 1y ago
>The main use case for PNG is web browsers This is news to me. I'm pretty sure the main use case for PNG is lossless transparent graphics.
- asadotzler 1y ago
  Depends on whose use cases you're considering. 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.

ajnin 1y ago

What backward compatibility are we talking about here? Backwards compatibility of images will be fine, backwards compatibility of decoders might be impacted, but the article says the major image viewers (browsers) and image editors already support the 3rd version. Better compression is only planned for the 5th version of the spec. Also if you forbid evolving existing formats, the only alternative to improve is to introduce a new format, and I argue that it would be causing even more fragmentation and be more difficult to adopt to. Look at all the drama surrounding JPEG XL.

altairprime 1y ago

They could, for example, use lossy compression for the compatibility layer and then fill it in the rest of the way to lossless using incompatible new compression objects. Legacy uses will see some fidelity degradation, but they are already being stuck with sRGB downmixes, so that’s fine — and those who are bothered by it can just emit a lossless-pixels (but lossy-color and lossy-range) compatibility layer and reserve the compression benefits for the color and dynamic range. I’m not saying this is what will happen — but if I was able to construct a plausible approach to compression in ten minutes, then perhaps it’s a bit early to predict the doom of compatibility.

bawolff 1y ago

I don't think that will super be an issue. How often has "progressive jpeg" ever caused problems? That's the same thing.

ProgramMax 1y ago

Worry not! (Well, worry a little.) The first bit of our research is "What can we already make use of which requires no spec update? There are plenty of PNG optimizers. How much of that should go into the typical PNG libraries?" Same with parallel encoding & decoding. An older image viewer will be able to decode it on one thread without ever knowing parallel decoding was an option. Here's the worry-a-little part: Everybody immediately jumps to file size as to what image compression is better or worse. That isn't the best take, but it is what it is. So there is pressure to adopt newer technologies. We often do have a way to maintain some degree of backwards compatibility even when we do this. For example, we can store a downsampled image for old viewers. Then extra, new chunks will know "Mix that with this full scale data, using a different compression". As you can imagine, this mixing complicates things. It might not be the best option. Sooooo we're researching it :)

ori_b 1y ago
My strong vote is to just not touch it. Stability is a feature.
HexDecOctBin 1y ago
Downsampling will make PNG not be a lossless format. Just leave it alone, and work on a separate PNG2 or PNGX or whatever.