>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.
> [not] Officially supports Exif data
How can you call this basic fail a success?
A new PNG spec
121–130 of 622 posts
Re: A new PNG spec
#122Earlier quoted context omitted.
> 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…
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 sp…
Video files aren't a good analogy. Before God placed VLC and ffmpeg on earth, you had to install a galaxy of codecs on your computer to get a chance to read a video file and you could never tell exactly what codec was stored in a container, nor if you had the right codec version. Unfortunately there is no vlc and ffmpeg for images (I mean there is, the likes of imagemagick, but the vast majority of software doesn't use them).
Re: A new PNG spec
#123Parallel compression/decompression is already possible via Z_SYNC_FLUSH.
Re: A new PNG spec
#124> 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
Yeah - it's a mess. Some devices only charge with a charger that supports PD. Some other devices need a charger WITHOUT PD support.
Re: A new PNG spec
#125Earlier quoted context omitted.
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.
> Cable labeling could fix 99% of the issues with USB-C compat. Labelling is a poor band-aid on the root problem - consumer cables which look identical and fit identically should work wherever they fit. There should never have been a power-only spec for USB-C socket dimensions. If a cable supports both power and data, it must fit in all sockets. If a cable supports only power it must not fit into a power and data soc…
> If a cable supports only power it must not fit into a power and data socket
That's even more confusing than the current state of affairs. If my phone has power and data socket, then I cannot use power only cable to only charge it? Presumably with the charger that has power only socket. So I need a cable with two different ends anyway. Just go micro-USB at this point :)
Funnily enough, there is a 100% overkill way to solve such issues. Just use super expensive certified TB cables. Well... plus a A-to-C adapter for noncompliant devices, I guess.
Re: A new PNG spec
#126> 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.
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…
[deleted]
Re: A new PNG spec
#127Earlier quoted context omitted.
And I strip Exif data, too, intentionally, for similar reasons.
That makes sense to me for any image you want to share publicly, but for private images having the location and capture time embedded in the image is incredibly useful.
If by private you mean "never shared", I agree.
Re: A new PNG spec
#128Earlier quoted context omitted.
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
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.
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.
Re: A new PNG spec
#129Earlier quoted context omitted.
I never once in 25 years encountered an issue with an mp4 Container that could Not be solved by installing either the divx or xvid codec. And I extensively used mp4's metatdat for music, even with esoteric Tags. Not Sure what youre talking abouz.
He's saying that in 25 years, you used only the LC and HE profiles, and didn't encounter TwinVQ even once. I looked at my thousand-odd MPEG-4 files. They're overwhelmingly AAC LC, a little bit of AAC LC SBR, no TwinVQ at all. If you want to check yours: mediainfo **/*.mp4 | grep -A 2 '^Audio' | grep Format | sort | uniq -c https://en.wikipedia.org/wiki/TwinVQ#TwinVQ_in_MPEG-4 tells the story of TwinVQ in MPEG-4.
[deleted]
Re: A new PNG spec
#130Earlier quoted context omitted.
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.
The difference between valid PNG you can't decompress and invalid PNG is fairly irrelevant when your aim is to get an image onto the screen. 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.
It's a new and compatible spin. https://svgees.us/blog/img/revoy-cICP-bt.2020.png uses the important new feature and your old software can display it.
More generally, PNG has a simple feature to specify what's needed. A file consists of a number of chunks, and one bit in the chunk specifies whether that chunk is required for display. All of the extensions I've seen in the past decades set that bit to "optional".
For example, this update includes a chunk containing EXIF data. As you'd expect, the exif chunk sets that bit to "optional".