[webkit-gtk] JPEG-XR support in WebKItGTK+
changseok.oh at collabora.com
Tue Mar 31 23:24:39 PDT 2015
I recently worked on bringing jpeg-xr image format to WebKitGTK+ and just started to submit a patch set for it. 
But Martin raised a strong concern on supporting new image format so that we need to discuss on whether or not to accept the new image format into webkit before going forward.
According to my previous thread in webkit-dev . apple guys look like they don’t care about adding new image format if it’s supported by linking external libraries and they deferred to each port maintainers. So I think it’s enough that deciding the support of jxr in WebKitGTK+ community.
The jpeg-xr image format was patented by Microsoft before, but now the license issue is solved after jpeg-xr became a web image standard. 
MS published jxrlib which is a library decoding/encoding jxr formatted image under BSD-like license.
Actually you can install it by apt-get install libjxr-dev if you’re using debian based systems. Anyhow no more license issue as long as I know.
Nothing special on this. I could see some end users wanted the format for their use  and a blank hole in html5test.com <http://html5test.com/> even though jxr is an image standard.
I thought how popular is not important for web image format candidates because choosing universally supported image format like jpeg, gif and png is quite natural in web rather than choosing non-universally supported one. At least IE (which is the top used browser yet, still takes 50% around market share) has supported it so we can improve compatibility issue and performance by reducing image size if we adopt the jpeg-xr.
I don’t have much info of the use case though, jpeg-xr is competitive in some area. It shows reasonable quality in low resolution(=in small file size), so it’s useful in mobile game field as I heard.
1. We already have WebP. Do we need to support other image format?
We had png, but it does not mean we can drop jpg support. We had apng, but we can’t drop gif support.
In same manner, I think supporting any other format could not be a reason to reject jxr support.
2. Is there any advance from WebP?
This is pretty debatable topic. You can see a lot of discussions happened regarding this if you google ‘jpeg-xr v.s webp’ like that.
I think extending the argument here is not productive. jpeg-xr has its own advances so I think supporting webp is out of consideration to adopt jpeg-xr.
3. Chromium and mozilla rejected jpeg-xr support.
Yeah I know. I’m the guy proposing jpeg-xr support to blink. I can understand their stance since webp is owned by google and they're driving webp as a next modern image standard. But is there any reason for WebKit to follow google’s stance? Especially for WebKitGTK+, we support WebP, but it’s not supported by Gecko nor IE. We supports apng, but it’s not supported by Chromium nor IE. In same manner, there is no reason not to support jpeg-xr I think.
4. How popular is it in web?
I have not much information on this. (Maybe flickr, tumblr, adobe flash player? I’m not sure) But this question is something similar to the question, what comes first, chicken or egg..
jpeg-xr can’t spread out in the world because of browser compatibility. That’s what content author complain about both webp and jpeg-xr.
For the reason, I think measuring the popularity of new image format is meaningless. Personally I don’t think how chromium could adopt webp is not because of its popularity in the web.
 https://bugs.webkit.org/show_bug.cgi?id=143265 <https://bugs.webkit.org/show_bug.cgi?id=143265>
 https://lists.webkit.org/pipermail/webkit-dev/2015-March/027325.html <https://lists.webkit.org/pipermail/webkit-dev/2015-March/027325.html>
 http://en.wikipedia.org/wiki/JPEG_XR#Licensing <http://en.wikipedia.org/wiki/JPEG_XR#Licensing>
 http://www.itu.int/rec/T-REC-T.832 <http://www.itu.int/rec/T-REC-T.832>
 https://code.google.com/p/chromium/issues/detail?id=56908#c17 <https://code.google.com/p/chromium/issues/detail?id=56908#c17>
 http://blog.kaourantin.net/?p=116 <http://blog.kaourantin.net/?p=116>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-gtk