What if we kind of fit JXL in PNG? That way it's more likely to be supported
A new PNG spec
51–60 of 622 posts
Re: A new PNG spec
#52DaVinci Resolve also supports OpenEXR format with the added magic of LUT. PNG is popular with some Commercial Application developers, but the exposure and color problems still look 1980's awful in some use-cases. Even after spending a few grand on seats for a project, one still gets arrogant 3D clown-ware vendors telling people how they should run their pipeline with PNG hot garbage as input. People should choose EXR…
What are some "consistent color standards" you'd recommend? Honest question.
Re: A new PNG spec
#53> 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.
Does usb-c spec break backward compatibility ?, a 2018 macbook work perfectly fine with 2025 usb c charger
[deleted]
Re: A new PNG spec
#54> 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.
> Having an extensible format and electing never to extend it seems pointless.
So then it was pointless for PNG to be extensible? Not sure what your argument is.
Re: A new PNG spec
#55Official 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 correct headers, no encoders needed (assuming PNGs are already encoded as input).
https://github.com/NightElfik/Malsys/blob/master/src/Malsys....
Re: A new PNG spec
#56Earlier quoted context omitted.
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.
The problem is not backward compatibility but labeling. A USB-C cable looks universal but isn’t. Some of them just charge, some do data, some do PD, some give you access to high speed. But there is no way to know. I believe the problem here is that you will have PNG images that “look” like you can open them but can’t.
the parent said "changing the compression algorithm will break backwards compatibility", which i assume is something works now won't work in the future. The usb-c spec is intentionally trying to avoid that.
Re: A new PNG spec
#57I'm very curious to see how this will end up stacking up vs lossless jpegxl
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.
Re: A new PNG spec
#58Earlier quoted context omitted.
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.
The problem is not backward compatibility but labeling. A USB-C cable looks universal but isn’t. Some of them just charge, some do data, some do PD, some give you access to high speed. But there is no way to know. I believe the problem here is that you will have PNG images that “look” like you can open them but can’t.
Cable labeling could fix 99% of the issues with USB-C compat. The solution should never be blaming consumer for buying the wrong cable. Crappy two-wire charge-only cables are perfectly fine for something like a night desk lamp. Keep the poor cables, they are okay, just tell me if that's the case.
Re: A new PNG spec
#59Earlier quoted context omitted.
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.
The problem is not backward compatibility but labeling. A USB-C cable looks universal but isn’t. Some of them just charge, some do data, some do PD, some give you access to high speed. But there is no way to know. I believe the problem here is that you will have PNG images that “look” like you can open them but can’t.
Some aren't even USB. Thunderbolt and DisplayPort both use USB-C too.
Re: A new PNG spec
#60What about implementations? libpng seems pretty dead, 1.7 has been in development forever but 1.6 is still considered the stable version. Is there a current "canonical" png C/C++ library?