ProgramMax
Joined 15 years ago
Joined 15 years ago
The big one is adoption. I love JPEG XL and hope it becomes more widely adopted. It is very scary to add a format to a browser because you can never remove it. Photoshop and MSPaint no longer support ICO files, but browsers do. So it makes sense for browsers to add support last, after it is clearly universal. I think JPEG XL is well on their way using this approach. But they aren't there yet and PNG is.
There is also longevity and staying power. I can grab an ancient version of Photoshop off eBay and it'll support PNG. This also benefits archivists.
As a quick side note on that: I want people to think about their storage and bandwidth. Have they ever hit storage/bandwidth limits? If so, were PNGs the cause? Was their site slow to load because of PNGs? I think we battle on file size as an old habit from the '90s image compression wars. Back then, we wanted pixels on the screen quickly. The slow image loads were noticeable on dial-up. So file size was actually important then. But today?? We're being penny-wise and pound-foolish.
You can see this with PNG optimizers like OptiPNG and pngcrush.
So step 1 is to improve libpng. This requires no spec change.
Step 2 is to enable parallel encoding and decoding. We expect this to increase the file size, but aren't sure how much. It might be surprisingly small (a few hundred bytes?). It will be optional.
Step 3 is the major changes like zstd. This would prevent a new PNG from being viewable in old software, so there is a considerably higher bar for adoption. If we find step 1 got us within 1% of zstd, it might not be worth such a major change.
I don't yet know what results we'll find or if all the work will be done in time. So please don't take this as promises or something to expect. I'm just being open and honest about our intentions and goals.
However, gain maps are extra data. So there is a trade off.
The reason gain maps didn't make it into Third Edition is it isn't yet a formal standard. We have a bunch of the work ready to go once their standard launches.
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 actual PQ.
Here is that original proposal: https://w3c.github.io/png-hdr-pq/
Possibly more context (I just found this) from Apple. I'm not sure of date: https://www.color.org/hdr/02-Luke_Wallis.pdf Slide 29: "HDR parametric transfer functions not in ICC spec Parametric 3D tone mapping functions not in ICC spec - Neither can be approximated by 1-D or 3-D LUTs"
I'm not sure why they cannot be approximated by LUT. Maybe because of the inversion problem?
I designed the article to be accessible and understandable for the average person. So I took some liberties like showing only HDR primaries and not deep diving into HDR transfer functions. People understand the primaries intuitively.
But you are right that a wide color image could also use those same primaries without being HDR.
My goal was to be as truthful as possible while still being digestible at a glance.
In the article, I linked to Chris Lilley's post which explains it more thoroughly for the technical people.
Sooooo file some bugs :D
Also, be kind to them. This literally launched yesterday.
W3C requires that we do not break old, conformant specs. Meaning if the next PNG spec would invalidate prior specs, they won't approve it. By extension, an old, conformant program will not suddenly become non-conformant.
I could see a group of people formalizing IFFv2, and adapting PNG to it. But that would effectively be PNGIFF, not PNG. It would be a new spec. Because we cannot break the old one.
That might be fine. But it comes with a new set of problems, like adoption.
Soooo I like the idea but it would probably be a separate thing. FWIW, it would actually be nice to make a formal IFF spec. If there was no governing body that owns it, we can find an org and gather interest.
I doubt W3C would be the right org for it. ISO subgroup??
Chris Lilley--one of the original PNG co-authors--has a post with an example HDR image: https://svgees.us/blog/cICP.html It is about half way down, with the birthday cake. Generally, us tech nerds have phones that are capable of displaying it well. So perhaps view the page on your phone.
What you should look for is the cake, the pink tips in her hair, and the background being more vivid. For me, the pink in the cake was the big give-away.
There is also the Web Platform Tests (WPT) which we use to validate browser support: https://wpt.fyi/results/png/cicp-chunk.html?label=master&lab...
Although, that image is just a boring teal. See it live in your browser here: https://wpt.live/png/cicp-chunk.html
For an example of APNG, you can use Wikipedia's images: https://en.wikipedia.org/wiki/APNG
But you have a bigger point: I should have live demonstrations of those things to help people understand.
In the first video, the person loads the image and manually chooses a gamma transfer function with 2.2. If that was then saved, it would produce the washed-out fireball you mentioned.
In the second video, the person loads the image and manually chooses rec.709, which is also gamma tf and also produces washed-out fireball. In fact, the EXR image he loads literally has a bright fireball and you see it get washed out.
If you want to make claims about EXR being better than PNG, you need to say why storing the values as floating point is better than integer. But the blown-out fireball example is just incorrect. As evidence, I'll point to HDR. ANYTHING you see in an HDR movie is now 100% losslessly reproducible in a PNG.
- 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. Short and sweet: - There are chunks of data. -- Chunks have a name, which says what data it contains. A program can skip a chunk it doesn't recognize. - There is only one image stream.
Maybe iccMAX supports HDR. I'm not sure. In either case, that isn't what PNG supported.
So something new was required for HDR.