I do not really know based on which libraries mozilla displays graphics, but one should be prepared when the JPEG2000 format is released and mozilla should support this standard as early as possible

While major changes to JPEG 2000 are not expected at this point, like most standards it can be expected to undergo a few "last minute" tweaks over the next year or so. Mozilla probably has until at least 2002 to get this working, mark LATER for now I should think. (When ISO eventually get their finger out, I expect Mozilla will use a third-party library something like they do with IJG's libjpeg.so)

The IJG jpeg libraries are used in mozilla. But with the new imglib design adding a new jpeg2000 component will be easy. It will be a drop in. -P -P

that bug really is a bit ambiguous, now it I´ve got a different folder and it won´t download the headers many times, it downloads them once, but does not display anything.... I´ll atach that file

ups, wrong bug

Jpeg2000 is now an ISO-standard. (01.01.2000) Mozilla should support Jpeg2000 as one of the first browsers. (https://www.jpeg.org/JPEG2000.htm)

All pnunn bugs reassigned to Pav, who is taking over the imglib.

proposing mozilla1.0

Is there an open source jpeg2000 library that we can build and ship with mozilla? If so, this might get fixed for 1.0. Otherwise, I'll wait on someone to write a jpeg2000 decoder :-)

pavlov: on the jpeg web site are links to several software packages, one for Java, one for C and one for C++. The IMHO most interessting implementation is the C software called Jasper. Sadly the link is broken, and the website seems to have no search function... On one website Jasper was mentioned as candidate for the example implementation of JPEG 2000. Some URLs: Jpeg2000-Homepage: https://www.jpeg.org/JPEG2000.htm#testlinks the broken Jasper link: https://www.ece.ubc.ca/~mdadams/jasper/ Author of Jasper (got a timeout, but that might be temporary) https://spmg.ece.ubc.ca/people/mdadams/mdadams.html Jasper Announcement: https://www.wavelet.org/wavelet/digest_10/digest_10.01.html#15 my google search for Jasper (seems to be a popular package) https://www.google.com/search?as_qt=w&as_q=jasper+jpeg+2000&as_eqt=w&as_eq=&as_dt=i&as_sitesearch=&lr=&num=100&btnG=Google-Suche Since the announcement mentioned above is from february (arround 2 monthes ago) I think it should be possible to find a valid adress. I hope I could help...

the site is back again, I have contacted the administrator and their site has been down due to security issues... https://www.ece.ubc.ca/~mdadams/jasper

any information about the progress of jpeg2000 support?

no, not really. Only what pavlov wrote on April 25th, and that this bug still has the mozilla1.0 keyword but is only new and not assigned.

markus: until a given standard is officially published, it is prohibited to do ANY commercial work with Jasper, even trying it in internal projects. So nothing can be done for Mozilla until this standard is released :-/ From the Jasper-Homepage: In particular, the JasPer software may not be used for any commercial purpose whatsoever (even for internal use by an organization) before the JPEG-2000 Part-5 standard (i.e., ISO/IEC 15444-5) is officially published by the ISO. pavlov said in IRC, that working in JPEG2000 supported is VERY low on his priority list...

Here's a summary of the jpeg2000 situation that I wrote up, but never made it into bugzilla: You might want to ask Tom Lane, head of the Independent JPEG Group, for his opinion. It seems that adding jpeg2000 support would get us involved in a legal mess. If you look at appendix L of the jpeg2000 draft, there are 22 companies who believe that implementing the spec may require use of their patents. From https://www.jpeg.org/CDs15444.htm : Particular attention is drawn to the use within the standard of selected technology or algorithms which are claimed to be protected by national and/or international patents. In the case of technology submitted for consideration by JPEG for incorporation in Part 1 of the standard, the JPEG committee believes that the individual organisations concerned will make available licences to use this intellectual property, on a royalty- and fee-free basis, under specified conditions which may apply only to conforming implementations of the standard. These conditions are available on application to the organisations concerned, which are listed in an Annex to the document. It is of course still possible that other organisations or individuals may claim intellectual property rights that affect implementation of the standard, and any implementors are urged to carry out their own searches and investigations in this area. The JPEG committee requests any organisations or individuals claiming (or being aware of claims) that any of the committee drafts available for download here infringes other intellectual property rights to provide information and/or evidence to substantiate their claim to the JPEG Convener in the first instance. Moving on to more practical considerations, there is one open (sort of) C implementation of the jpeg2000 standard that I'm aware of, Jasper: https://www.ece.ubc.ca/~mdadams/jasper/ The licensing terms are specified in this document: https://www.ece.ubc.ca/~mdadams/jasper/LICENSE-1.000 While I'm not a lawyer, the impression I get is that once ISO officially publishes part 5 of the jpeg200 standard we're free to use the library as we like.

www.lurawave.com has a free browser plugin that supports Netscape. Maybe it could simply be included.

Drats... I meant www.luratech.com

Drats... I meant www.luratech.com

https://gemal.dk/browserspy/images.html can be used at testing image/jp2 support.

/. article re: Jpeg 2000 --> https://slashdot.org/articles/02/04/07/1948233.shtml?tid=152

Some coments before seem to imply that the Jasper code is open. That code is not free software, beacuse it's being licensed only for software implementing the ISO JPEG-2000 standard. So it's sad, but it can't be considered for inclusion into Mozilla.

How about the libj2k at https://j2000.org/ ? BSD licensed.

Nicolás: a browser with jpeg2000 image support would be considered a ISO/IEC 15444-1 complaint product. That part of the jasper license is fine. I've looked at the jasper software a bit, and it doesn't appear to have been constructed with the idea of embedding it easily in another application.

Yes it would be legal. But Mozilla as a free software project can't use software that isn't free software too.

Ben: libj2k, at least in its current form, apparently needs the complete image to be able to decode it... I'm not sure about this though, as there is no documentation at all available for this library (neither in a seperate document, nor in the apparently main header file).

In addition, libj2k uses a global variable for the image that's currently decoded; so only one image at a time can be decoded.

Looking through libj2k, I agree with Christian's analysis. It appears to deal with the image in one massive chunk instead of the incremental processing and display needed for a browser image decoder.

minusing as we're not taking features in the 1.0.1 release. this seems like good trunk work.

Adding CC to myself, and expressing interest in progressing this.

Just a general FYI - the plugin found at www.luratech.com crashes Moz 1.0; Win2K

That plugin works fine here, in both 1.0 and later. (win2k too).

Strange. I first had problems loading the JPEG 2000 image at the following URL: https://www.fnordware.com/jp2samples/jp2samples.html (click on the image labeled JP2 to actually see the JP2, the image embedded in the page is a PNG, actually). The problem was that apparently the plugin only registers image/jp2 and not image/x-jpeg2000. So, I saved the .jp2 file and then opened it from Mozilla to view it, and that's when I got the crash message (this plugin has caused ... blah, blah, blah). See if that happens to you.

Yes I see it now, but that would actually be another bug....

I was mainly posting that as an FYI/warning to others seeking to get JP2K support in Mozilla. Now that the (free) Photoshop plug-in is out, I imagine it won't be too long before folks are clamoring for this feature.

Adding CC to myself, and expressing interest in progressing this. (tnx to Adam for this perfect sentence! ;-))

Downloaded plugin (W2k) from Luratech & installed it (very convenient, detected that I have installed NS7 & Mozilla ;-)). But while trying to open a *.jp2 form my local filesystem, the plugin crashed. I got a requester by Mozilla, telling me the plugin caused a serious problem and that it is strongly recommended to restart the browser... :-( IMHO you should not be an expert-user for viewing JP2... I'd really prefer build-in support for jpeg 2000...

*** Bug 180073 has been marked as a duplicate of this bug. ***

I agree with Robert.. users shouldn't have to seek out plug-ins or other inconveniences because that would just result in another bug report that it is less pleasant for the user experience than it is with Internet Explorer which does have builtin support for JP2000. Vote to set target for no later than 1.4..

Matt: The target is "Whenever we hear about a suitable JPEG 2000 library" I highly doubt that somebody would create an own j2k decoder for mozilla.

maybe worth to evaluate ? -> https://www.j2000.org/ couldnt even find what license it runs under ...

last I heard, libj2k from that url does not have the required features.

Anyone check out https://www.jpeg.org/JPEG2000.html ?

Adam, er, that url was linked in comment 5 already. That said, it seems doubtful to me that a mozilla developer would write a jpeg2k implementation from scratch. Now, if there was a library that supports streaming the data in, this bug would be easily fixable.

Perhaps we should change the summary of this bug, considering that it's no longer an upcoming format; it's here.

> Perhaps we should change the summary of this bug, considering that it's no > longer an upcoming format; it's here. Ok.

I have written a patchset for mozilla 1.4 to use jasper, you can find it at https://www2.informatik.uni-wuerzburg.de/mitarbeiter/tischler/mozilla/jasper-mozilla.tar.bz2 It contains some new files, a very small patch for jasper and a build script. I have tested it on Suse Linux 8.0 and on Redhat Linux 8.0 and it seems to work. I also have a report that it compiles on FreeBSD, but have no way to write a test environment for windows because I don't have that installed. It is a very basic implementation that decodes the whole picture at once. (I don't think the current jasper API allows progressive decoding.) As far as linewise decoding is concerned: jpeg2000 is based on an hierchical decomposition of the image using dyadic wavelets, that means it is (in a way) not block or even line based. The way to go would probably be to use it's SNR progressive properties. Please note that this is just an implementation study, I don't know how far it is useable or even may be used at all.

ok. some comments. 1. I would have loved to see the changes in .diff form, because the relevant files (at least configure.in) have changed in the meantime, so if I diff my current tree against those files, it's pretty useless... 2. don't bother with win32.order haven't looked at the actual decoder yet... however, I don't like that the decoding is not progressive. I would not like a non-progressive jp2k patch in the mozilla tree. But, I am neither a module owner nor a peer, so that's just my opinion. Also, if you would have put the code that you put in nsImageModule.cpp in a new file in your decoders/jp2/ directory (similar to the mng one) and created an own .so for the jp2k decoder, you could make an XPI out of it. It wouldn't _fully_ work, because of the missing code changes in imgLoader.cpp, but it would work for most things.

Also, you might want to read the description of PR_Realloc, might make your code somewhat simpler :) https://www.mozilla.org/projects/nspr/reference/html/prmem2.html#21474

Patch Maker is reputed to be a good tool for generating those diffs. https://www.gerv.net/software/patch-maker/ Okay. I'll be quiet now.

I removed win32.order and packed up the changes as a diff (except the new files), it is still at the same URL.I also use realloc instead of alloc and free for buffer appending.As further interest seems to be nonexistent at the time being, I'll not put any more time into this.

I guess the CCs were removed by accident. Readding...

adt: nsbeta1-

new plug-in w/ source adding JPEG2000 capability for Mozilla (amongst others) on Linux: https://linuxj2k.free.fr/ it's based on previously mentioned Jasper and/or GDAL.

The JasPer library seems to be compatible with mozilla licensing. Is there really a good reason to choose _no_ jpeg2000 support over wait-for-your-image-to-load-completely support? Personally, I wouldn't mind it one bit if _all_ my images showed up as a transparent/white box that just 'popped' into place at the end. Would make my sluggish system feel that little bit more responsive...

"F. This software is for use only in hardware or software products that are compliant with ISO/IEC 15444-1 (i.e., JPEG-2000 Part 1). No license or right to this Software is granted for products that do not comply with ISO/IEC 15444-1. The JPEG-2000 Part 1 standard can be purchased from the ISO." I do doubt that this is compatible with the GPL. in any case, I seem to recall that pavlov is against supporting jpeg2k in mozilla. (I am also against a non-incremental image decoder in mozilla... though it wouldn't be my decision)

Forgive my naivety, but isn't the requirement of the cited paragraph a self-fulfilling one, given that the library in question is exactly what (I suppose) would make Mozilla comply with the JPEG-2000 standard? In other words, when you use JasPer in an application, don't you make it JPEG-2000 compliant, thus fulfilling the requirement of the JasPer license? Also, why would anyone be against supporting jpeg2k? (That's meant as a serious question, not a flamebait.) Personally, I'm anxious to see widespread support for it. Is there a better alternative? (Note that comment 13 mentions that Jpeg2k is low priority for Pavlov, which I acknowledge and understand.) As for incremental image decoding, it's a "nice to have but not essential" feature as far as I'm concerned.

For interests sake, the Jasper library has changed its licence now... https://www.ece.uvic.ca/~mdadams/jasper/#news -- The JasPer software has been re-released under a new (and less restrictive) license. This new license is truly open-source by the standard definition of the term. (The license is based on the MIT license.) All of the more restrictive clauses in the old license have been dropped. This change was made at the request of the open-source community in order to allow more widespread use of the JasPer software. -- Even though the library might not support progressive decode, any decode is better than none.

YAY!

*** Bug 262296 has been marked as a duplicate of this bug. ***

I am very interested in seeing this feature added. Progressive decoding, being able to specify a filesize, and better compression should create a better web experience, and provide more flexibility for web designers.

*** Bug 276821 has been marked as a duplicate of this bug. ***

now, nearly a year after the license has been changed, mozilla didn't manage to support jpeg 2000. Is there any progress been made since the the license change?

What is sad is that this is such a great feature, yet nobody knows about Jpeg2000 - except the most uber web/graphic designer. JPEG2k is superior to plain JPEG, saves bandwidth, supports alpha, spot compression, lossless, supports region of interest, and requires no extra effort on the web development side other than the graphics program has to support it. It's built into Adobe Photoshop CS, and there is a free plugin available as well. I am for this feature more so than SVG. Do we have to wait until IE7 before Mozilla wakes up and adds this feature? Free plugins: https://www.fnordware.com/j2k/ https://www.leadtools.com/Utilities/PSPlugIn/PhotoShop_plug-in.htm

This could be a breakthrough technology for scaling images down to popular mobile devices with the Minimo UA. https://www.aware.com/products/compression/whyj2k.html#Resolution%20Scalability

*** Bug 284972 has been marked as a duplicate of this bug. ***

Wow. A year of total silence in this room. I can feel the tension. If everyone starts talking it will break the ice. For what it's worth, a WHOLE bunch of FOSS software friendly tools seem to being using the Jasper code now: https://www.ece.uvic.ca/~mdadams/jasper/#users Sidenote: even if the use of j2k is sparse (arguably caused wholey by lack of viewing support in web-based products ;-), it truly is a remarkable technology for reducing bitrate and increasing quality. There are currently NO consumer digital cameras that support it, but j2k's use is anticipated (being preciptated actually) due to its finding use in the last year in the video field, for high quality intra-frame based HD and SD video capture, at much lower birates / higher quality compared to DV or HDV formats (or any DCT based CODEC for that matter).. there are now also hardware (chip) manufacturers that should soon be accelerating adoption in digital still-cameras. I for one agree with an earlier vote that any j2k support is better than none (based on lack of progressive display). And it appears that another browser will support it first :-/

(dont know if this is relevant for this bug) the QuickTime Plugin (at least on my Mac) has support for image/jp2, image/jpeg2000 , image/jpeg2000-image and image/x-jpeg2000-image but for some reason the JP2 Picture doesnt show up in the Linked URL, but it works fine with https://gemal.dk/browserspy/pics/test.jp2 (or opening the page in Safari) maybe you could tweak Firefox into using the QuickTime Plugin for using JP2 Images untill a native support is available?

Wouldn't jpeg2000 support be a nice project for Google's Summer of Code? Google itself uses jpeg2000 (at least internally) and if you look at Google Maps; using jpeg2000 would be a significant improvement (not to mention the fact that many sattelite and aerial imagery companies already work with jpeg2000 with geolocation information embedded).

Mac OS X 10.4 supports JPEG 2000 natively, so Safari browser supports it too.

So let me summarise: There is (or at least was) a working patch, the only "reason" not to include JPEG2K support is because this patch doesn't support incremental rendering and nothing has been happening for years now. Can anyone explain this to me? Not only does Adobe Photoshop support JPEG2K encoding, almost any Mac OS X software does so and I would really like to use this feature if only Firefox supported these images. The technology is great, it just isn't used for *some reason*. Perhaps we just have to wait for Windows Media Photo. Microsoft will have the power to force all other browsers to support this format.

To bring it on the point - the reason why nothing happend for years is simply that we don't have an active developer who is able to integrate JPEG 2000 support to the mozilla browsers. As you can see by the amount of the positive comments there is indeed a huge demand for this support. But what shall we do? I guess not many developers have experience with JPEG 2000 at all. So giving the Mozilla browsers the JPEG 2000 support would be for every Mozilla developer something complete new, that he hasn't done ever before. I am not sure if the gimp supports JPEG 2000 but if it does, somebody should ask one of the gimp developers to have a look at the code of the Mozilla browsers. That's why nothing is changing. And there won't be any change till someone makes this tiny step so that the Mozilla Browsers make a huge step ;

(In reply to comment #70) > To bring it on the point - the reason why nothing happend for years is simply > that we don't have an active developer who is able to integrate JPEG 2000 > support to the mozilla browsers. > > As you can see by the amount of the positive comments there is indeed a huge > demand for this support. But what shall we do? I guess not many developers have > experience with JPEG 2000 at all. So giving the Mozilla browsers the JPEG 2000 > support would be for every Mozilla developer something complete new, that he > hasn't done ever before. > > I am not sure if the gimp supports JPEG 2000 but if it does, somebody should > ask one of the gimp developers to have a look at the code of the Mozilla > browsers. > > That's why nothing is changing. And there won't be any change till someone > makes this tiny step so that the Mozilla Browsers make a huge step ; > Is it 'only' the lack of developers? In that case the word should be brought out. I didn't find an official GIMP developers forum, but if and when I do find an appropriate place I'll post a message with a link to this bug. I think a JP2K implementation is important enough to search and call out for help. Surely if everyone will know about this "open position" someone will be glad to help.

Guys, complaining won't help. Let's put our money where our mouths are and plunk down some cash and make a bounty for this bug/feature. A couple hundred dollars should do it. I'd put in $100 or so. How about it? This will give it some traction if there's enough $$$.

One thing is for sure... if this feature doesn't make it into the next major version of Moz & Firefox(2.0), users will be left waiting 6-12 months for the next release version, while all the other browsers (Safari, IE, Opera, etc) will already have support for jp2k, and no doubt it will start being widely used on websites, once both IE and Safari support it...

(In reply to comment #72) > Guys, complaining won't help. Let's put our money where our mouths are and > plunk down some cash and make a bounty for this bug/feature. A couple hundred > dollars should do it. I'd put in $100 or so. How about it? This will give it > some traction if there's enough $$$. > Personally I won't participate, but if you are willing to organize such thing Bugzilla probably isn't the place. Maybe mozillaZine will be the place to do it.

https://packages.qa.debian.org/j/jasper.html Jasper is the free software library for providing jp2 support. It should be fairly straightforward to implement in Firefox. I think Apple has licensed https://www.kakadusoftware.com/ which seems to have much better support for the format.

Does anyone with diplomatic abilities want to convince the Kakadu guys that it is in their interest to release an open source noncommercial sharealike version of their code because that would lead to a more widespread use of JPEG2K which will in turn put pressure on commercial software developers to implement it for which they will probably purchase a license from the Kakadu guys?

(In reply to comment #76) > Does anyone with diplomatic abilities want to convince the Kakadu guys that it > is in their interest to release an open source noncommercial sharealike version A "noncommercial sharealike" license would likely be incompatible with the MPL. While we're listing libraries, OpenJPEG looks like another possibility.

Looks like openjpeg.org released 1.0 version of their library, may be jp2 support will be implemented soon?

About comment #15: The plugin doesn't work for me. But there is the morgan plugin available which works more or less. https://www.morgan-multimedia.com/JPEG2000/mozilla_plugin.htm Still you can't include a .jp2 file with the <img src="..."> tag but at least it works. About comment #73: Well, 2.0 is released by now and still nothing happened. :-( Btw: This feature request was added 2000-04-19 and still nothing happend. You can download a firefox plugin (GNU GPL) from https://linuxj2k.org/ and also the source code. It seams as this plugin only works on linux.

I wish Firefox could stand out from the crowd and be the first to support both JPEG 2000 (https://en.wikipedia.org/wiki/JPEG_2000) and Microsoft's Windows Media Photo (https://en.wikipedia.org/wiki/HD_Photo). It would be nice for Firefox to implement Microsoft's photo format before IE!

For anyone wishing to tackle this bug, I've done a quick code-dive into the source code of image library libpr0n and created wiki page about it at https://wiki.mozilla.org/Libpr0n You can browse the libpr0n source code at https://lxr.mozilla.org/seamonkey/source/modules/libpr0n/ (look at decoders/xbm for the simplest example.)

I just encountered a JPEG-2000 file in Thunderbird 1.5 (again), and of course it could not be displayed. So I did a search and found this stone-age old bug from the year 2000. Two comments in this bug are very funny: # 5 (2001-01-02) "Mozilla should support Jpeg2000 as one of the first browsers." And now, 6 years later: # 80 (2007-03-18) "I wish Firefox could stand out from the crowd and be the first to support ... JPEG 2000 ..." Can I hope the upcoming Thunderbird 2.0 -- just like Firefox 2.0 -- will resist to display this evil format which tries to sneak into the Mozilla codebase since it was ISO-certified in the year 2000? ;-)

Some time ago the devs stated that no new image formats would be added to the core without a very good reason, such as being recommended for use by the W3C. The suggested way to add new formats is through the extension system. Here are the main bugs related to this task: bug 374088 bug 374089 bug 374225

I have updated my patch mentioned above to Firefox versions 2.0.0.11 and 3.0b1. It is at https://wwwi2.informatik.uni-wuerzburg.de/mitarbeiter/tischler/mozilla/ . I have also provided some compiled packages. Perhaps someone finds the time to transform the patch to a mozilla extension. I spent some time looking at JasPer and sadly it seems there is no simple (and efficient) way of adding progressive decoding yet, but this may change in the future.

This might be what everybody is looking for, it supports arbitrary/progressive decoding and is Open Source: https://www.2kan.org/public/2KAN_JPIP_overview.doc From what little I understand it sounds just right!

Can someone at Mozilla please change the status of this Bug Report to something sensible??? This bug-report has been open for 8 years, with no apparent interest from Mozilla's to implement JPEG2000 internally. So close the bug/feature request for internal support and point to the extension. What surprises me most is this: [Comment #67] "Wouldn't jpeg2000 support be a nice project for Google's Summer of Code?" Which was my comment in April 2006. A year later, in 2007: --> https://code.google.com/soc/2007/mozilla/appinfo.html?csaid=C7B9CCBBF96648B3 The (current) result: --> https://svn.eschew.org/projects/mozilla/jp2/libjasper/mozilla/extensions/render-jp2/ --> https://eschew.org/test/jp2/xpi/

Nooo! Don't close it just because it is open! We can't handle problems like this. There is a demand for the support of jpg2k files. An extension for the browser is not the right solution. An extension is makeing more harm than good because an extension is knockout argument to say that firefox is supporting jpg2k. But actually isn't. Because webmasters still can't use the format and users can't view jpg2k pictures without the extra installation. Other browsers will presumably support newer graphic formats and make them spread for good reasons. Hindsight is better than not doing anything at all.

Yes, there is demand for JPEG2000, but if browsers do not back the format, than JPEG2000 will die a slow death, at least online. There is no point in "eventually wanting" to support a format which is already heading that way. It will only cost time and resources, without significant returns. Seeing that JPEG2000 is not likely to be supported by Mozilla in the near future, JPEG XR (Windows Media Photo / HD Photo) will have better odds at succeeding JPEG online as it is backed by MS and already available in Vista.

"At least online" JPEG XR seem more on-par with obsolescence; dubious/limbo license, little software support, metadata/interop, no video/wavelet derivaties. And MS's usual marketing comparisons of quality and speed, but w/o empirical evidence. J2K as a web format has seen little adoption because in a web context faster line speeds and PNG's features (arguably) obviate the most important benefits of (both formats). Even on still-cameras, quality, large storage, and speed still dictate using RAW if quality matters, JPEG v1 if interop matters. The compelling advantage of "HD Photo" is difficult to see, for acquisition OR the web, why add it to the code base? TIFF and other formats would be more much more useful.

Please do not confuse Microsoft's HD Photo format with JPEG 2000. JPEG 2000 is a format backed by the Joint Photographic Experts Group and enjoys has accumulated license waivers by many copyright holder for the compression techniques used. Furthermore, it supports transmission of various qualities from the same file. This would be a good feature for web developers, as it means that they would only need to keep one good quality version of an image on their site, and users may select a quality level they are comfortable with. According to wikipedia, HD Photo's licensing is also considerably more restrictive than JPEG 2000's despite Microsoft's assurances that it would be released with a "open" license. Please see wikipedia for further details: https://en.wikipedia.org/wiki/JPEG_2000 https://en.wikipedia.org/wiki/HD_Photo

Microsoft's HD Photo = JPEG XR (more or less). See https://www.jpeg.org/ or their latest press release https://www.jpeg.org/newsrel21.html

(In reply to comment #83) > Some time ago the devs stated that no new image formats would be added to the > core without a very good reason, such as being recommended for use by the >W3C. Was APNG recommend by the W3C? I don't believe it was. In fact I believe the PNG group rejected it. Not that I was against adding apng to the core, in fact I was for it, but it would seem the devs didn't follow the behavior you stated there. I personally think the Joint Photographic Experts Group and the International Organization for Standardization(ISO) are nothing to sneeze at. Granted neither organization are specifically devoted to the web, like the W3C is but JPEG2000 would have clear benefits for the web. It is more efficient than JPEG and with the proper encoder under tests I have seen(https://www.imagecompression.info/lossy/ and others I've seen) more true to the image than HD photo. This means that widespread adoption of the format will reduce bandwidth usage for servers and speed-up page loads for clients. Ultimately, improving the web.

I'm also asking myself: Why support some crude standards like APNG and ignore the older, more thorough thought out standards? They are more sophisticated and have already ready made libraries that you just have to link in. Like OpenJPEG for JPEG2000, or LibMNG for MNG. I vote for this enhancement!

This doesn't have to be some kind of battle between formats. To support as much as possible, as long as it isn't supposed to be used on the web anymore, I would say is the most important.

(In reply to comment #95) > This doesn't have to be some kind of battle between formats. To support as much > as possible, as long as it isn't supposed to be used on the web anymore, I > would say is the most important. Yes! Firefox tradition is even to _support_ progress, and push file formats to make them wide accepted standards. Like the Theora and Ogg/Vorbis Video/Audio standard. Without Firefox the format would have absolute no support from a "big player" browser. And it's no recommended W3C standard.

(In reply to comment #96) Actually, Ogg was required by an HTML 5 draft at one point. Regardless, JPEG 2000 should still be supported.

JPEG2000 is simply not used enough or important enough to justify the outlay of code, time, and increased threat surface. However, I would welcome an addon for JPEG2000 support; if it sees great use, we may reconsider this decision.

(In reply to comment #98) Wasn't the same argument used against APNG? How can it "see great use" if no browsers support it? (Plus, unlike APNG, it's an ISO/IEC standard.) IMHO, either this or bug 374225 should be reopened.

I also want to add what suprisingly no one wrote till now: ======== JPEG2000 is not only a compression improvement... It supports transparency! An alpha channel with 8-bit transparency. To my knowledge Firefox supports no other lossy image format which has that important feature! ======== Currently the only way to use lossy images with transparency is: Adobe Flash. I think we can all agree that this isn't satisfying. To address your issue with the distribution of JPEG2000: That argument speaks also against the Theora Format. Practically no one uses it, the only big player started using it is Firefox. To get it used more. So why did Firefox don't add that as an Extension? Because that way it won't get used. They included it, right into their source. So that in the future it might be used. I'm also encouraging everybody _not_ to write an extension. The history has shown that is a waste of time. None of any file format extensions have _ever_ been successful. (Maybe they wouldn't with bug 374225, but that enhancement has been closed with wontfix.) The only way are patches / forks, then you (implementers) _may_ have a chance.

JPEG with transparency, the dream. The transparency on PNG with the photography, this is unusable on the web. If there is no browser that supports it, the format will never be used.

(In reply to comment #98) > JPEG2000 is simply not used enough or important enough to justify the outlay of > code, time, and increased threat surface. How much more comments does it need to have just following this bug report cause more work than having implemented JPG2K support using one of the available libraries in the first place? ;) > However, I would welcome an addon for JPEG2000 support; if it sees great use, > we may reconsider this decision. It has been argued before but: Why would it see *any* use? No web page uses JPG2K because no browser supports it (except Safari on Mac OS IIRC).

JPEG 2000 is an nonproprietary format, as clear of any legal encumbrances as the ISO standards body could make it. There are no legal issues nor have their been since the standard was introduced. All stakeholders waived all of their and their successors rights, in an effort by the working group to prevent any potential chilling effect about exposure to such issues - they wanted the standard to be open and widely adopted, because everyone could benefit. This standard in terms of exposure when compared to previous standards, and is certainly safer than some formats included in Mozilla today. The format has numerous benefits to the browser, including multi-layered images, multi-resolutional capability within a single file, over double the compression efficiency, and facility to work with very large images. There re a lot of good reasons to include this format - Google already uses it in their mapping, Yahoo uses it in video chat, Safari includes it in their Webkit. Mozilla would significantly improve the adoption of a modern open image compression standard that the web at large would greatly benefit from.

The best way to advocate for what you want here is not by continuing to argue in this bug. Advocate by developing the add-on (portably to all of the top-tier platforms) that was suggested in comment #98 and driving its usage.

(In reply to comment #104) > The best way to advocate for what you want here is not by continuing to argue > in this bug. Advocate by developing the add-on (portably to all of the > top-tier platforms) that was suggested in comment #98 and driving its usage. As already said: Yes, an extension sounds like a great idea. It's easy to install and the Firefox team doesn't have to maintain it. But: That has already been tried more than once and has never ever worked. And never will. None of the __file format__ extensions code was ever brought into the Firefox code. Till now every file format extension was left to die and none was ever overtaken. If it isn't in Firefox and prominently advertised, like the Theora video support, no one will use it. The only way is to fork Firefox and bring the Mozilla coders ready-made patches continually. After a while they may accept it. Don't ever bother writing file format extensions - write something "harmless" like a tab colorizer if you want your code to be overtaken.

JPEG2000 is actually widely used in archives for high resolution scans and for astronomy images. It's a well matured standard too, not some newly invented fileformat that people try to push through Firefox. And yes, making an extension for a file format is obviously useless.

We'd consider a patch for the Ubuntu builds of Firefox.

(In reply to comment #107) > We'd consider a patch for the Ubuntu builds of Firefox. That's a great idea. Considering you could use the JasPer library on Linux. Which has been proven pretty useful for Linux projects to my knowledge. And will be therefore also constantly maintained. That means: if there are security flaws in the library, it should affect some other different Linux projects, so that it gets immediately fixed. For example: KDE(!) and ImageMagick. And: the library is to my knowledge also usable under other OS's. The problem with that library, mentioned here 5 years(!) ago, was that the library had some restrictions, but only until the JPEG2000 standard gets officially released. Well, that happened already years ago! And consider that even the Linux community embraced that library, what would be very strange if the library had some restrictions which were against the Linux OpenSource spirit. Here is a link to the license: https://www.ece.uvic.ca/~mdadams/jasper/LICENSE I can see no collision there.

That's cool, but we'd need a good quality patch which integrates it into the core.

(In reply to comment #109) > That's cool, but we'd need a good quality patch which integrates it into the > core. Do you think Mozilla will like that you call the result Firefox ?

(In reply to comment #98) > However, I would welcome an addon for JPEG2000 support; if it sees great use, > we may reconsider this decision. For those interested in implementation details, now that bug 391667 is fixed, only bug 374089 can prevent from writing an external component that could handle other image formats (think dejavu, mng, jpeg2000...)

(In reply to comment #110) > (In reply to comment #109) > > That's cool, but we'd need a good quality patch which integrates it into the > > core. > > Do you think Mozilla will like that you call the result Firefox ? For exact such reasons there exists already the Iceweasel project for Debian (Ubuntu is based on Debian). Additionally I think they won't care much for beta versions. And if the beta versions is satisfying enough they will hopefully eventually overtake the patches in their main core and release it with their next final.

(In reply to comment #110) > Do you think Mozilla will like that you call the result Firefox ? Isn't that his problem (or not, as the case may or may not be), and not really relevant to the feature this bug wants fixed? And isn't that concern rather immaterial until a patch is created anyway?

(In reply to comment #113) > > Do you think Mozilla will like that you call the result Firefox ? > > Isn't that his problem (or not, as the case may or may not be), and not really > relevant to the feature this bug wants fixed? And isn't that concern rather > immaterial until a patch is created anyway? you all are missing the sardonicism in Mike's statement. he is the debian iceweasel maintainer, so he knows very well the firestorm that comes after releasing an unapproved version with the mozilla trademarks.

Cut the chatter. This bug is about jp2k support, noise in it is counterproductive. /be

the trademark issues are a legitimate concern and have a significant impact. it is very much so productive to consider the effect of this policy within this discussion.

Please, calm down everyone. A practical suggestion: Just let us try getting a version done for Debian/Ubuntu Iceweasel, and _then_ convincing the Firefox people to overtake the code. If the implementation is good, I think there should be no problem for them.

(In reply to comment #116) > the trademark issues are a legitimate concern and have a significant impact. > it is very much so productive to consider the effect of this policy within this > discussion. Wrong bug. You need to re-read the bugzilla etiquette guide. /be

i have no desire to prolong this bickering, but will simply point out two ironic facts: your call for less noise in fact created more, and you are violating the etiquette guide you so gracefully called upon.

It is generous of Mark to offer to test a patch, though I think his terseness here has probably lead bug followers to misinterpret his comments as indicating that Canonical would ship a Firefox with a forked imagelib. They are certainly aware that that's not good behaviour, so I'm certain that Mark was simply offering his beta channel as a test vector for a production-quality patch. It would be helpful to hear why Mark believes that JPEG2000 support is valuable enough to include in Firefox, though. (And worth the effort, code size, and threat surface, as correctly pointed out by Joe.) To get JPEG2000 into Firefox, we would need: - an available library of sufficient quality (including incremental display, certainly) and appropriate licensing and available maintainers -- we do not want to sign up to maintain such a format library ourselves, in the event of security or other serious bugs found in the future. - a careful analysis of the patent landscape, since by my reading the patent disclaiming only covered part 1 of JPEG 2000, and we would need to ensure that the selected library didn't implement other, encumbered parts of the format. ref: https://www.jpeg.org/faq.phtml?action=show_answer&question_id=q3f042a68b1081 - fuzzing and security review of the resulting library; Apple's library, which is above described as higher quality than at least some available open source ones, is susceptible to crashes on invalid image data (ref: https://www.openradar.me/6758757, even after they fixed https://securitytracker.com/alerts/2006/Sep/1016953.html quite a bit earlier) - an appropriate test suite (possibly coming with the aforementioned library) - review of the resulting code from the graphics module owner or peers Given that Safari supports it, I think it's reasonable to expect that there is some use of it on the web to demonstrate use cases; I expect that Safari now has more market share than Mozilla did when Mozilla support was deemed the route to widespread use of JPEG2000! (There are certainly quite a few demonstrations of other Safari-only features, like CSS transitions and 3D transforms, even though they are much more recently deployed!) Examples of such cases on the web would be helpful in prioritizing the review of the new code against other work. This bug is a suitable place to collect such information; please keep other advocacy out of it, if you want to help the adoption process. Thanks for your interest in Mozilla!

If anyone out there is actually cooking up a patch, keep in mind that the architecture of Imagelib is about to change pretty significantly - See in particular bug 435296 and bug 512269 for some upcoming API changes. Ping me on irc (bholley) if you have any questions.

And six months later, no changes. 10 years after it was opened. I can't believe whoever makes the determinations on here actually marked this "wontfix." What does ideology have to do with it? Is there some big decision-maker whose wife was cheating with one of the main developers of jpeg2000? What's the problem here? The people talking about JPEG being enough, sound like people who think xvid in avi is "enough" and that we don't need h264 in mkv. Progress is pointless? Extra "threat?" From including support for an image format? This isn't something that can be handled?

The reasons are more like excuses. If JPEG is enough, so is flash. What's the point of HTML5, esp. with exclusive Theora support?

All this time and we won't add the *leading GIS, photo archival, and medical imaging format* .. and after 10 years there is no challenges or encumbrances to the IP, no issues with legality...and everyone still has to use a 3rd party plug in. And all they see is risk.. from an open standards body, a non-proprietary image format that went out of the way to help get it adopted, make it open source, and all you hear are excuses.. Someone even wrote a plug in - and they can't even get it adopted. All open standards, open source code for years. I'm wondering where in this organization is someone is "progressive" enough to adopt a 10 year old image format. - Like 2 of the other browsers.. Frankly it's mystifying to me. WHAT Threat?? From what? Let's close the code and offer no new features! That's how we'll be a leading browser! sheesh.

(In reply to comment #124) > Someone even wrote a plug in - and they can't even get it adopted. Not aware of an extension/plug-in for jp2k at all. Where did you see this?

See comment 67, 87 above.

This all reminds me of a certain other browser which became very popular and then thought it needn't do anything to improve itself for many years.

Feeding the troll, but... (In reply to comment #127) > and then thought it needn't do anything to improve itself for many years. You know this isn't true. You know numerous other user features have been added, web author features have been implemented, and existing features improved in this time period. Overwrought rhetoric does nothing to make it likely your concerns will be addressed, indeed perhaps worse than nothing in that what feedback you give will be ignored entirely.

Thanks for responding to my rather provocative post. I think I am expressing the frustrations felt by others following the "WONTFIX" status, but I don't need to continue being pugnacious, and of course Mozilla is doing good things in other areas (e.g., HTML5). However, let me re-state what it seems everyone else has been saying: that JPEG2000 is an excellent image format (I particularly like the losslessness and transparency: PNG24 for photos) and _in an ideal world_, it would of course be supported. From a reading of all the comments, the reasons given for _not_ adopting it are as follows: (1) Because it is not widely used on the web. Besides this being a self-supporting and circular argument, the fact is that JPEG2000 is now being supported by Safari, Konqueror and Opera-via-QuickTime, and judging by the support for this feature request, I suspect there are many websites and web-related projects that would use it, if they could. Off the web, it is widely used in mapping (e.g., Google, the Met Office), medicine and photo archive (obviously because of its lossless feature) and is supported by Photoshop, GIMP, ImageMagick and others. And there are examples of Mozilla supporting formats that weren't/aren't widely used at the time of adoption (or even recommended for use), such as Ogg in <video> (what a waste of time that'll -- probably -- turn out to be when Google open sources On2's VP8 codec, slated for May) and APNG (rejected by the PNG Group, but implemented by Mozilla in March 2007 and used by no-one, apparently). (2) Supporting it would involve a greater risk to browser security and stability, and it would need to be tested (e.g., comment #120). This obviously applies to any new feature, so I don't see this can be an argument, except insofar as it would involve a considerable amount of work (see point 3). (3) There are doubts about whether any developers are able and willing to do the work. This may have been the case, but it was part of Google's Summer of Code 2007 (as noted in comment #87) and an extension resulted: https://svn.eschew.org/projects/mozilla/jp2/libjasper/mozilla/extensions/render-jp2/ And there's also a Mozilla plugin: https://plugindoc.mozdev.org/windows-all.html#MorganJPEG2000 However, I fully understand that it is no use arguing for a feature if no-one is willing to implement it _now_; but a lack of developer interest cannot be used to justify an obstructive "WONTFIX". I am not myself able to work on this, but I would be willing to donate funds towards it if possible, and as noted some work has been done already, and there is obviously a lot of interest by those on the sidelines. Mark Shuttleworth came on here and offered to help take steps towards getting it into the Ubuntu version, so you can't say there isn't willingness to get this underway... but apparently after he commented, Mozilla slapped the "WONTFIX" on it. What's going on? I could understand apathy (as noted in a quote from pavlov), but it now seems there are definite efforts from on high to stop JPEG2000 from happening in Firefox. (4) Potential intellectual property rights issues. As noted in comment #120, and following my understanding of the issue, these concerns don't apply to the core JPEG2000 specification, but it would be necessary to ensure no dubious extensions to the spec were implemented. And (empirically) no-one has been sued for implementing JPEG2000, which surely would have been the case by now (and in the UK, it has been in use for so long that any action against, e.g., Adobe is probably statute-barred). I don't think this should actually stop development, and for myself I would be happy to look into this in detail if there were a chance to change the Mozilla position. (5) It has also been stated that Mozilla won't support things that don't form part of a W3C recommendation (comment #83). Well hey, what about Ogg and APNG, neither of which are ISO formats like JPEG2000? And anyway, JPEG2000 is being considered as a _requirement_ for SVG 2.0, so (assuming SVG2 is adopted by Mozilla), wouldn't it be a good idea to get going on this now? Maybe the W3C will end up being the one to force Mozilla's hand. In the meantime, I note that Microsoft is pushing ahead with its own proprietary JPEG-XR format, in use on Vista and Windows 7 and due to be included in IE9, because obviously _they_ recognise JPEG is obsolete, and they sense the opportunity to make money on patents; so come on Mozilla, you have a chance to do something that will (genuinely) improve the internet: "maybe not today, maybe not tomorrow, but soon..."

Let me reply: I was the last one pushing this entry. And I'm still willing to code the Jasper library into a solution for Mozilla and actively maintaining it. But I'm currently full time bound on another project (not at Mozilla). And this may still take another 6 months to finish. And if I have enough time after that is written in the stars - so if you feel the urge to include j2k support into Mozilla - don't hesitate a split second, take the jasper library and include it. Please, I really want this feature too!

Who here wants to contribute or sponsor a bounty? As long as it fits Mozilla guidelines and won't be shot down, I'm willing to donate.

Who marked this "wontfix?" Can I throw something at them? Nothing heavy or sharp... just something annoying like a crushed ball of paper. Troll or not, it had been six months since the last comments and I wanted discussion back on this topic, as I've been watching it for over two years without saying anything. I'm not a programmer (two years of C++ convinced me I wasn't up to the task) but I did learn it's libraries and time. That it hasn't been implemented yet is ideology and I feel the need to fire a spitwad.

I don't really have a certain opinion here, to me it doesn't matter since I don't work with any form of JPEG images on the Internet, but, I think it boils down to two questions: Is the format worth supporting, considering the future maintenance need, potential security holes and performance impact it might have? (for the people who want the support to be included) Would a fully working patch be accepted or is the decision to not support it, final? (for Mozilla)

I too, have kept quiet on this one until now. It seems we have a couple of options :- (1) We convince the Mozilla team to implement and support JPEG2000. Pros: - Mozilla gains additional support for formats - Wide user testing, hopefully meaning bugs will be discovered sooner Cons: - Extra work for the Mozilla team (2) We rely on plugins Pros: - Mozilla don't have to do anything Cons: - Security holes are much harder to deal with - People have to manually source and install plugins for their browser ==> potentially fewer people testing Luckily, Mozilla's codebase is opensource, so we also have this option: (3) We fork Mozilla (with the view of merging in the future), to implement JPEG2000 Pros: - Mozilla doesn't have to do anything - We can manage the security implications Cons: - Smaller testing audience - We still then need to convince Mozilla to merge in and support our changes in once the work is complete Security implications of supporting a new format natively, surely have to be better than just leaving it to a plugin, so on that viewpoint, I think we're better to just roll with it... we really don't want another mess like Flash. If Mozilla doesn't want to do it, they don't have to. We can go ahead and implement it ourselves, opensource gives us that choice -- the only catch is that we can't call our creation "Firefox". Perhaps the Iceweasel fork may be a useful testing ground for this (sufficiently arms-length)? If done properly, I see no reason why Mozilla can't join in at a later date, should they decide to come onboard. I dare say peer pressure will bring them onboard if enough of the alternate browsers begin supporting it natively. :-)

I'll reiterate my offer to include a reasonable patch that implements this, in the Ubuntu packages of Firefox. The patch would need to pass security and maintainability reviews.

People interested in making this move forward should focus on bug 374089.

Maybe it's indeed time to fork from the current status of development because Mozilla doesn't only block the implementation of JPEG2000 but also MNG and JNG. JNG has a JPG datastream plus the alpha transparancy from PNG. The Konqueror already supports this file format. There are plugins available for the Internet Explorer, Opera und Firefox. Firefox already supported this file format but isn't supporting it anymore since version 1.5a. See bug #18574 MNG is an animated png-a-like file format. It could replace the gif files. While gif files can only cope up to 256 colors, png has also alpha transparency. MNG was also supported by the firefox.

(In reply to comment #137) > MNG is an animated png-a-like file format. It could replace the gif files. > While gif files can only cope up to 256 colors, png has also alpha > transparency. MNG was also supported by the firefox. What advantage does MNG provide over the currently supported APNG format?

It's also hard to see what JNG can do that J2K cannot do more elegantly. I hope the poster of comment #130 can find the time to do JPEG2000 in due course, but I think Mozilla also needs to revise its position on this bug.

Well, APNG was created by some guys of the Mozilla team. APNG is some kind of Mozilla-specific-file-format. It has never become part of the png standard because there is no clear separation between the standing image and the animation. Something like that was the reason which was given by the png developers. This reason isn't necesarrily a bad thing, especially because this makes APNG backwards compatible to PNG compatible programms (Firefox 2.0 for example). But yes, you guys are right. Let's just stick to JPG2000 first. A long discussion had already took place at bug #18574 and since the implementation of APNG the demand for MNG decreased.

This bug is/was 10 years old. And all we get for it is a pedantic technical circle-jerk about esoteric file formats by people who have no concept of distinguishing the difference between "de facto" and "de jure" standards. Yes I know the difference betoween gif, jpg, and png -- the rest of the world DOESN'T CARE ANY MORE. Mozilla lacks the fundamental ability to prioritize and conform to change where there's pre-existing momentum in areas it does not -- and cannot -- control. As a former Netscape employee it pains me to have switched to Chrome because Mozilla can't fight its way out of a technical paper bag.

(In reply to comment #139) > It's also hard to see what JNG can do that J2K cannot do more elegantly. > > I hope the poster of comment #130 can find the time to do JPEG2000 in due > course, but I think Mozilla also needs to revise its position on this bug. PNG doesn't allow a lossy compression. The only alternative is Adobe Flash, but it's not usable with CSS.

Some mentioned JPEG2000 plugin. Here are the links (it seems outdated for now): * https://linuxj2k.org/modules.php?op=modload&name=Downloads&file=index - plugin for Firefox * https://scilincdev.blogspot.com/2006/12/viewing-jpeg2000-images-in-linux.html - installation instruction for that

Many people have recently been suggesting implementing a jp2k-supporting version of Firefox for Linux. That's well and good, but A, Linux users already have a work-around solution. B... like it or not, most people don't use Linux. We need a solution that works regardless of operating system. People suggesting we need to look at a different bug, are *really* too far down the rabbit-hole of ideology over practicality. It can't get fixed because people are talking about it in the wrong thread? If that's the reason, it's worse than I thought.

I think the Linux implementation would be merely a stepping-stone, not OS-specific. No need to get concerned by that: clearly Mozilla have some hoops set up, but they aren't impassable.

(In reply to comment #144) > It can't get fixed because people are talking about it in the wrong thread? If > that's the reason, it's worse than I thought. What are we even discussing here? It's obvious that almost everybody wants this feature but so far nobody actually wants to *implement* it. The only meaningful post at this point would be something along the lines of "Fine, I'm doing it" (or actually more people agreeing to pay for someone to do it). As soon as there's a patch, we can accept Mark's great offer and have it included in Ubuntu. When that has happened, please continue to discuss mainline inclusion and other operating systems.

> What are we even discussing here? It's obvious that almost everybody > wants this feature Well, everybody except Mozilla. > but so far nobody actually wants to *implement* it. Not true: read the comments. But anyway, it's clear that the only way forward is to do the nuts-and-bolts, and anything else is mere persiflage.

Actually, I think the noise on the subject is worthwhile, even if it's mostly by people saying "I wish we had this" instead of "I can do this." If I weren't the sorriest programmer in all Christiandom, I'd be on it like sauce on spaghetti. A few people who have said they are capable of doing the work, have said they are busy, but want to. If no one had shown any interest (there hadn't been a comment in six months before my first) they might not have bothered. Hopefully they will.

In response to Joe Drew, who closed this bug as WONTFIX with the following comment: > Joe Drew (:JOEDREW!) 2009-08-24 20:18:30 PDT > JPEG2000 is simply not used enough or important enough to justify the outlay of > code, time, and increased threat surface. > > However, I would welcome an addon for JPEG2000 support; if it sees great use, > we may reconsider this decision. Joe, in light of the recent arguments, especially about JPEG2000 being already implemented in Konqueror and Safari, and about Microsoft going forward with their own JPEG-XR image format to occupy the high quality lossess format market, and in light of presence of volunteering implementors, would you reconsider the status of this bug and reopen it?

I don't know if this is helpful, but just some notes: Webkit based browsers (Safari, Chrome) on Mac OS X already have support for JPEG2000 (they are probably using Core Image, just a guess). The same browsers on Windows have no support for JPEG2000. Adobe Photoshop and almost everything else no longer ships with support for JPEG2000. Someone used DevIL to implement a bunch of formats for Flash - including JPEG2000 (this isn't relevant, but it is pretty spiffy). Could DevIL be used for Mozilla? https://www.zaalabs.com/2010/04/introducing-zaail-40-image-format-support-for-flash/ https://openil.sourceforge.net/

Photoshop (as of CS4) *does* ship with support for JPEG2000, but it's an optional plugin (as it's always been, or so I believe): https://help.adobe.com/sv_SE/Photoshop/11.0/WSfd1234e1c4b69f30ea53e41001031ab64-7749a.html If you think it relevant, can you give examples of other software that "no longer ships" with JPEG2000 support (i.e., which previously did but now does not support it)? Quality of support seems to vary quite a lot, but it does exist. However, lack of *inbuilt* support for it has been one of the problems (as well as lack of support in cameras and web-browsers). There has been a whole load of negative groupthink, it's fair to say. You have a point about Safari -- I tested it on Windows XP and it's true that it doesn't support it natively, but the interesting thing I have discovered in my tests is that all the browsers on Windows (with the exception of IE6) will display JPEG2000s as an <object> via the QuickTime plugin, and QuickTime is installed on about 60% of systems. Even in Firefox you won't need a specialist plugin to see this: https://plugindoc.mozdev.org/testpages/jp2.html As noted, it's also part of Core Image on the Mac. So basically the prime supporter of the format is Apple... whilst Microsoft supports a rival and encumbered format in Vista and Win 7. It surprised me to discover that JPEG2000 is actually supported in PDFs too, so you can view JP2s in Acrobat and Foxit Reader.

You'll notice in that *CS4* link you posted, that they recommend grabbing the plugin from a *CS3* install CD. Sadly, they removed the product completely from CS4 disks, and I doubt it'll be back in CS5 (it hasn't shipped yet, so I can't confirm). Maybe you are right, that other apps haven't removed support, as much as they've let them quietly linger. It certainly lacks the industry support that other specifications like h.264 have though. That much is clear. SVG once had, but now doesn't have industry support though, and Mozilla et al do support that. If JPEG2000 gets into some standard, I'd say that's the only real reason to support it at this point. You nailed the rest of it - Quicktime has worked to display JPEG2000 for years.

Oops... yes, you're right about Photoshop. I do remember having to download the Photoshop JPEG2000 plugin from somewhere, but it is still available, although it's currently listed as a "legacy" plugin: https://www.adobe.com/support/downloads/detail.jsp?ftpID=4049 However, it seems it may have been a mistake not to include it on the DVD: https://blogs.adobe.com/jnack/2007/04/jpeg_2000_do_yo.html It would be interesting to find out if it makes a return with CS5. Obviously, having the ability to save files in that format in Photoshop is pretty important to this whole issue, but again I think it is a reflection of the general unwillingness of camera and browser manufacturers to support the format rather than a deliberate position being taken by Adobe, who after all included it in the PDF spec and have otherwise shown willingness to support it when others haven't. And it's not too late... but by arguing against the format, we will only create bigger problems in the future, esp. re: Microsoft. Whatever some people might think, JPEG will *not* be around forever: it can't be, because of its inherent limitations, and something will have to replace it. I simply don't understand the reluctance to embrace JPEG2000.

Here's another good reason to embrace jp2k, since this bug has again been ignored by the powers that be: 30% better lossless compression than PNG. Try it. If you have photoshop, get the jpeg2000 plugin and try saving a bitmap image in png and in jp2k lossless. Oh, we have huge hard drives now, who needs to worry about 30% space savings? The person with 10,000 images. The person with a SSD instead of mechanical drive. Any person who's interested in efficiency instead of the perceived ease of sticking with something that "already works well enough."

This is asinine. We've waited long enough. Apparently Firefox needs to be dragged kicking and screaming into the early 2000's. I have a financial interest in seeing this implemented, so I'm going to step up. I'm going to offer a $1000 bounty for native JPEG2000 support in Firefox, on Windows, Mac, and Linux. Terms: Interested parties should already be on the Firefox development team, or have a good working relationship with them (ie, patches & features applied to current code). Payment will be One Thousand ($1000) US Dollars paid via Paypal from my corporate credit card, paid 30 days after roll-out of the feature to all three platforms. You must contact me in advance, documenting your credentials (bugs fixed, patches applied, features accepted) and express your interest. I will select a candidate to perform the work. I will deal only with ONE person -- I will not get in the middle of spats about splitting the bounty. I'd like to see this implemented before December 31st, 2010. eMail: firefox.j2k -at- gmail.com

Well done for stepping forward, but I've noticed the email address at the bottom of your post contains a full point, whereas the one you've posted from does not. Shurely shome mishtake?

(In reply to comment #155) > This is asinine. > > We've waited long enough.... Yes! We did! I will happily add 50$ if I earn enough before December. That's not much, compared to 1000$, but I'm not rich. On the other hand: 50$ for such an important feature: Really cheap.

Not a typo. It works just fine. If there are others interested in contributing, maybe we'll register at one of the OSS Bounty websites to pool our resources.

(In reply to comment #158) > Not a typo. It works just fine. > > If there are others interested in contributing, maybe we'll register at one of > the OSS Bounty websites to pool our resources. That could be a good idea, the CC List for this bug is already extreme long.

Before you do that, you should check with whoever is responsible for IP in Mozilla - it'd be a shame to implement a patch for $1050 - only to find Mozilla can't include it due to patent issues (similar to the problems with h.264). I'd definitely check with Mozilla legal before proceeding. On a side note - I was sure this was a dead format that no one in any industry picked up for anything (due mostly to licensing complexity). Adobe even dropped support from Photoshop (years ago).

(In reply to comment #160) > On a side note - I was sure this was a dead format that no one in any industry > picked up for anything (due mostly to licensing complexity). Adobe even dropped > support from Photoshop (years ago). I save my answer for that and beg you to read the __whole__ thread before saying something like that. The legal stuff has also been discussed over and over. There are no reasonable reasons against that. Just FUD. Pure FUD.

(In reply to comment #160) > On a side note - I was sure this was a dead format that no one in any industry > picked up for anything (due mostly to licensing complexity). Adobe even dropped > support from Photoshop (years ago). JPG2000 is a normal compression method for images in PDFs. PDF supports JPG2000 since PDF 1.5 (Acrobat 6 from 2003).

This is also a chicken-and-the-egg scenario. Without broad-based browser support for the format, it won't get used by websites and service providers. It's a good format, with an existing, supported library, which has been stated to be easy to add to Firefox: >But with the new imglib design adding a new jpeg2000 component will be easy. It will be a drop in. It sounds like this will be easy money for anyone who steps up.

(In reply to comment #163) > >But with the new imglib design adding a new jpeg2000 component will be easy. It will be a drop in. > It sounds like this will be easy money for anyone who steps up. Unfortunately that comment is obsolete. Image decoders are no longer extensible. You will have to modify the source to add an image format.

And build option: ac_add_options --enable-jpeg2000 If I understand right, it can be dangerous to adopt OpenJPEG. While I was testing this module with some binaries, they often made it crushed. It seems to me that OpenJPEG can handle a clean Jpeg 2000 file without any problem, but what about malformed Jpeg 2000 images by malicious people on the web? Or am I missing something?

I investigated the available OpenSource solutions and found Jasper and OpenJPEG. I would vote for OpenJPEG as the library of choice, since it is a constantly maintained OpenSource project, not like Jasper, which had its last release years ago and didn't do any further development. I want to make that clear: Both libraries have to be "hardend", they are pure C, meant to be implemented in DigiCams and other closed systems. They are more coded for efficiency, standard fulfillment etc.. They both use stuff like "strlen" or the same evil: "memcpy" with no checked parameters (copy length 1 billion? Why not, sure.)! So it's not that easy, like "Just add lib and done". The libraries have to be polished too. Also JPEG2000 is much more calculation intensive, it would be highly advised to make use of the Firefox 4 hardware acceleration. Modern GPUs feature such enormous powers, which is till now mostly ignored by desktop apps. Therefore I think the offered price of $1000 is really good.

(In reply to comment #166) > They both use stuff like "strlen" ... I meant, of course, "strcpy". But I'm sure you get the idea. What I also saw: "strlen" result as parameter for memcpy. Brrr.... (shaking)

So, should I add "Add requisite patches to address security and stability" to the criteria, or does that go without being said? As for GPU support -- I'll happily accept a straight implementation of the feature. If it goes well, who knows, I pay sponsor another bounty for GPU support. Should I be altering the developers to this bounty in some other fashion? I'm a lurker on many OSS *-dev mailing lists, but don't know of any for Firefox.

(In reply to comment #168) > So, should I add "Add requisite patches to address security and stability" to > the criteria, or does that go without being said? Well... "without being sad"? Programmers have often enough sadly proven otherwise >-( I wouldn't even use strlen/cpy even for implementation targets like OpenJPEG. > Should I be altering the developers to this bounty in some other fashion? I'm > a lurker on many OSS *-dev mailing lists, but don't know of any for Firefox. No idea. I would suggest you post in one of the mozilla mailing lists and ask about details.

Modified most of client side problems I found. But I have no idea how to handle DoS caused by broken images.

Well... wouldn't it be better to negotiate with the OpenJPEG admins to push those changes back into their SVN? Plus: Did you pull the source code from the attachment for this bug entry or from the OpenJPEG repository?

(In reply to comment #155) > I'd like to see this implemented before December 31st, 2010. I'm a bit loathe to comment in this bug, but I just want to make sure expectations are realistic... * Firefox 4 is currently in feature freeze. There is no chance of jpeg2000 shipping as part of Firefox 4 -- we've already cut _planned_ features, so a contentious WONTFIX bug is way out of scope. The next release after that is unscheduled, but clearly would be well into 2011. * Reread Mike Shaver's comment 120, where he outlines some of the basic steps that would need to be done for such a patch to be considered. No, really, reread it now. I'll wait! * If someone's serious about getting jpeg2000 into Firefox, you'll need to figure out how to convince and work constructively with the Mozilla imagelib module owner (Joe Drew) and project drivers. Like it or not, they are the gatekeepers and you'll need to gain their support if you actually want this to ship. Patches are a great sign someone is serious about doing the work, but unwanted patches in a WONTFIX bug don't really do anyone much good. Of course, if your goal is just to produce a patch that you maintain for you own build / fork of the browser, then feel free to carry on in whatever way you see fit (though I would suggest this bug isn't an appropriate place for it).

(In reply to comment #173) > (In reply to comment #155) > > > I'd like to see this implemented before December 31st, 2010. > > I'm a bit loathe to comment in this bug, but I just want to make sure > expectations are realistic... > > * Firefox 4 is currently in feature freeze. There is no chance of jpeg2000 > shipping as part of Firefox 4 ... The next release after that is > unscheduled, ... well into 2011. Whoops, of course, you're right. I forgot to mention this as reply to comment 155. I didn't expected this for 4.0. But who cares, could be 4.0.1? Because the Firefox team decided just recently to add functionality also in minor patches (like in 3.6.x). > * Reread Mike Shaver's comment 120, where he outlines some of the basic steps > that would need to be done for such a patch to be considered. No, really, > reread it now. What exactly of that points hasn't been discussed in this thread at length? > * If someone's serious about getting jpeg2000 into Firefox, you'll need to > figure out how to convince and work constructively with the Mozilla imagelib > module owner (Joe Drew) and project drivers... > > Of course, if your goal is just to produce a patch that you maintain for you > own build / fork of the browser, then feel free to carry on in whatever way you > see fit (though I would suggest this bug isn't an appropriate place for it). I know it the other way (for Eclipse patches): Provide fully working patches. With Unit-Tests. Before that you have absolutely no chance, forget it. Don't even ask! Then convince the owners that this patch is worthy enough to be included into main. They tell you how most of your work is wrong. Fix everything according to their wishes and send it in again and again until they have no more complaints. The longer you work with them the better you understand their goals, the faster you get your stuff through. And that's (I think) a reason why the donor wants to work only with someone who has a long working relationship with the mozilla programmers. I see no problem there.

Incidentally, Adobe CS4 removed integrated support of jp2k. It was still available via a legacy plugin. More importantly, Adobe CS5 includes jp2k support standard, and it's a joy to use. I have 10 Hubble Space Telescope images at 29566 x 14321 resolution. Saved as bitmap files they're 11.8 GB total. Stored as jp2k-lossless files in Photoshop CS5, They're shrunk to 3.14 GB. Stored as PNG, they weigh in at 4.65 GB. We have not yet reached the typical hard drive size where 1.51 GB is a trifle. It'd be just swell to be able to use this as a portable format, instead of one only Photoshop can open. Then I could *send* files to people. Put them up on my websites and expect visitors to be able to view them. Why... imagine the possibilities. Glad to hear someone else is motivated to make this happen, albeit years later than it should have been done.

Updated the backend from v1.2 to v2.0x. Aside from ideological discussions, I think we need to talk about very slow codecs. For example, a 4000px-4000px image (jpeg or png or anything) freezes my PC for 0.5 sec or so. Then in case a html file has 10 <img> elements with such PNGs (and with ultra high speed network connection), a user can't push back button for a few seconds. Now imagelib's time scheduling is ruled only by network's input callback, but it's kinda problem. How about "Continue loading this image?" dialog, like JS's Maybe-Infinite-Looping dialog?

I too note that I am loathe to comment in this bug. (In reply to comment #174) > > * Firefox 4 is currently in feature freeze. There is no chance of jpeg2000 > > shipping as part of Firefox 4 ... The next release after that is > > unscheduled, ... well into 2011. > Whoops, of course, you're right. I forgot to mention this as reply to comment > 155. I didn't expected this for 4.0. But who cares, could be 4.0.1? Because > the Firefox team decided just recently to add functionality also in minor > patches (like in 3.6.x). Assuming you meant out-of-process plugins, they were backported not as desirable "functionality" but as a substantial stability improvement, of the sort branches are always open to considering (and accepting, if the gains outweigh the risks). The size and risk of the OOPP changes were highly unusual, but OOPP's overall gain in stability was also highly unusual (it cut crash counts by two-thirds, if memory serves). Whatever the merits and demerits of jp2k, I think we can agree that it cannot be considered a stability improvement that might be worth including in a 4.0.x release for that reason.

Sorry for the off-topic... Can someone please remove me from CC? (I tryied unsetting of "Add me to CC list" + "Save changes" for serveral time, but it won't work... :( ) Tnx!

I slightly modified the patch to make it compile with the latest 4.0b10pre code. I also enabled jp2k support by default, so gentoo users will be able to patch the ebuild through /etc/portage/env/ /etc/portage/env/net-libs/xulrunner post_src_unpack() { cd mozilla-* epatch "/etc/portage/env/www-client/j2k-4.diff" cd .. } /etc/portage/env/www-client/firefox post_src_unpack() { cd mozilla-* epatch "/etc/portage/env/www-client/j2k-4.diff" cd .. }

Please use compile-time symbols for code stability. /* check magic numbers */ if (mCodecFormat == CODEC_UNKNOWN) { enum LocalDefs { magicJ2K_LEN = 03, magicJP2_LEN = 014, magictype_LEN = 010 }; static const PRUint8 magicJ2K [+magicJ2K_LEN] = {0xFF, 0x4F, 0xFF}; static const PRUint8 magicJP2 [+magicJP2_LEN] = { 0x00, 0x00, 0x00, 0x0C, 0x6A, 0x50, 0x20, 0x20, 0x0D, 0x0A ,0x87, 0x0A}; // static const char magicJP2type [+magictype_LEN + 01] = "ftypjp2 "; static const char magicJP2type [+magictype_LEN] = { 'f', 't', 'y', 'p', 'j', 'p', '2', ' ' }; // static const char magicMJ2type [+magictype_LEN + 01] = "ftypmjp2"; if (mSize < 8) return; if (0 == memcmp(magicJ2K, mBuffer, +magicJ2K_LEN)) mCodecFormat = CODEC_J2K; else if (0 == memcmp(magicJP2, mBuffer, +magicJP2_LEN) && 0 == memcmp(magicJP2type, mBuffer + 16, +magictype_LEN)) mCodecFormat = CODEC_JP2; else return; }

Is there some official line from Mozilla why they block this? I mean JP2 is advanced to JPEG in any way (and here, compression factors are the least interesting part). And there are good libraries available, so Mozilla wouldn't have that much development efforts. The only remaining point is the patent issues, but thinking about H.264, Mozilla has already proved that they will threw away any good intentions with respect to patent issues if they just decide to. Not supporting JPEG2000 rows into a line of good formats that could actually get widespread use if some of the major browsers would support them, like MNG, APNG, etc. It's really a shame.

(In reply to Christoph Anton Mitterer from comment #181) > Is there some official line from Mozilla why they block this? Read the comment history? https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c98 is where its marked with the reason.

Yeah of course,.. but that comment is three years old an many things have happened in the meantime, as I noted the change in patent policy, etc. And in all doing respect, Joe's argument is a pretty bad one, cause quite obviously this comes down to the hen-egg-problem. Of course JP2 can't get that much widespread use when all the big players block it. An addon won't be of much use,.. because it means that there won't be general support, which again will lead to nobody start using it. Additionally you (Mozilla) do support stuff which hasn't that much widespread use; take APNG,.. [found out that only MNG/JNG is still unsupported]... and it's basically the same with every other new technology in its beginning, HTML5, SPDY, etc. He also mentions the time/effort needed: With libopenjpeg there seems to be a well maintained library available,... and even much smaller open source projects seem to easily manage linking to that library and using it. The thread surface is of course an argument, but I mean that way, one could never really add new features. That way you could have also blocked WebM (as you weirdly do with WebP). Moreover, e.g. libopenjpeg doesn't have a particularly bad security record. So I simply think it's time to re-evaluate these things unbiased... If there were support from the major browser manufacturer, then it's also quite possible, that big content providers like flickr or so might eventually get interested in.

(In reply to Christoph Anton Mitterer from comment #183) > widespread use; take APNG,.. [found out that only MNG/JNG is still > unsupported]... The answer is easy -- Mozilla used to support MNG, but the Mozilla guy called pavlov, the supervisor of the image/video support wanted to propose APNG (that he himself created and suggested) so he decided to remove MNG support to create a need for some animated image format. Read the history of the bugs <https://bugzilla.mozilla.org/show_bug.cgi?id=18574> and <https://bugzilla.mozilla.org/show_bug.cgi?id=195280> to see it ... He first tried to hide it behind space limitation, so the volunteers did all the work required -- to just see it was thrown away anyway ... I am afraid JNG is a similar case ... :-(

WebP is here now and not only does it have a better quality/compression ratio but it's implemented in Chrome, Opera and supported by a bunch of other software. See bug 600919. The status is currently set to WONTFIX but it doesn't mean that it can't be reopened. That's the one I'm moving my vote to. https://developers.google.com/speed/webp/

>WebP is here now and not only does it have a better quality/compression ratio Not disputing what you said but I'd like some hard numbers on this from a seemingly unbiased source. Furthermore, JPEG2K is a frozen ISO standard, unlike WebP that's still in development. One should also take existing authoring tool support (that's in favor of JPEG2K). If the reasons for considering WebP and not JPEG2K are license/patent based or based on incentives offered from GOOG then that should be made clear, because discounting those issues, one would be hard pressed to go with WebP.

It would seem that the single reason for not implementing either is that they aren't used much, which isn't helped by the fact that they aren't implemented. In other words, the only way Mozilla will implement this is to catch up with Chrome, if Chrome's adoption alone will be enough to make these files start appearing online (which is looking doubtful at the moment). Yet another way to phrase is is that we'll continue to be stuck with ancient formats because we're currently stuck with ancient formats. Yeah, go figure.

(In reply to Roman from comment #187) > Yet another way to phrase is is that we'll continue to be stuck with ancient > formats because we're currently stuck with ancient formats. Yeah, go figure. Most users do not complain about JPEG/GIF/PNG/BMP. If only a few people started using J2K on their websites, they would scatter unhappiness to rest of the people on web. JFYI, pdf.js has (feature limited) jpeg 2000 decoder, which is of course implemented in JavaScript. https://mxr.mozilla.org/mozilla-central/source/browser/extensions/pdfjs/content/build/pdf.js#32348 https://async5.org/moz/jpx2/jpx.js And demo to convert from jpeg2000 to PNG on HTML <canvas>. https://async5.org/moz/jpx2/ We should make the discussion a little clearer. 1. imglib should implement jp2k decoder or not. This would make rendering PDF faster/more beautiful, especially those with some graphic composed with Adobe Acrobat. In other words, that's all. 2. HTML <img> element should accept "img/j2k" etc. format or not. This is very dangerous. Mozilla might get involved in format war. There's [parity-safari] tag on this bug's white board, while [parity-chrome] on WebP's !

Here are my 2cts on this issue: I do not believe there is any need at this time (Apr 2013) to implement JPEG 2000 support in browser. JPEG 2000 adoption has gained only three grounds AFAIK: - Dissemination of cultural heritage, - Satellite images - Digital Cinema Initiatives Let's look at typical size of images in each of those fields: $ wget https://chroniclingamerica.loc.gov/lccn/sn82016455/1882-03-07/ed-1/seq-2.jp2 $ identify seq-2.jp2 seq-2.jp2 JP2 5132x6928 5132x6928+0+0 8-bit DirectClass 4.446MB 24.490u 0:25.239 and $ wget https://geology.utah.gov/databases/coalminedata/43_007_326a.jp2 $ identify 43_007_326a.jp2 43_007_326a.jp2 JP2 10549x6539 10549x6539+0+0 8-bit DirectClass 8.017MB 17.980u 0:18.250 I do not have any DCI sample, but the idea is that each frame of the movie is a full frame JPEG 2000, so you get the /picture/. What I am trying to say, is that JPEG 2000 simply cannot be compared to other PNG/JPG/WebP codec IMHO. The aim is clearly different. So until the specification for <img/> allow something smarter, or that <media/> is extended to support something close to JPIP, Internet Imaging Protocol and/or DeepZoom protocol, then it will be a bad idea to implement a half-broken feature in browser. As some people mention in this thread, if we focus on user base, then JPEG 2000 is clearly meant for very large images, it is meant for 'out-of-core' images (bigger than any screen you ever dream of!). So in this case any browser implementation will not be able to fulfill user expectation, given that <img/> element simply expect a browser to download the whole image (well you are allowed some minor optimization in the case of progressive JPEG). But the point remains that you still have to download the whole file anyway. See also the following thread for more info on that matter: https://stackoverflow.com/questions/15678475/html-and-displaying-of-img-element So until WHATWG propose something smarter for this kind of images, open source implementations will be a lot better, and security issues will be long gone.

Mathieu - (In reply to mathieu from comment #189) I'm one of the 'cultural heritage' sector that's using large JPEG 2000s for archival and dissemination purposes. I understand your argument about not wanting to download an entire JPEG2000 for viewing in the browser, but does the specification specifically say that a browser *must* download the entirity of a file given an <img> tag? You say: > <img/> element simply expect a browser to download the whole image > (well you are allowed some minor optimization in the case of progressive > JPEG). But the point remains that you still have to download the whole file > anyway. Wouldn't this just be up to the browser? Could it not be implemented in that if the img filename is ~=*.jp2 (for example) then you could use a HTTP GET Range: to download the JP2 header and then if the img tag had width & height attributes you could just download the bits of the file that you need to render that (as is done with only reading parts of the file from disk with jp2 image libraries)? This is only a suggestion, and I'm very ready to be educated as to why this wouldn't work, or would break standards. I realise that the implementation wouldn't be easy, as you'd have to interact between the HTTP requests and the JPEG2000 library implementation, rather than just handing it the file to render.

(In reply to mathieu from comment #189) > As some people mention in this thread, if we focus on user base, then JPEG > 2000 is clearly meant for very large images, it is meant for 'out-of-core' > images (bigger than any screen you ever dream of!). I don't think so - it might just be that that's what it's *currently* being used for. It seems JPEG2000 is currently used only be those who have to use it (due to size or quality requirements) and are willing to suffer the lack of widespread support, but I presume others would start using it if there was better support. I for one would gladly switch to JPEG2000 for average-sized photographs if it was supported by a significant fraction of the installed browser base.

> Could it not be implemented in that if the img filename is ~=*.jp2 (for > example) then you could use a HTTP GET Range: to download the JP2 header and > then if the img tag had width & height attributes you could just download > the bits of the file that you need to render that (as is done with only > reading parts of the file from disk with jp2 image libraries)? > > This is only a suggestion, and I'm very ready to be educated as to why this > wouldn't work, or would break standards. I realise that the implementation > wouldn't be easy, as you'd have to interact between the HTTP requests and > the JPEG2000 library implementation, rather than just handing it the file to > render. There's no way I'm aware of in HTML to specify the client wants only a portion of an image. Conceivably, it might be doable with some server-side help, with server specific URLs such as: example.jp2?x=30;y=30;height=200;width=200 The JPEG2000 format might make getting a specific 200 pixel square easier than with some other format, but all the work of extracting the 200 pixel square would have to be done server side, just as it would with any other image format, so it isn't a client issue. Possibly a standardized way of making such a request could be added to the HTML standard, but even if WHATWG could be convinced to do that, I'd be highly doubtful it would be done in a manner that would be able to fully take advantage of JPEG2000's abilities there since it would likely require tailoring the spec specifically for JPEG2000 and that simply won't happen. For those users who want to take advantage of JPEG2000's capabilities beyond better image compression of whole images, a plugin is probably the only realistic way of that ever happening. In summary, the only feature of JPEG2000 that a browser could be expected to take advantage of is the improved compression of whole images.

(In reply to Ernest Cline from comment #192) > There's no way I'm aware of in HTML to specify the client wants only a > portion of an image. Conceivably, it might be doable with some server-side > help, with server specific URLs such as: > example.jp2?x=30;y=30;height=200;width=200 I believe the suggestion was not to specify which part of the image is required (or at what resolution), but to do all the work required to retrieve only those parts client-side. One could do that without requesting the whole image file by issuing range requests the same way a local image decoder might read only specific parts of the file. This way no special support is required in the protocol or on the server. The only problem I see with this is the latency: one might require quite a few roundtrips to figure out which parts to retrieve. I wouldn't be surprised if it takes just two or three roundtrips. This would be a great way to support images at multiple resolutions, which has been a bit of a sore topic for quite a while. JPEG2000 + a smart client doing range requests could have been the answer to that, had it been supported.

NB the following extract from https://www.jpeg.org/jpeg2000/j2kpart9.html concerning Part 9 of JPEG 2000 (ISO/IEC 15444-9) a.k.a. JPIP: "Part 9 also defines some new file format boxes for indexing JPEG 2000 files and codestreams. The indexes are based on the same concepts as the JPIP stream types, and may be useful in server implementations of JPIP. They are also intended, however, to enable random access to JPEG 2000 files in the absence of JPIP. For example, the byte-range requests built into an unmodified HTTP (version 1.1) server could be used for this purpose." (Full disclosure: I was a co-editor of this Part, helped to draft the Annex concerned and probably the above text.)

I'm not sure the inability to support some advanced use case (controllable partial download) is a good reason for not supporting a baseline experience. We don't have built-in colour profile management, but we still support colour profile. We support @page, but not page-break-before/after. IE supported innerHTML, just not for table and select (and stayed that way even in IE 9). These basic supports are all useful. Apart from the size advantage, jpeg 2000 also has the advantage of being a lossy formats that support alpha. But if WebP, JPEG-HD and pdf is any proof, size saving is a big enough reason for basic support. Which is sad, because IMHO if Firefox had supported J2K when we had higher market share, may be the market won't be so fragemented today. As it stands, Firefow would need to implemeting J2K just to catch up with IE and Chrome in term of next-gen image support.

Any updates?

I see there is a library called OpenJPEG (https://www.openjpeg.org) that has BSD license, that is capable to decode JPEG 2000 files. Is there any chance to include a plug-in in FireFox to decode JPEG 2000 files using this library?