3 ms·

It's interesting how JPEG2000 use has not really taken off outside of a few niche areas. Web browser vendors have been reluctant to implement it because of incr

It's interesting how JPEG2000 use has not really taken off outside of a few niche areas. Web browser vendors have been reluctant to implement it because of increases attack surface, and of course web sites will not use it without browser support. Patents may also be an issue. JPEG works mostly on 8x8 blocks of pixels, and in high resolution pictures each block is almost a single color. JPEG does a poor job taking advantage of similarity between the blocks. JPEG2000 does at least see some use in archival formats.

anon1385 11y ago
>Web browser vendors have been reluctant to implement it because of increases attack surface Which isn't a very convincing argument when they are quite happy to implement dozens of other things that vastly increase the attack surface of browsers but have far lower practical impact on the average web page. Imagine how much bandwidth has been wasted over the last 10 years because the web didn't have a lossy image format that supported transparency.
captainmuon 11y ago
> Web browser vendors have been reluctant to implement it because of increases attack surface, and of course web sites will not use it without browser support. I believe codecs should actually be part of the OS. There should be one good, well-tested implementation per OS that browsers and other apps just link to. It might actually be possible to sandbox the codec components for increased security. Ideally, a web browser would just be a HTML+stuff parser, a layout engine, and a bit of gui, and shell out to the OS for everything else. Unfortunately, it seems the monolithic kitchen sink model has won.
- vetinari 11y ago
  The monolithic kitchen sink has won, because the OS bundled libraries have different APIs (not only among different OSes, but also among different versions - and OS vendors are interested in pushing the latest), so app vendors just said to themselves "screw it" and bundled library (like jpeglib or libpng) that has same API on all systems and versioning is under their control. That's the short version ;).

anon1385 11y ago

>Web browser vendors have been reluctant to implement it because of increases attack surface Which isn't a very convincing argument when they are quite happy to implement dozens of other things that vastly increase the attack surface of browsers but have far lower practical impact on the average web page. Imagine how much bandwidth has been wasted over the last 10 years because the web didn't have a lossy image format that supported transparency.

captainmuon 11y ago

> Web browser vendors have been reluctant to implement it because of increases attack surface, and of course web sites will not use it without browser support. I believe codecs should actually be part of the OS. There should be one good, well-tested implementation per OS that browsers and other apps just link to. It might actually be possible to sandbox the codec components for increased security. Ideally, a web browser would just be a HTML+stuff parser, a layout engine, and a bit of gui, and shell out to the OS for everything else. Unfortunately, it seems the monolithic kitchen sink model has won.

vetinari 11y ago
The monolithic kitchen sink has won, because the OS bundled libraries have different APIs (not only among different OSes, but also among different versions - and OS vendors are interested in pushing the latest), so app vendors just said to themselves "screw it" and bundled library (like jpeglib or libpng) that has same API on all systems and versioning is under their control. That's the short version ;).