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

11–20 of 622 posts

Re: A new PNG spec

#11

Post by masklinn »

skywal_l wrote: post #6
LeoPanthera wrote: post #3

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

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.

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

Re: A new PNG spec

#12

Post by riffraff »

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?

Re: A new PNG spec

#13

Post by vhcr »

skywal_l wrote: post #6
LeoPanthera wrote: post #3

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

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.

That's what OptiPNG already does.

Re: A new PNG spec

#14

Post by ggm »

Somebody needs to manage human time/date approximates in a way other people in s/w will align to.

"photo scanned in 2025, is about something in easter, before 1940 and after 1920"

Re: A new PNG spec

#15

Post by Lerc »

LeoPanthera wrote: post #3

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

Re: A new PNG spec

#16

Post by mattigames »

andsoitis wrote: post #8
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.

> Curious if Animated SVGs are also a thing. Yes. Relevant animation elements: • • • • See https://www.w3schools.com/graphics/svg_animation.asp

Overshadowed by CSS animations for almost all use cases.

Re: A new PNG spec

#17

Post by colanderman »

LeoPanthera wrote: post #3

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

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.

Re: A new PNG spec

#18

Post by Aardwolf »

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 the validity of the Exif data, the data should be considered to be of historical value only.", so hopefully the rotation will not be used by renderers, but it's only a vague recommendation, there's no strict "don't rotate the image" which would be the only backwards compatible way

With jpeg's exif, there have also been bugs with the rotation being applied twice, e.g. desktop environment and underlying library both doing it independently

Re: A new PNG spec

#19

Post by jandrese »

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.

Yes, but websites frequently strip all or almost all Exif data from uploaded images because some fields are used by stalkers to track people down to their real address.

Re: A new PNG spec

#20

Post by andsoitis »

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.

There is no standard field to record readouts of a camera's accelerometers or inertial navigation system.

Exif fields: https://exiv2.org/tags.html

Post reply on HN