Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new PNG spec

programmax.net

Post reply on HN
Print view View original

81–90 of 622 posts

Re: A new PNG spec

#81

Post by armada651 »

riffraff wrote: post #12
albert_e wrote: post #5

So animated GIFs can be replaced by Animated PNGs with alpha blending with transparent backgrounds and lossless compression! Some nostalgia from 2000s websites can be revived and relived :) Curious if Animated SVGs are also a thing. I remember seeing some Javascript based SVG animations (it was a animated chatbot avatar) - but not sure if there is any standard framework.

I was under the impression many gifs these days are actually served as soundless videos, as those basically compress better. Can animated PNG beat av1 or whatever?

> Can animated PNG beat av1 or whatever?

Animated PNGs can't beat GIF nevermind video compression algorithms.

Re: A new PNG spec

#82

Post by chithanh »

albert_e wrote: post #5

So animated GIFs can be replaced by Animated PNGs with alpha blending with transparent backgrounds and lossless compression! Some nostalgia from 2000s websites can be revived and relived :) Curious if Animated SVGs are also a thing. I remember seeing some Javascript based SVG animations (it was a animated chatbot avatar) - but not sure if there is any standard framework.

When it comes to converting small video snippets to animated graphics, I think WEBP was much better than APNG from the beginning. Only if you use GIF as intermediate format then APNG was competitive.

Nowadays, AVIF serves that purpose best I think.

Re: A new PNG spec

#83

Post by ay »

mystifyingpoi wrote: post #58
yoz-y wrote: post #47

Earlier quoted context omitted.

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.

Same thing with PNG. Just call the format with new additions it PNGX, so the user can clearly see that the reason their software can’t display the image is not a file corruption.

This is just pretending that if you have a cat and a dog in two bags and you call it “a bag”, it’s one and the same thing…

Re: A new PNG spec

#84

Post by fc417fc802 »

koito17 wrote: post #24
Lerc wrote: post #15

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

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

I honestly don't see an issue with the mpeg-4 example.

Regarding the potential for fragmentation of the png ecosystem the alternative is a new file format which has all the same support issues. Every time you author something you make a choice between legacy support and using new features.

From a developer perspective, adding support for a new compression type is likely to be much easier than implementing logic for an entirely new format. It's also less surface area for bugs. In terms of libraries, support added to a dependency propagates to all consumers with zero additional effort. Meanwhile adding a new library for a new format is linear effort with respect to the number of programs.

Re: A new PNG spec

#85

Post by DidYaWipe »

Aardwolf wrote: post #18
qwertox wrote: post #10

> Officially supports Exif data Probably the best news here. While you already can write custom data into a header, having Exif is good. BTW: Does Exif have a magnetometer (rotation) and acceleration (gravity) field? I often wonder about why Google isn't saving this information in the images which the camera app saves. It could help so much with post-processing, like with leveling the horizon or creating panoramas.

Exif can also cause confusion for how to render the image: should its rotation be applied or not? Old decoders and new decoders now could render an image with exif rotation differently since it's an optional chunk that can be ignored, and even for new decoders, the spec lists no decoder recommendations for how to use the exif rotation It does say "It is recommended that unless a decoder has independent knowledge of t…

The stupid thing is that any device with an orientation sensor is still writing images the wrong way and then setting a flag, expecting every viewing application to rotate the image.

The camera knows which way it's oriented, so it should just write the pixels out in the correct order. Write the upper-left pixel first. Then the next one. And so on. WTF.

Re: A new PNG spec

#87

Post by DidYaWipe »

josephg wrote: post #36
riffraff wrote: post #12

Earlier quoted context omitted.

I was under the impression many gifs these days are actually served as soundless videos, as those basically compress better. Can animated PNG beat av1 or whatever?

I doubt it, given png is a lossless compression format. For video thats almost never what you want.

For animations with lots of regions of solid color it could do very well.

Re: A new PNG spec

#88

Post by vanderZwan »

hrydgard wrote: post #60

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

I mean, if the spec has been stable for two decades then maybe there just hasn't been much to fix? Especially since PNG is a relatively simple image format.

Re: A new PNG spec

#89

Post by DidYaWipe »

Joel_Mckay wrote: post #25

DaVinci 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…

"PNG is popular with some Commercial Application developers, but the exposure and color problems still look 1980's awful in some use-cases."

What are you talking about? It's a bitmap. It has nothing to do with "exposure and color problems."

Re: A new PNG spec

#90

Post by fc417fc802 »

shiomiru wrote: post #74
Lerc wrote: post #15

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

> plenty of more advanced competing lossless formats

Other than JXL which still has somewhat spotty support in older software? TIFF comes to mind but AFAIK its size tends to be worse than PNG. Edit: Oh right OpenEXR as well. How widespread is support for that in common end user image viewer software though?

Post reply on HN