[webkit-gtk] JPEG-XR support in WebKItGTK+

[Carlos Garcia Campos]

El mié, 01-04-2015 a las 15:24 +0900, ChangSeok Oh escribió:
[...]
> 
> FAQ
> 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.

I agree, the fact that we support other formats is not a reason not to
support new ones.

> 
> 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.

It doesn't matter which format is better or worse, what matters to us is
the compatibility. We need to support whatever the web sites use.

> 
> 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. 

I see this as an advantage, TBH. Supporting things other don't, makes us
stronger :-)

> 
> 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.

This is the key point in my opinion. Adding more code to support
something nobody is using ... It also depends how easy to maintain the
code is. I mean, if most of the work is done by the external library and
we only need a few lines of code to support that (and it's optional
dep), it would make sense. Unfortunately that's not the case of all
other image formats, even if we use libjpeg, libpng, etc., the glue code
to use that in WebKit is a lot, and not trivial code.

Another negative point I see, is that the external library is not
adopted by distros, and it seems upstream support sucks (no serious
build system, no public repo nor download link, etc.)

> 
> BR.
> 
> 
> [1] https://bugs.webkit.org/show_bug.cgi?id=143265
> [2] https://lists.webkit.org/pipermail/webkit-dev/2015-March/027325.html
> [3] http://en.wikipedia.org/wiki/JPEG_XR#Licensing
> [4] http://www.itu.int/rec/T-REC-T.832
> [5] https://code.google.com/p/chromium/issues/detail?id=56908#c17
> [6] http://blog.kaourantin.net/?p=116
> 
> ChangSeok
> 
> 
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-gtk

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20150401/a4cc5235/attachment.sig>