That had several impacts which scarred a lot of people I've worked with:
1. The commercial implementations were not interoperable and people get VERY nervous when they periodically get images which won't open correctly in one tool or, worse, have defects which one tool hides.
2. Many open source tools either didn't support the format at all or used Jasper, which just didn't get enough support to be fast or compliant.
3. Performance was quite slow for a while and people who weren't starting with Photoshop or native Mac apps (ImageKit uses the Kakadu codec, which has decent performance) were probably hitting Jasper or the Java implementation, both of which were orders of magnitude slower. People will forgive a certain performance hit for better compression but, especially as network bandwidth and storage capacity went up so much, the savings just weren't worth it if you could transfer and decode a JPEG in less time than it took just to decode the JP2.
4. All of that combined to mean browsers never really implemented it, other than Safari which picked it up via the standard image framework. The complexity meant that getting acceptable performance and security would be expensive and the demand just wasn't there.
5. The complexity of the format and low encoding performance meant that many JP2s were not encoded with optimized settings, which reduced the benefits to supporting it.
This makes me a bit sad because technically it was the only format for a long time which supported a wide range of colorspaces, bit depths, etc. and the way you can progressively decode a stream would have been a really neat option for responsive images in HTML — imagine if all your srcset had to do was say “Range-request bytes 1-x for 512x512, 1-y for 1024x1024, …” and the server + CDN could host & cache a single file for every client.
There are certain scenarios where the progressive / tiled decoding can make up for the friction (medical imaging and archival storage in libraries/archives) but they're not widespread enough to establish an entire image format. The open source situation has never been better with OpenJPEG but there just doesn't seem to be a high likelihood of significant increases in demand at this point.
Add in the fact that JPEG2000 showed at best a marginal improvement over JPEG and it's not hard to just stick with the proven technology. Having no good reference implementation is just a nail in the coffin.
If you look at it technically, it'll win on just about every point. Unfortunately for the standard, most of the people involved assumed that was enough to make adoption inevitable. I think it could have gone down a different path if, say, someone had released a high-quality open source version or worked with e.g. Netscape/Mozilla to integrate it into web browsers but that would have basically meant scaling back the older dream of making a profitable business around a single component like an image codec.
Marginal support from tool/browser didn't help boost its popularity, and patent situation as pointed in parent comment just shut the coffin on this otherwise ok format.
At the time vanilla jpeg had compression artifact and had worst compression rate, but was good enough at the time, even now because of its ubiquity the "successors" are still having a hard time dethroning jpeg.
Visually, where JPEG produces ringing artifacts, JPEG2000 produces blurriness. JPEG artifacts look "sparkly" and are often a reasonable replacement for the original texture, JPEG2000 artifacts look offensively dull (my opinion). I think, in theoretical speak, it's called "JPEG better preserves high frequency energy". You should be able to find side by side comparisons using your favorite image search engine.
This is the result of actual experiments with human subjects judging image quality.
I haven't really heard claims that JPEG2000 is better, actually. I remember people saying that it was "supposed" to be better, but not by people who dug into it and made comparisons with human eyeballs.
There were some images that would appear visibly better with JPEG2000, like photographs with those beautiful fields of defocused color. JPEG2000 captured those fields of color with all the smoothness they originally had.
Subjectively I think JPEG2000 is better across the different images, at least at this "medium" size preset.
Here another article [1] I found recently that discussed why Movie theaters use JPEG2000 over popular video format.
[1] https://www.design-reuse.com/articles/4595/digital-cinema-re...
* The industry doesn't want you to see compression artifacts, ever. Digital Cinema has no inter-frame compression, it's encoded as a series of individual jpeg2k images at a pretty reasonable quality.
* If one frame has a glitch, the glitch doesn't propagate over a bunch of frames the way x264 style compression does.
* jpeg2k at too-low a quality doesn't have jpeg/mpeg style square artifacts—instead certain parts of the picture will look slightly blurrier.
* jpeg2k has an interesting property where a 4k image can be encoded (with the proper parameters) such that when decoding you can stop at some point midway through a single frames data and have the equivalent encoded 2k image. Which means you can encode for 4k and ship it to theaters that only have 2k projectors (and that 2k hardware isn't required to render to a 4k framebuffer and then downsample).
* Since it's more modern than jpeg was (and dcinema was standardized before something like webp came along), it has a lower bytes/quality ratio than jpeg. IE, to achieve equivalent quality image from jpeg you'd need a lot more data.
* Support for deeper color depths and a much wider gamut. This is of course limited by what a projector can recreate, but they didn't want to limit to rec 709 or something.
They didn't care about patent encumbrance because they didn't need push this out the consumers—the jpeg2k patent stuff only affects the decoders and encoders, both of which are owned by people who can afford to pay.
JPEG2000 is also sometimes used to encode images embedded in PDFs.
Interesting. I thought PDF normally convert the format into .jbig2 for embedding into the PDF itself.
IMO, the flexibility provided by the container is not worth the development/support effort. It's better to do one or two things really well rather than have hundreds of edge cases.