Intent to implement: JPEG-XR support

[ChangSeok Oh]

Contact emails

shiva...@gmail.com, changs...@collabora.com

Spec

I'm not sure if there is a web spec defining new image formats like jpeg-xr or webp.

Instead here are some relevant links regarding jpeg xr.

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=56465

https://html.spec.whatwg.org/multipage/embedded-content.html#embedded-content

http://www.w3.org/2008/WebVideo/Fragments/wiki/State_of_the_Art/Codecs#Image_Coding_Formats

Summary

I'm liked to extend the ImageDecoder module to support JPEG-XR. My approach will be very similar with what other implementations for jpeg, png, and webp do.

Motivation

- JPEG XR is an open image standard.

- It gives web developers benefits of better compression, support for high bit depths, alpha channels, lossless and so on. [1][2]

- IE has supported the formated since its version 9. And Firefox restarted to discuss it. [https://bugzilla.mozilla.org/show_bug.cgi?id=500500] since the license issue of the format has been solved (BSD licensed.)

- I don't want to compare or argue which format is better. But I think giving more options for web image format that web developers can choose is just good. =)

Compatibility Risk

Low. IE has supported the format. And Firefox reopened a ticket to discuss jpeg-xr support since its license changed to BSD.

IE : Supported since IE9

FF : https://bugzilla.mozilla.org/show_bug.cgi?id=500500

Safari : Opened a ticket but no active discussion yet, I'll propose it to WebKit community as well. (https://bugs.webkit.org/show_bug.cgi?id=49889)

Web developer : Positive as I see in https://code.google.com/p/chromium/issues/detail?id=56908

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=56908

Link to entry on the feature dashboard

I have no authority to create a new entry(but filled a relevant form and sent it) so I can't point out a link for the feature dashboard for now.

Requesting approval to ship?

No

[1] https://hdview.wordpress.com/2013/05/30/jpegxr-updates

[2] http://en.wikipedia.org/wiki/JPEG_XR#Description

ChangSeok

[PhistucK]

​Where is the link to the codec specification?

The ISO link costs nearly 200​ US dollars to purchase and view.

Do you intend to implement the codec yourself, or use a third party library (which?)?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[ChangSeok Oh]

> Where is the link to the codec specification?

My bad. You can find an alternative pdf here. http://www.itu.int/rec/T-REC-T.832-201201-I/en

> Do you intend to implement the codec yourself, or use a third party library (which?)?

I'll use jxrlib which is open code. you can find it in https://jxrlib.codeplex.com.
Currently I'm using a debian system so I could installed the package by apt-get install libjxr-dev. https://packages.debian.org/jessie/libjxr-dev

ChangSeok

[Anselm Hannemann]

May I ask why you want to implement JPEG-XR support over MozJPEG? According to this article mozjpeg produces better results and is based on a truly free standard that isn’t an issue for any browser vendor (including Firefox)?

I’m just curious, if it isn’t appropriate to ask here, let me know or feel free to ignore this comment.

[PhistucK]

Unless I am misinformed here, MozJPEG is not a codec or format, but a library that encodes regular JPEG, only quicker and produces a smaller file, but it is still just a regular JPEG.

JPEG-XR is a totally different codec which is incompatible with JPEG (perhaps JPEG-XR decoders can read JPEG, but not the opposite).

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Peter Kasting]

As one of the image decoder owners, I doubt we would accept this.  We have in the past explicitly decided not to support various other image formats such as JPEG2000 and APNG.  There is both a binary size and security surface cost to image decoders, and when their relevant formats are not prevalent on the web it is often (though not always) not worth the tradeoff to implement them.

Accordingly, you should not proceed with implementation unless you get positive responses from the platform leads as well as security folks.

If you want to improve the chances of this being supported, posting specific numbers for JPEG-XR's use on the web, as well as code size (both binary and LOC) footprint for the decoder, would be useful.

Now, regarding various things you cite.

First, I think the level of Firefox interest is lower than you portray.  The bug in question was never closed (so it can't have been reopened), and comment 13 there notes that other factors besides the license are larger issues.  The lone possibly-positive comment from someone whose opinion I know matters, comment 24, simply says that they'll look into things, and was posted almost two years ago.  It seems clear Mozilla doesn't have much interest in this.

Regarding the level of web developer support for this, citing a Chromium bug with 41 stars is not terribly convincing.  Bugs in our bug tracker, like bugs elsewhere, are not unbiased samples of developer opinion -- they tend to become honeypots for people to glom onto regardless of the merit of their arguments or the actual relevance they have to the web development community.  I've seen very little demand for JPEG-XR on the web to date; honestly, if we were going to add another image format beyond what we currently support, I think APNG would be of more wide interest.  And even if the bug tracker were representative, 41 stars would be a very low number.

I'll leave further followup to the platform leads.

PK

[ChangSeok Oh]

Hi Peter.

Thank you for sharing your thought. But I have a slightly different view from yours unfortunately.
IMHO, how many usage for a new tech or format could not be a sensible reason, not to support it. On the contrary low usage of any kind new format sounds very natural to me.

Especially new image formats for web are really such things. You seems to think supporting JPEG-XR is not meaningful because of its low usages for web though, I think its low usage is due to poor browser support from browser vendors. This sounds quite similar with what comes first, chicken or egg, but it's true.

Many new image formats like (APNG, WebP, JPEG-XR etc) has been introduced in industry and they insist their own advantages compared with other formats.
But most of web developers still prefer using gif, jpg, png. This situation is not much different from 10 years ago's.
Why? I think the main reason is compatibility. I don't think they don't know new image format came out or its benefit. Just compatibility among browsers is the matter.
In this context, I don't think counting jpeg-xr usage for web won't give us meaningful data.

If we decide whether to support any kind of technology or not with usages, we can't go forward even a single step. Because new html5 features (even including WebP) could not be exceptional.

Regarding Firefox. The ticket was closed once at 2011-10-07 and then reopened to discuss continually. You can see it in its history or comment 19.

I don't know why you think Firefox community is not interested in supporting jpeg-xr.
1) At least the ticket is still open(indeed reopen).
2) Some positive movement happened (comment 31, 33 and 34).
3) And a good feedback appears from Mozilla community (comment 35. This is the last comment posted just few month ago).
All these make me feel they want to go forward to add jpeg-xr support. 

Best regards.

 

ChangSeok

[Jochen Eisinger]

Hey,

thanks for your interest in contributing to blink.

For the reasons Peter cited, we will not accept patches for jpeg-xr support into trunk at this time.

If you want to move forward with this, I would encourage you to develop the changes on a branch and work on addressing the points Peter mentioned, esp. demonstrating that the format is technically superior, documenting broad support in the web developer community, as well as making sure that the codec doesn't crash with a reasonable fuzzer hammering on it.

best

-jochen

[Boris Zbarsky]

On 1/14/15 5:48 AM, ChangSeok Oh wrote:
> 2) Some positive movement happened (comment 31, 33 and 34).
> 3) And a good feedback appears from Mozilla community (comment 35. This
> is the last comment posted just few month ago).
> All these make me feel they want to go forward to add jpeg-xr support.

My suggestion would be that instead of trying to read the tea leaves you
just ask Seth (the image library module owner) directly what the plan
here is on Mozilla's side. See
https://wiki.mozilla.org/Modules/Core#ImageLib for contact info.

-Boris

[Noel Gordon]

As another image decoding owner, it seems to me that

> Web developer : Positive as I see in https://code.google.com/p/chromium/issues/detail?id=56908

no one in the WebKit community has provided a positive signal on that bug. 

> Requesting approval to ship?

> No

> [1] https://hdview.wordpress.com/2013/05/30/jpegxr-updates

I found that reference in a webp mailing list discussion [2], where it was noted that jpeg-xr suffers from ringing artifacts (mosquito noise).

[2] https://groups.google.com/a/webmproject.org/forum/#!topic/webp-discuss/7amtdOl-1Yo

At a more recent comparison site, I looked at Colonge Catherdral in jpeg-xr and webp:

http://xooyoozoo.github.io/yolo-octo-bugfixes/#cologne-cathedral&jxr=s&webp=s

The ringing artifacts are clearly visible to me around the cathedral towers and the bridge arch in that example. More modern encoders seem to control that type of noise very well.

So apart from the issues already mentioned, there's the quality issue - there things get hard (of course) to provide convincing arguments that some image format X, for any format X, provides superior quality to whatever has gone before. For X=jpeg-xr, it seems that modern encoders have progressed much further in terms of the quality.

~noel

[jrmu...@gmail.com]

I've clarified the current feeling at Mozilla on JPEG-XR on the bug you mentioned. Last time we looked at JPEG-XR it's compression performance was worse than JPEG (https://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/)

In fact it's pretty easy to confirm this for yourself using this comparison site especially if you set the image size to large which is the typical bitrate of jpeg images on the web.
http://xooyoozoo.github.io/yolo-octo-bugfixes/#cologne-cathedral&jxr=s&webp=s

-Jeff

[jos...@gmail.com]

Link to newer study, the one Jeff linked to is old.

https://people.mozilla.org/~josh/lossy_compressed_image_study_july_2014/

I'm not the module owner, but so far as I know Mozilla currently has no plans to add support for JPEG XR.

-Josh

[ChangSeok Oh]

O.K. It seems that blink community made a consensus on not to support jpeg-xr near future.

It's still a little bit doubtful if the decision is all about technology and a superiority or perfection of any technology is really a matter to adopt or not to adopt it.
Latest technology used to be better than old one(yeah.. not always) and arising new one will never stop. so I think this kind of argument will also never stop.

TBH, I read many articles about WebP vs JPEG-XR and other camparisons among modern image formats before staring this work. I know a lot of debates among them already happended.
But that sounds not constructive to me. I thought giving many options to web developer was just good. That is why I wanted to avoid technical debates.

Anyway I respect the community's decision. Here I lay down my works regarding jpeg-xr.

Thank you for all those who replied in this thread. I could learn many things. =)

Best regards.

ChangSeok

ChangSeok

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike Lawther]

Hi ChangSeok,

> Anyway I respect the community's decision. Here I lay down my works regarding jpeg-xr.

> Thank you for all those who replied in this thread. I could learn many things. =)

Thank you for accepting this gracefully. In return, I'd like to try and answer a point you had:

> I thought giving many options to web developer was just good. That is why I wanted to avoid technical debates.

It's a good general principle, but web developers are not the only folks we as browser vendors worry about. We also have to consider the cost and benefit to our end users of providing such a choice. This means things like extra binary size to download and store, and extra memory use, as well as ensuring the implementation is secure. For something like a new image codec, the benefits should include lower bandwidth requirements, meaning reduced latency and cost to the user. 

The backwards compatible nature of the web also means that once we support a new feature, it is very hard to later remove it. So even if only 0.005% of websites use a feature, the vast majority of users are still paying the binary and possible security costs of an unused feature.

This is why it's not as simple as 'more choice is always better' - it's a tradeoff, and technical reasons are required. 

    mike