Hacker News Reader

Comment by wereHamster | Hacker News Reader

At last for the web (which is what WebP targets mostly, right?) you don't need broad support. We have the new <picture> element where the UA selects the most appropriate image from a list of options. So Chrome will prefer webp, other browsers will pick jpeg, png or whatever else they support at the moment.

View on HN

The problem is, content delivered over the web "leaks out" in standard usage and interfaces with the overworld, unless prevented by DRM. People save files, sometimes using contrived workflows, and content that was transferred to a browser for display (such as WebP) will eventually be downloaded, shared, and reposted somewhere else. Facebook once famously migrated serving most images as WebP and had to back out because people were downloading images, only to end up with .webp files that are unsupported in other programs [1].

In the past, I articulated, on the topic of 'Ask HN: Software for writing a diary that will be around in 20 years from now' [2]:

I'd be wary of the archival potential of formats that are solely used on the Web with little usage on tangible physical hardware by major commercial publishers -- the Web of today moves very fast and technologies come and go. Google is pushing WebP, WebM, but work is already under way on a big consensus format called AV1. When AV1 comes out, new VP8/VP9 content will likely no longer be produced. Browsers periodically prune older features, 20 years is almost as long as the web has been around, and given enough time support for the format may only be available in software that make format coverage an explicit goal (ffmpeg, libav, VLC). Opus is being made a mandatory audio codec for WebRTC, teleconferencing is usually ephemeral -- will there be lots of .opus files sitting on disks in the future? Too early to tell, not worth gambling on.

The context of this was choosing formats for the express purpose of long-term archival, but our incidental usage of formats today will shape the sort of files that will be naturally around in our future.

[1] https://news.ycombinator.com/item?id=5589206 [2] https://news.ycombinator.com/item?id=12979854#12980359

This is why many tend to consider only uncompressed/lossless formats viable for archival usage. Doubling down on those doesn't really address what you were talking about — something that you make today being viewable in browsers of the future — but with the original content itself preserved in a way that maintains its full quality, the 'deliverable' formats can be updated periodically from the original masters in a way that the content will be viewable with software 20 years from now, and without degrading quality each time.

We had similar problems in the past with physical media, and still do to some extent, but in the purely digital domain this problem is somewhat more tractable (content negotiation helps facilitate these transitions for those willing to work that into build pipelines and maintain those over time, for example.)

If possible, I’d much prefer having a single format that is widely supported, hardware accelerated, and with a state-of-the-art codec. Making content authors create multiple different files in different formats—some with deficient feature support—sounds like a pain in the butt for everyone.

If we can get everyone to agree on a format that handles layers, exposure bracketing, transparency, animation, high bit depth, different color models, both lossy and lossless compression, every common type of metadata, etc., that would be great.

There are services like Imgix that will do the conversion automatically on the fly, you don't have to convert images manually.

If your format handles everything it isn't a format, it just is everything. (The one you want is TIFF though.)

The point is that you want support for those features (certainly the core codecs, etc.) in the spec, so if you send someone a file you can be sure they can read it.

TIFF is not useful if you want to use a state-of-the-art lossy codec and get hardware-accelerated decoding on an arbitrary mobile device, or if you want to display an animated image with transparency on a web page.

But can you actually get people to implement it if you make it that complicated? Images are pretty hard, hardware support is /actually/ really hard.

That's why it's best to accept whatever format is already out there and author to it - the only thing that matters is that it actually works when it's out there.

Actually I'm surprised there's still no good way to do animations with transparency, but maybe nobody wants to use it?

Yes! This is one of the motivations behind HEIF: it's codec agnostic and extensible. You can use HEIF with JPEG and AVC for example, or some new codec down the line.

It's also extensible, in that you can define new item types and box structures to describe any new imaging construct you like. For example, you could host images with alpha, depth maps, stereo left/right channels, a HDR image with each of the raw brackets and the final fused image, etc.

The format relies upon the ISO Base Media File Format file-type branding to distinguish the infinite possibilities into a clear set of capabilities required for playback; in the same way MPEG4 does for video codec profile and levels.

Reply on news.ycombinator.com