71–80 of 622 posts
Earlier quoted context omitted.
I doubt it can get anywhere near. What is even the point of a new PNG version if there's something as advanced as JXL that is also royalty-free?
Browser support for JPEG XL is poor (basically only Safari I think), while the new PNG spec is already supported by all mainstream browsers.
> 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.
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.
In an ideal world, yes. In practice however, if some field doesn't change often, then software will start to assume that it never changes, and break when it does.
TLS has learned this the hard way when they discovered that huge numbers of existing web servers have TLS version intolerance. So now TLS 1.2 is forever enshrined in the ClientHello.
>After 20 years of stagnation, PNG is back with renewed vigor! After 20 years of success, we can't resist the temptation to mess with what works.
> 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.
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.
And considering we already have plenty of more advanced competing lossless formats, I really don't see why "feed a BMP to deflate" needs a new, incompatible spin in 2025.
> 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.
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.
Official support for animations, yes! This feels so nostalgic to me, I have written an L-system generator with support for exporting animated PNGs 11 years ago! They were working only in Firefox, and Chrome used to have an extension for them. Too bad I had to take the website down. Back then, there were no libraries in C# for it, but it's actually quite easy to make APNG from PNGs directly by writing chunks with corr…
While I welcome that there is now PNG with animations, I am less impressed about how Mozilla chose to push for it.
Using PNG's magic numbers and pretend to existing software that it is just normal PNG? That is the same mindset that lead to HTML becoming tag soup. After all, HTML with a tag is still HTML, no?
I think they could have achieved animated PNG standardization much faster with a more humble and careful approach.
Earlier quoted context omitted.
Extending the format just because you can – and breaking backwards compatibility along the way – is even more pointless. If you've created an extensible file format, but you never need to extend it, you've done everything right, I'd say.
What about an extensible format that would have as part of header an algorithm (in some recognized DSL) of how to decompress it (or any other step required for image manipulation)? I know its not so much about PNG but some future format. That's what I would call really extensible, but then there may be no limits and hacking/viruses could have easily a field day.
Will sooner or later be used to implement RCEs. Even if you could do a restriction as is done for eBPF, that code still has to execute.
Best would be not to extend it.
>After 20 years of stagnation, PNG is back with renewed vigor! After 20 years of success, we can't resist the temptation to mess with what works.
Yea I'm mildly concerned about this as well. PNG's age is a feature, in a time where software development has gone to hell.