Live data from Hacker News

A new PNG spec

programmax.net

531–540 of 622 posts

Re: A new PNG spec

#531

Reading the linked blog post on the new cICP chunk type [0], it looks like the "proper HDR support" isn't something that you couldn't already do with an embedded ICC profile, but instead a much-abbreviated form of the colorspace information suitable for small image files. [0] https://svgees.us/blog/cICP.html

Unfortunately that seems to mean that the backwards compatibility here is washed out preview instead of limited-to-sRGB.

Re: A new PNG spec

#532

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's the correct pronunciation the same way the correct pronunciation for GIF is jiff. Human language is not something you can prescribe.

Re: A new PNG spec

#533
post #325
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

The only logic I ever hear for using a hard G is because that's how Graphics is said. Yet I never hear people saying jay-feg.

As with all other pronunciations the real reason is because it sounds better (more correct) to most people.

Re: A new PNG spec

#534

Earlier quoted context omitted.

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

When someone makes a baby, you call that person by their real name with the correct pronunciation, don’t you? So why can’t you do that with GIF or PNG? People that create things get to name them.

You are aware that kids generally don't get to pick the nicknames they end up being called and their parents definitely don't either.

Re: A new PNG spec

#535

Earlier quoted context omitted.

Linguistic prescriptivism is wrong , and people who promote it are showing they have zero respect for others when they don't have to.

Linguistic prescriptivism has nothing to do with it. English has both pronunciations for "gi" based on origin. Giraffe, giant, ginger, etc from Latin; gift, give, (and presumably others) from Germanic roots. Using the preferred one is just a matter of politeness. Also, it's quite ironic to prescribe "linguistic prescriptivism" as wrong.

Insisting on one out of multiple possible pronunciations when most people naturally pick a different one is the definition of linguistic prescriptivism. Politeness doesn't have anything to do with it, people are not required to let individuals dictate how our collective language works.

Re: A new PNG spec

#536
post #96
post #71

Earlier quoted context omitted.

It's poor, only because Google is using their stranglehold on browsers, to push their own WebP trash. That company can't get broken up soon enough.

Firefox also doesn’t support JPEG XL out of the box, and Chrome does support the new PNG, so ¯\_(ツ)_/¯.

Firefox is there to prevent/delay the forced breakup of Googles monopoly no to provide any real competition, thanks for showing another example of that.

Re: A new PNG spec

#537
I'm worried that by supporting too many encodings and color spaces this will hamper adoption and unexpected unsupported files. Perhaps this is more of an encoder/decoder library issue, which hopefully will give us rec2020 rgb32/rgb10a2 encode/decode apis so we can simply use them without having to know so many details.

Re: A new PNG spec

#538

Earlier quoted context omitted.

[flagged]

Those are indeed the "magic" bytes of PNG. It's a very clever choice meant to ensure the transport layer didn't mess with it. To start, there's a byte with the upper bit set which ensures an "8-bit clean" transport. If it's stripped, it becomes a harmless tab. Then the literal "PNG" text so you can see it in a text editor. Then a CR-LF pair to check for CR-LF to LF translations. Then, a CTRL-Z to stop display on DOS-…

It's clever but I'm not so sure it actually mattered - other formats have done just as well with simpler magic numbers. All it does in the end is that you get something that doesn't identify as a PNG file rather than a PNG file with bad data when a non-binary transport is used - both results are bad and immediately apparent.

Re: A new PNG spec

#539

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.

completely fails the second you want to do anything more than load it on a webpage Photoshop still won’t open it, MacOS preview opens it but then demands to convert it to tiff when you try to edit it

GIMP and Gwenview have supported webp (the latter via platform image plugins that add support to other applications as well) since before you encountered them online. Maybe choose better tools.

Re: A new PNG spec

#540

Until everything new is "optional". Hopefully PNG won't be the target of "enshitification". We all know that for file formats, there is a very strong pressure from developers and vendors for that to happen since it favors, hard, vendor and developer lock-in. If not careful, even with a team of PHD devs won't be able to write alternatives encoders/decoders that "reasonbly" and the world will end-up with very few alter…

Everything new is optional. This is not a breaking change. Old PNGs and software continue to work just fine. And these new changes are backwards-compatible as much as they can be. So old software can display a new PNG and be mostly correct. By that I mean, the user will still say "it is a picture of a red apple". But if the software isn't HDR, they might not get the bright highlights and inky blacks of the HDR PNG.

What is the remaining pertinent value of HDR since we are moving towards xrgb16161616 pixel format?
Post reply on HN