Live data from Hacker News

A new PNG spec

programmax.net

191–200 of 622 posts

Re: A new PNG spec

#191
post #117

Earlier quoted context omitted.

But where the analogy with USB-C is very good is that just like USB-C, there is no way for a user to tell from the look of the port or the file extension what the capabilities are. Which even for a fairly tech savvy user like me is frustrating. I have a bunch of cables, some purchased years ago, how do I know what is fit for what? And now think of the younger generation that has grown up with smartphones and have bee…

> there is no way for a user to tell from the look of the port or the file extension what the capabilities are But that's typical for file extensions. Consider EXE – it is probably an executable, but an executable for what? Most commonly Windows – but which Windows version will this EXE run on? Maybe this EXE only works on Windows 11, and you are still running Windows 10. Or maybe you are running x86-64 Windows, but…

Just last week I had again some PDFs Okular could not open because of some more uncommon form features.

Re: A new PNG spec

#192

Earlier quoted context omitted.

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.

TIL, and hard agree (on face value). I’ve been struck by this with arbitrary rotation of images depending on application, very annoying.

What are the arguments for this? It would seem easier for everyone to rotate and then store exif for the original rotation if necessary.

Re: A new PNG spec

#193

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.

5% of people can't view them, yet 25% of top websites use them? In what other industry would it be considered acceptable to exclude 5% of visitors/users/clients?

Any industry.

e.g. cars - not everyone is physically able to drive books - blind people can't read music - deaf people can't hear

It is a form of 80/20 or 90/10 rule the last small percentage costs as much as the majority.

Re: A new PNG spec

#194
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

What about transparency? That’s the main benefit of PNG imo.

Re: A new PNG spec

#195
post #183
post #176

Earlier quoted context omitted.

Maybe the issue is with your operating system then?

App support has very little to do with the operating system. OSes by and large will preview it just fine.

on the contrary. on macOS apps don't have to support image (or movie) formats. it is done by the system and transparently handled by the APIs. apps automatically gain new formats when the system adds it.

Re: A new PNG spec

#197
post #183

Earlier quoted context omitted.

App support has very little to do with the operating system. OSes by and large will preview it just fine.

on the contrary. on macOS apps don't have to support image (or movie) formats. it is done by the system and transparently handled by the APIs. apps automatically gain new formats when the system adds it.

The unfortunate side effect of this convenience is that apps automatically lose image support when macOS chases to no longer support them, too.

One example is Sony's SRF camera raw format.

Programs like Photoshop and Affinity have to bring their own decoders where previously none were required.

Re: A new PNG spec

#198

A fun fact about PNG, the correct pronunciation is defined in the specification > PNG is pronounced “ping” See the end of Section 1 [0] 0: https://www.w3.org/TR/REC-png.pdf

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

Re: A new PNG spec

#199

A fun fact about PNG, the correct pronunciation is defined in the specification > PNG is pronounced “ping” See the end of Section 1 [0] 0: https://www.w3.org/TR/REC-png.pdf

Because the creator of gifs telling the world how he pronounced it made such a huge difference :)

Not sure I'll bother to reprogram myself from “png”, “pung”, or “pee-enn-gee”.

Re: A new PNG spec

#200

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.

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
Post reply on HN