Live data from Hacker News

A new PNG spec

programmax.net

261–270 of 622 posts

Re: A new PNG spec

#261

Seems a bit too late? And also, JPEG XL supports all the features and uses already advanced compression (finite-state entropy, like ZStandard). It offers lossy and lossless compression, animated pictures, HDR, EXIF etc. There is just no need for a PNG update, just adopt JPEG XL.

I really don’t get it. Why, but why? It’s already confusing as hell, why create yet another standard (variant) with no unique selling point?

Re: A new PNG spec

#262
post #198

Earlier quoted context omitted.

That makes two image format names which I will refuse to pronounce correctly (the other being GIF [1]). [1] https://edition.cnn.com/2013/05/22/tech/web/pronounce-gif

How do you pronounce PNG?

P&G, stands for Pee & Gloat.

Re: A new PNG spec

#263
post #170

It is just a spec on something widely implemented already. Assuming Next gen PNG will still require new decoder. They could just call it PNG2. JPEG-XL already provides everything most people asked for a lossless codec. If there are any problems it is its encoding and decoding speed and resources. Current champion of Lossless image codec is HALIC. https://news.ycombinator.com/item?id=38990568

> If there are any problems it is its encoding and decoding speed and resources.

And this will improve over time, like jpg encoders and decoders did.

Re: A new PNG spec

#264

Not backwards compatible. We just add it to that nice cupboard "great advanced image formats we will forget about". Society doesn't need a new image format. I'd wager to say not any new multimedia format. Big corporate entites do, and have churning them out at a steady pace. Look at poor webp - a format pushed by the largest industry players - and the abysmal everyday use it gets, and the hate it generates.

> Look at poor webp What about it? "Lossless WebP is typically 26% smaller than PNG, while lossy WebP can be 25-34% smaller than JPEG at equivalent quality levels" This literally saves houndred of thousand of cost, bandwith, electricity every month on the internet. In fact, I strongly belive that this is one of the greatest contributions from Google to society just like ZSTD from Facebook. https://developers.google.c…

I don't think the commenter you replied to disagrees with any of that. They were talking about poor rates of adoption, not its feature set.

Re: A new PNG spec

#265

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.

Seems that logic does not apply to jpeg though.

Re: A new PNG spec

#266

Earlier quoted context omitted.

> and the abysmal everyday use it gets Estimates are that 95% of Internet users have a browser that supports WebP and that ~25% of the top million websites serve WebP images. I wouldn't call that abysmal.

Great, so I can download it, but then I have to convert it to a different format before half my apps will be able to use it.

I was about to write that Slack doesn't support webp but I just tested it and it does. For years I have been typing "convert file.webp file.jpg" and then posting that in slack but it looks like they have added support.

Re: A new PNG spec

#267

Earlier quoted context omitted.

My file manager can’t handle them but my browser can. Edit: and good luck uploading the format to the majority of webforms that aren’t faang.

If you are using an image optimization service like Imgix / Cloudflare Image Resizing then it doesn't really matter, image can be uploaded as any supported format and will be sent to the end user according to their "Accept" header

if you’d like to go and implement that in all the millions of existing web apps, go ahead?

Let’s also not forget the dependency mess that leaves in applications before we do though..

Re: A new PNG spec

#268

Earlier quoted context omitted.

> What are the arguments for this? It would seem easier for everyone to rotate and then store exif for the original rotation if necessary. Performance. Rotation during rendering is often free, whereas the camera would need an intermediate buffer + copy if it's unable to change the way it samples from the sensor itself.

How is rotation during rendering free?

Pretty much every pixel rendered these days was generated by a shader so gpu side you probably already have way more translation options than just a 90° rotation (likely already being used for a rotation of 0°). You'd likely have to write more code cpu side to handle the case of tell the gpu to rotate this please and handle the UI layout diffrence. Honestly not a lot of code.

Re: A new PNG spec

#270
post #264

Earlier quoted context omitted.

> Look at poor webp What about it? "Lossless WebP is typically 26% smaller than PNG, while lossy WebP can be 25-34% smaller than JPEG at equivalent quality levels" This literally saves houndred of thousand of cost, bandwith, electricity every month on the internet. In fact, I strongly belive that this is one of the greatest contributions from Google to society just like ZSTD from Facebook. https://developers.google.c…

I don't think the commenter you replied to disagrees with any of that. They were talking about poor rates of adoption, not its feature set.

The biggest driver of adoption are features.

"WebP is used by 16.7% of all websites. This means that while it's a popular image format, it's not yet the dominant format, with JPEG still holding the majority share at 73.0%, according to W3Techs. However, WebP offers significant advantages in terms of compression and file size, making it a preferred choice for many web developers. "

Post reply on HN