You are correct. I designed the article to be very approachable and understandable for the normal person. As such, I took some liberties like only showing HDR primaries and ignoring transfer function. I linked to Chris Lilley's post to give experts a more correct answer.
But wide color gamut was already possibly in PNG via ICC profiles (HDR was not). And those primaries I showed could have been used in a wide color image.
So the image is a bit misleading or red-flag-y to experts who know. But to the average person, I think it is as truthful as I can be without getting too deep in the weeds.
It is very backwards compatible. I'm not sure why you thought that.
We jumped through quite a lot of hoops to make sure old software will be able to display new images. They simply won't display them optimally. But for the most part, that would be because the old software wouldn't display images optimally anyway. So the limit was the software, not the format.
What I mean by this is old software that treats everything as sRGB wouldn't correctly show a Display P3 image anyway. But we made sure it will still display the image as correctly as it could.
The sample HDR images don't show correctly in image viewers even though the colors used fit into the sRGB gamut (or at least have good approximations in there). That's not really backwards compatibility.
We went to pretty extreme lengths to make sure old software worked with the new changes. Effectively, the limit will be the software, not the image.
For example, you can imagine some old software that is unaware of color spaces and treats everything as sRGB. There is nothing we can do to make that software show a Display P3 correctly. However, we can still show the image well enough that a user understands "that is a red apple".
Having images show up in washed up colors without any indication is not what I'd consider "working". This mistake has been made many times, please let's not make it again.
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: Everybody immediately jumps to file size as to what image compression is better or worse. That isn't the best take, but it is what it is. So there is pressure to adopt newer technologies.
We often do have a way to maintain some degree of backwards compatibility even when we do this. For example, we can store a downsampled image for old viewers. Then extra, new chunks will know "Mix that with this full scale data, using a different compression".
As you can imagine, this mixing complicates things. It might not be the best option. Sooooo we're researching it :)
> The PNG decoder has to determine whether a syntax error is fatal (unrecoverable) or not, depending on its requirements and the situation. For example, most decoders can ignore an invalid IEND
It doesn't explicitly mention what decoders should do on encountering data after IEND, but The general philosophy for decoders seems to be that errors should be handled gracefully where possible, even if the file is technically malformed (which is maybe something that could be clarified or expanded upon?)
Back in the olden days, when people were using protocols like Kermit and XModem to download their questionable images from BBS's, You would often get a file whose size was rounded up to the nearest block size. In that situation, failing for extra data at the end would have been a fatal move for someone implementing an image decoder, and I think PNG might be just barely old enough that the designers remembered that.
From a usability perspective, it's preferable to recover from and workaround any data stream errors rather than crash with an exception error.
Why? Because users have stuff to do. They don't know about and don't care for errors.
The most prominent example are web browsers. Browsers are supposed to crash when fed invalid HTML, and this was even mandated when XHTML was trying to replace HTML. Users fucking hated it, and XHTML crashed and burned and HTML with its error-safe handling has stayed to this day.
Thanks for explaining, from a user perspective the best thing to do is definitely graceful recovery, but bugs like this highlight that there's value to the ecosystem in failing loudly whenever anything is out of spec. The appropriate balance of those behaviors is obviously a function of the nature of the ecosystem, and could be different for different tools.
I'd suggest that for PNG in particular, one reasonable behavior would be to show a little red "File corrupted!" warning or popup for these sort of out-of-spec-but-probably-recoverable issues, which would probably have been noticed and filed as a bug for the developers of these tools, even if only a small fraction of viewers had that behavior. Something like a thumbnail viewer should maybe just opt to early-abort whenever anything sketchy is going on, especially since out-of-spec behaviors can lead to security issues.
I don't speak for Google/Chrome but I really need to clarify something that keeps being misstated:
The test of JPEG XL support has been removed.
It was always behind a flag and never actually supported. That is not to say that Chrome will not ever support JPEG XL. The two concepts are fundamentally unrelated. So we should stop conflating them.
In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support. I would argue this is likely the case. And the thing they should be waiting on IMHO is wide spread support.
Adding image formats to the web should be the last step because it is so difficult to remove them. I bet other browser devs in the image space wish they could remove ico support. Oh well.
"So why add it in a test just to later remove it?" I hear someone ask. Because you want to make sure that path is clear and you're in position long before it is needed. Once you know the path is clear, you don't want to keep dead code around. It is easy enough to dig it out of old commits when the time comes.
Heck, it could even be as simple as someone wanted to add a big item to their promo packet. Who knows.
But at the end of the day, Chrome did not remove JPEG XL support. And I haven't seen anything saying Chrome wouldn't later add it. If we all want JPEG XL (I do), we should continue to help its adoption grow. Using it via WASM is a strong indicator. Get it to the point where "of course Chrome will add support -- it is everywhere".
I think it's fine to assume the more likely interpretation that this company simply isn't interested in the format anymore, rather than whatever larger stretch you're describing here. "You don't want to keep dead code around." That's rich :) maybe if this was some one person hobby project or something.
I strongly disagree with "more likely interpretation". For several reasons:
- FireFox & Safari also don't fully support it. For your claim to be true, Google would need to be in control of them, too.
- I still get nag emails that I'm long overdue to remove dead test code from my Chromium tests. I'm being a bad person to other Chromium devs by being lazy and not getting around to it.
I think it is far more likely that they ran a test and know they're ready to support JPEG XL when the time comes. And that time (IMHO) is when there is already wide spread support outside of browsers. Browsers should be the last ones to add it. Not the first.
Chrome supports plenty of things that are unsupported by Firefox and Safari. E.g. you get set the audio sink id on individual media elements in Chrome. You can’t do that in Safari and Firefox.
Cleaning up code is something I get great pleasure. It not only makes navigating the code base easier for people new to the code base won't look at something that isn't ever actually run in production. It also prevents people from depending on something that we don't really want to be used anymore.
> In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support.
Waiting for libjxl 1.0 is reasonable. Though I can't help but to think it would be less work to just keep the experimental feature in there until it is stable.
Is there a good way to do that, though? What I think will needing to do properly:
1. You can implement picture/audio/video/document file formats as extensions, without needing to intercept requests/responses (so that save, view-source, etc will still access the original file). (I think some versions of Mozilla have this capability (although some details of the design are not as good as they could have been), but as far as I know, WebExtensions does not.)
2. Extensions can be native codes, WebAssembly codes, or JavaScript codes. (Native extensions will be excluded from the extensions catalog, and the end user or system administrator must install them manually.)
3. Add a "Interpreter" response header, to indicate what to do if the browser does not understand the file format. For example, this might link to an implementation of that file format in WebAssembly.
4. Such WebAssembly programs can also be used outside of a web browser, in local standalone programs. For example, an external program might run the WebAssembly code to convert data from stdin to stdout.
> In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support. I would argue this is likely the case.
If Chrome deems that something is useful (to them, for some definition of useful), they just release it (and if this something was on a standards track, too bad, it's out now).
I don't know about that. Some of the first responses I saw were along the lines of "It was a test. Tests have end dates. When that end date comes, the code gets removed unless it is being committed to full support."
Doesn't it now read like the bulk of the message is other's support? And the internal debate of "Should we be the ones to push this first, despite other's support and objections and browsers ideally adding support last?"
EDIT: To help clarify what I mean, let me insert my thoughts here inside a quote:
"When we evaluate new media formats [new as in not yet widely supported], the first question we have to ask is whether the format works best for the web [which is why it isn't yet widely supported -- IE it should actually come to browser first]."
But wide color gamut was already possibly in PNG via ICC profiles (HDR was not). And those primaries I showed could have been used in a wide color image.
So the image is a bit misleading or red-flag-y to experts who know. But to the average person, I think it is as truthful as I can be without getting too deep in the weeds.