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

471–480 of 622 posts

Re: A new PNG spec

#471

Post by ProgramMax »

LegionMammal978 wrote: post #448
ProgramMax wrote: post #424

Earlier quoted context omitted.

PNG previously supported ICC v2. That was updated to ICC v4. However, neither of these are capable of HDR. Maybe iccMAX supports HDR. I'm not sure. In either case, that isn't what PNG supported. So something new was required for HDR.

> However, neither of these are capable of HDR. How so? As far as I can tell, the ICCv2 spec is very agnostic as to the gamut and dynamic range of the output medium. It doesn't say anything to the extent of "thou shalt not produce any colors outside the sRGB gamut, nor make the white point too bright". Unless HDR support is supposed to be something other than just the primaries, white point, and transfer function. Al…

IIRC (been a while), the reason was ICCv2/v4 still requires a gamma function. And PQ is not a gamma function. Maybe they can cover HLG, but if we want to represent any given HDR content, we needed something more than ICCv2/v4.

Re: A new PNG spec

#472

Post by jdiff »

bastawhiz wrote: post #291
jdiff wrote: post #184

Earlier quoted context omitted.

Indeed, why might one upload a photo to the web in a format made for distributing images on the web?

I could save my photos as BMPs like early digital cameras did but that doesn't make it practical or reasonable. My camera takes pictures as RAW or HEIF files. Why would I save my photos to a primarily lossy codec that's optimized and designed for distribution rather than preserving fidelity? We used to do this with JPEG, in fact. And that's why many pictures on Facebook from pre-2018 or so all have a distinctive grai…

There's more on Instagram than photos. Lotta meme pages, lot of people just uploading random screenshots and photos they downloaded that have been turned over a million times. Heck, all it takes is someone downloading their own photo from SocialMediaX to reupload on SocialMediaY, or just uploading a the WebP that they exported for their website.

Re: A new PNG spec

#473

Post by 80x86 »

ProgramMax wrote: post #427

Author here. Hello everyone! Feel free to ask me anything. I'll go ahead and dispel some doubts I already see here: - It isn't really a "new format". It's an update to the existing format. - It is very backwards compatible. -- Old programs will load new PNGs to the best of their capability. A user will still know "that is a picture of a red apple". There also seems to be some confusion about how PNGs work internally.…

It would be nice if PNG supported no compression. That is handy in many situations.

Re: A new PNG spec

#474

Post by mrheosuper »

zirgs wrote: post #124
mrheosuper wrote: post #26

Earlier quoted context omitted.

Does usb-c spec break backward compatibility ?, a 2018 macbook work perfectly fine with 2025 usb c charger

Yeah - it's a mess. Some devices only charge with a charger that supports PD. Some other devices need a charger WITHOUT PD support.

If those devices follow the spec, they dont need charger without PD support.

You don't follow spec, you're on your own.

Re: A new PNG spec

#475

Post by HexDecOctBin »

ProgramMax wrote: post #391
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.

Worry not! (Well, worry a little.) The first bit of our research is "What can we already make use of which requires no spec update? There are plenty of PNG optimizers. How much of that should go into the typical PNG libraries?" Same with parallel encoding & decoding. An older image viewer will be able to decode it on one thread without ever knowing parallel decoding was an option. Here's the worry-a-little part: Ever…

Downsampling will make PNG not be a lossless format. Just leave it alone, and work on a separate PNG2 or PNGX or whatever.

Re: A new PNG spec

#476

Post by kmeisthax »

derefr wrote: post #446
ProgramMax wrote: post #427

Author here. Hello everyone! Feel free to ask me anything. I'll go ahead and dispel some doubts I already see here: - It isn't really a "new format". It's an update to the existing format. - It is very backwards compatible. -- Old programs will load new PNGs to the best of their capability. A user will still know "that is a picture of a red apple". There also seems to be some confusion about how PNGs work internally.…

So, I'm a big fan of metaformats with generalized tooling support. Think of e.g. Office Open XML or ePub — you don't need "an OOXML parser" / "an ePub parser" to parse these; they're both just zipped XML, so you just need a zipfile library and libxml. For the lifetime of PNG so far, a PNG file has almost, but just barely not , been a valid Interchange File Format (IFF) file. IFF is a great (simple to understand, simp…

[dead]

Re: A new PNG spec

#477

Post by Mr_Minderbinder »

dev_l1x_be wrote: post #258
poisonborz wrote: post #146

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…

Those numbers are from Google. Third parties have not found WebP to be as good as Google claims.

Re: A new PNG spec

#478

Post by LegionMammal978 »

ProgramMax wrote: post #471
LegionMammal978 wrote: post #448

Earlier quoted context omitted.

> However, neither of these are capable of HDR. How so? As far as I can tell, the ICCv2 spec is very agnostic as to the gamut and dynamic range of the output medium. It doesn't say anything to the extent of "thou shalt not produce any colors outside the sRGB gamut, nor make the white point too bright". Unless HDR support is supposed to be something other than just the primaries, white point, and transfer function. Al…

IIRC (been a while), the reason was ICCv2/v4 still requires a gamma function. And PQ is not a gamma function. Maybe they can cover HLG, but if we want to represent any given HDR content, we needed something more than ICCv2/v4.

That doesn't sound quite right to me. ICCv2's 'curveType' gives the option of a full lookup table instead of a simple gamma function. Maybe it has to do with ICCv2 saying that the reference viewing condition has an illumination level of 500 lx for the perceptual intent? (But how does that apply to non-reflective media?)

I don't doubt that there's lots of problems in the chain from RGB samples to display output, but I'm finding this whole thing horribly confusing. Wikipedia tries to distinguish 'HDR' transfer functions like PQ [0] from 'SDR' transfer functions in terms of their absolute luminance, but the ICC specs are just filled with relative values all the way down.

(Not to mention how much these things get fiddled with in practice. Once, I had the idea of writing a JPEG decoder, so I looked into how exactly to convert between sRGB and Rec. 601 YCbCr coordinates. I thought, "I know, I'll just use the standard-defined XYZ conversions to bridge between them!" But psych, the ICC sRGB profile has its own black point scaling that the standards don't tell you about. I'm still not sure what the correct answer is for "these sRGB coordinates represent the exact same color as these Rec. 601 YCbCr coordinates".)

[0] https://en.wikipedia.org/wiki/Perceptual_quantizer

Re: A new PNG spec

#479

Post by dave8088 »

ProgramMax wrote: post #427

Author here. Hello everyone! Feel free to ask me anything. I'll go ahead and dispel some doubts I already see here: - It isn't really a "new format". It's an update to the existing format. - It is very backwards compatible. -- Old programs will load new PNGs to the best of their capability. A user will still know "that is a picture of a red apple". There also seems to be some confusion about how PNGs work internally.…

You’re awesome. Thanks for making things better.

Re: A new PNG spec

#480

Post by dotancohen »

pchangr wrote: post #168
dotancohen wrote: post #153

Earlier quoted context omitted.

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?

I can tell you, I have personally worked with a global corporation and we estimated that for one of their websites, supporting the 3% that we exclude by using “modern standards” would be more costly than the amount of revenue they get from them. So in that case, it was a rational decision. And up to the 10% cut, management just didn’t want to do the extra investment. So if something falls below that 10% threshold, th…

In my experience, accessibility features are needed by about 1.5% of users (E-commerce and some internal business tools). So by your logic, the rational choice is to exclude accessibility?

Or Linux users? Or even Firefox users in our market?

Post reply on HN