Add JPEG XR support
Reported by sky...@gmail.com, Sep 25 2010
JPEG XR is an image format created by Microsoft and standardised by JPEG. It is already supported in IE9 and its support could probably be added to Chromium as well.
Sep 30 2010,
It well be cool that supporting more color accuracy and High Dynamic Range (HDR) imaging format---Jpeg XR instead of supporting WebP which does not support HDR and wide color space.
Oct 1 2010,
It would be great to support JPEG XR. No need for WebP, we have something great as an open standard, why don't embrace it?
Oct 3 2010,
Issue 57728 has been merged into this issue.
Oct 3 2010,
Oct 4 2010,
Nov 21 2010,
IE9 will be adopted by large numbers of people, it's a given. It would be really exciting for the web if Chrome could be JPEG XR capable too. If I can serve up JPEG XR files to capable clients it's going to make things faster and better. It's exciting to see the Mstone-X label appear!
Dec 12 2010,
Seconding comment 6 It would be great to see more adoption of Jpeg-XR on the web. It would be great to see websites like Google Image search, Google maps and flickr to serve up Jpeg-XR images to supporting browser clients. I know Google has it's own image standard it's trying to see adopted, but Jpeg-XR already has many of the advantages that they are trying to implement with WebP and more. On top of that it's already an ISO standard. Ideally I'd like to see both formats supported by most browsers and give website developers and users the choice to see which they prefer. Would seem like a win win for everyone.
Dec 30 2010,
I'm not quite sure what the point being made in the link at comment 8 is exactly. the message linked quotes: "A quick skim of mozilla's bug on the subject: https://bugzilla.mozilla.org/show_bug.cgi?id=500500 leads me to believe there is currently no patent-safe way to use JPEG-XR." Firstly the bugzilla thread makes no reference to patents. Microsoft have included Jpeg-XR under their community promise, which is a legal promise not to sue anyone for using their patents to implement the Jpeg-XR standard. They can not promise other companies owning patents will not attempt to sue should they feel they have patents used in Jpeg-XR. The only restriction is on the reference code Microsoft released for Jpeg-XR, which only allows you to use the code if you use it to read/create images conforming to the Jpeg-XR spec. This makes the code non-GPL compliant. But there is nothing stopping anyone from writing a Jpeg-XR library from scratch. as many people have.
Jan 12 2011,
JPEG worked perfect. We don't need WebP.
Jan 12 2011,
FWIW, an approach to this that might avoid the typical patent fusses over new formats is to use whatever libraries the system provides, and advertise which formats Chrome can accept. Mac OS and my Ubuntu installation decode JPEG 2000 and Windows decodes JPEG XR. If the powers that be deem that using an OS library isn't enough separation to prevent patent-related liability, maybe it would do for Chrome to make it easy for users to install third-party decoders. (I'm not endorsing format fussing, just looking for ways to deal given that Google, Apple, and Microsoft all engage in it.)
May 13 2011,
Mar 29 2012,
Add JPEG-XR to Chrome! +1
Mar 10 2013,
Apr 6 2013,
Apr 15 2013,
for anyone interested in investigating this feature, Microsoft just recently released a BSD licenced, optimised open source library for Jpeg-XR: https://jxrlib.codeplex.com/ Blog post: http://hdview.wordpress.com/2013/04/11/jpegxr-photoshop-plugin-and-source-code/
Apr 17 2013,
Please add JPEG XR Support to Chrome. Recently, I was able to compress a flowers background image of mine down to 60KB in JPEG XR with *reasonable* quality but that same image seemed to take about 120KB with standard JPEG compression. That's a bandwidth savings of 50%!!! I know no one in the developed world still uses modems, but if a modem gets 56 Kbps (bits per second), then it should get 56/8 = 7 KBps (Bytes per second). This means if someone visits my webpage with a 56 Kbps modem, then they will have to sit around twiddling their thumbs for 120KB / 7 KBps = 17 seconds before the above mentioned background image was downloaded. I understand that the HTML standard *probably* specifies that background images are downloaded *after* primary content, but this would still be really annoying to a visitor that simply wanted to see a plain text blog entry.
Apr 23 2013,
I need to point out that this differences between JPEG and JPEG XR on compression and image quality seem to vary. Sometimes JPEG XR seems in Paint.NET seems to do much better for me and sometimes it only seems to do marginally better. So the results are a bit mixed.
Apr 24 2013,
Just look how sticking to standards improved WEB. JPEG XR is a <strong>standard<strong>. It is also more universal. IMHO it should be the next choice for image encoding @WWW.
Jan 16 2014,
Please add support for JPEGXR in chrome....
Mar 10 2014,
JPEG 2000 > JPEG XR, because it wasn't made by Microsoft. Let's not turn Chromium project into some IE wannabe, please, and instead focus on the naturally born standards.
Dec 19 2014,
I think adding JPEG XR support is enough valuable. It is a web image standard and giving users many options to choose is important for open web. I just started adding jpeg-xr support to blink. If I'm ready. I'll open it to all.
Dec 19 2014,
That would be awesome. Thank You.
Jan 13 2015,
I'm ready to contribute my code for chromium. I has been working on the jpeg-xr support for linux system(Ubuntu 14.10). But I think expending the support to other plaforms is not that difficult. Here is my brief plan. 1. Add a jxr dependency to chromium repo. 2. Add a decoder for jxr. 3. Add a encoder for jxr. 4. Extend the jxr support to other platforms like mac, win, android and chrome os. 5. bug fix if any.
Jan 13 2015,
Can't wait to see it in work. Once Chrome and IE has the JPEG XR support, things might start changing. Thank You.
Jan 14 2015,
Per discussion on the blink-dev list, we won't be adding support for JPEG-XR. As noted on https://bugzilla.mozilla.org/show_bug.cgi?id=500500#c36 , Mozilla feels that JPEG-XR is worse than JPEG from a compression standpoint and thus unlikely to be worth adding. Similarly, some of the Blink owners noted problems with particular testcases, which they felt demonstrated that JPEG-XR's compression quality was disappointing. From a web developer standpoint, JPEG-XR seems not to be widely used, and there's been comparatively less demand for it across the web than for various other sometimes-contentious formats, e.g. WebP or APNG. Finally, image decoders not only incur the binary/code size overhead that any added feature does, but they are particularly sensitive from a security perspective. Any decoder we add needs to be thoroughly audited and fuzzed from a security perspective. We would consider reopening this bug if the following happened: * The patch to add support was of reasonably small size and had been significantly fuzzed and audited already. * JPEG-XR was shown to be in high demand among web developers, or at least demonstrated convincingly superior performance to other alternatives in terms of compression and features (the biggest such competitor here would probably be WebP).
Jan 15 2015,
As pkasting said, blink community reached a consensus not to accept JPEG-XR support near future. So I lay down my work unfortunately. But for those who are still interested in working jpeg-xr in chromium, I leave my working branch which implemented jxr decoder for blink. http://cgit.collabora.com/git/user/kevino/Blink.git/commit/?h=jxr-support&id=2ac58312a5aae502aacc1c55c0bfdff767ab82a2 Thanks
Jan 15 2015,
@pkasting I think BPG will be the competitor killer in that case. http://xooyoozoo.github.io/yolo-octo-bugfixes/#vintage-car&jpg=s&bpg=s
Jan 15 2015,
@shivamidow #28 - Thank you for raising the issue on blink-dev@ and for your code contributions. Such contribitions are valuable: you did work and wrote good code, which is more than most people do when requesting feature additions to Chrome. I appreciate the effort and time you've taken to explore this issue. If you are looking to contribute to Chrome, please do not let this issue discourage you.
Jan 16 2015,
@noel I'm not discouraged at all. This kind of situation used to happen in open source communities. Right? I already started looking for next stuff for blink and chromium. =) Thank you for your warm comment!
This will obviously be ignored, but I've been waiting for years for JPEG-XR support in FireFox and Chrome and it still isn't here. This is annoying. JPEG-XR is one of the few image formats that offers superior compression, transparency, metadata with and option of lossless compression. PNG is really good for transparency and lossless compression I think but I don't think it supports metadata. I'm just a hobbyist and I don't understand DRM and things like that very well so meta data is the only weak way I know of how to embed my copyright into my images. Yes, I know anybody can delete the metadata but I'm a bit leery of things like "invisible" watermarks. Please support JPEG-XR, I don't think JPEG 2000 is well supported either so it would help if you all would go for JPEG-XR.
@util It's now very obvious that WebP has won the next-generation image format war, as Microsoft already supports WebP and Mozilla has announced their intent to support it. https://winbuzzer.com/2018/10/08/microsoft-edge-now-supports-googles-webp-mozilla-promises-adoption-in-2019-xcxwbn/ https://www.cnet.com/news/firefox-to-support-googles-webp-image-format-for-a-faster-web/ If anything should be added, that would be AVIF rather than JPEG XR.
Sign in to add a comment