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

601–610 of 622 posts

Re: A new PNG spec

#601

Post by ProgramMax »

LegionMammal978 wrote: post #570
ProgramMax wrote: post #488

Earlier quoted context omitted.

Agreed that it gets confusing. That's a piece of why I'm unable to give you a solid answer. This isn't my area of expertise. Here is what I can tell you confidently: The original plan was to provide an ICC profile that approximates PQ as best as we could. But it wasn't enough. So the proposal was to force the profile name to be a special string. When a PNG decoder saw that name, it would ignore the ICC profile and do…

Thanks for that proposal link. The email thread starting at [0] seems to explain some of the challenges. My understanding: - In ICC-land, all luminances are relative to the display's (or reflective medium's) black and white points. So for an HDR-capable display, all content, HDR or SDR, would be naturally displayed at the full 10k nits or whatever the actual number is. This is obviously not how things work in practic…

You....are wonderful. Thank you.

Re: A new PNG spec

#602

Post by account42 »

Retr0id wrote: post #560
account42 wrote: post #546

Earlier quoted context omitted.

The problem is when "HDR" images that would perfectly fit into the sRGB color space are not rendered correctly on non-HDR systems. This PNGv2 fails that which means it isn't really any more useful and one of the existing (and much better) HDR-supporting formats like JPEG-XL or the video codec based ones pushed by the big guys.

If your image fits in sRGB colour space then why not just use sRGB?

Someone who is aware of this issue can do that. Someone who just uses the standard export might not notice that their files are not backwards compatible. It might also be that most of the image fits into sRGB but a few highlights do not - having the whole image washed out because of those is also not good.

Re: A new PNG spec

#603

Post by Retr0id »

account42 wrote: post #602
Retr0id wrote: post #560

Earlier quoted context omitted.

If your image fits in sRGB colour space then why not just use sRGB?

Someone who is aware of this issue can do that. Someone who just uses the standard export might not notice that their files are not backwards compatible. It might also be that most of the image fits into sRGB but a few highlights do not - having the whole image washed out because of those is also not good.

Software tends to default to sRGB export, because it's the safe default.

Re: A new PNG spec

#604

Post by pmarreck »

BobaFloutist wrote: post #388
illiac786 wrote: post #328

Earlier quoted context omitted.

a sw that does not know what jpeg xl is, will not be able to open jxl files. How would it? Not sure what the previous poster meant with “backward compatible” here. jxl is a different format. It can include every information a jpeg includes, which then maybe qualifies as “backward compatible” but it still is a different format.

Ah, got it. I assumed it was a losselessly compressed JPEG with metadata telling modern software not to compress differently but that older software would open as a normal JPEG, but I guess they meant something else with "backward compatible".

I guess I meant losslessly round-trippable. In other words, you can go from jpeg -> jxl -> jpeg without any loss in quality, potentially (although with jxl -> jpeg -> jxl, you will lose space while it is a jpeg, and you'd probably have to pick a high compression quality in order to not lose information... you may also lose information such as metadata that jxl accommodates but jpeg does not, like transparency)

So backwards-compatible in the sense that the jpeg-xl algorithm spec can read jpg and store the same pixel data more efficiently as jxl if you like. You gain space and lose nothing (except perhaps encode/decode speed).

Re: A new PNG spec

#605

Post by meindnoch »

pornel wrote: post #596
meindnoch wrote: post #386

Earlier quoted context omitted.

False. 8-bit YCoCg (even when using the reversible YCoCg-R [1] scheme) cannot represent 8-bit RGB losslessly. The chroma channels would need 9 bits of precision to losslessly recover the original 8-bit RGB values. [1] https://www.microsoft.com/en-us/research/wp-content/uploads/...

AVIF supports 10 and 12 bit encoding, which losslessly fits the 9-bit rotation of 8-bit data. It's also possible to directly encode RGB (channels ordered as GBR) when you set identity matrix coefficients, it's just less efficient. I've implemented this in my AVIF encoder, so I know what I'm saying.

Show me any of the popular image conversion tools (avifenc, imagemagick, photoshop, ffmpeg, whatever...) that does the identity matrix hack when asking for lossless AVIF. None of them do it. Many people have been burned by "lossless" AVIF, where they converted their images in the mistaken belief that the result will be bit-identical to the original, only to find out that this wasn't the case, after they've deleted the original files.

Re: A new PNG spec

#606

Post by pchangr »

dotancohen wrote: post #480
pchangr wrote: post #168

Earlier quoted context omitted.

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?

By that logic, yes. Thankfully, EU regulation forces them to implement accessibility even if it makes no sense by that specific logic.

As for Linux users… I do recall they were even less than the 3%. Firefox users were more tho.

In any case, I’m almost sure most Linux users were fine. We just didn’t wanted to support old browsers.

Re: A new PNG spec

#607

Post by pchangr »

account42 wrote: post #542
pchangr wrote: post #168

Earlier quoted context omitted.

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…

Thanks for demonstrating why laws like ADA are needed to force companies to not be bad citizens. We desperately need similar laws to force compatibility with older hardware - one could even champion it under environmental protection.

I absolutely agree. I’m very glad we have accessibility requirements in the EU.

Re: A new PNG spec

#608

Post by pchangr »

eviks wrote: post #360
pchangr wrote: post #168

Earlier quoted context omitted.

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…

Something is off in this calculation, how did they get to such a high cost for such a simple thing as an alternative image format when the web supports multiple???

No, this was not about the alternative image format. This was about the browsers and screen resolutions that we choose to fully support. We took the data directly from the website visitors analytics. Basically .. resolutions under 1024px and anything older than edge 11 was left out of the scope.

Re: A new PNG spec

#609

Post by fc417fc802 »

meindnoch wrote: post #605
pornel wrote: post #596

Earlier quoted context omitted.

AVIF supports 10 and 12 bit encoding, which losslessly fits the 9-bit rotation of 8-bit data. It's also possible to directly encode RGB (channels ordered as GBR) when you set identity matrix coefficients, it's just less efficient. I've implemented this in my AVIF encoder, so I know what I'm saying.

Show me any of the popular image conversion tools (avifenc, imagemagick, photoshop, ffmpeg, whatever...) that does the identity matrix hack when asking for lossless AVIF. None of them do it. Many people have been burned by "lossless" AVIF, where they converted their images in the mistaken belief that the result will be bit-identical to the original, only to find out that this wasn't the case, after they've deleted th…

That's shifting the goalposts from what the standard supports to the current state of the ecosystem. It's certainly an interesting point though. If common implementations all have bugs regarding lossless encoding that's a pretty bad situation.

Re: A new PNG spec

#610

Post by extraduder_ire »

qingcharles wrote: post #494
extraduder_ire wrote: post #371

Earlier quoted context omitted.

Do you mean services that reencode gif files to webm/mp4? apng just works everywhere that png works, and will remain animated as long as it's not re-encoded. You can even have one frame that gets shown if and only if animation is not supported.

Yes, most places only show the first frame. They ignore the animation, sadly. Even while accepting GIFs.

That's not the first frame, it's the fallback image that png decoders which are unaware of apng decode.

It is never shown by compliant apng decoders. You can make it the first frame of the animation, or any other image you want. e.g. some text saying "APNG unsupported"

Post reply on HN