Re: [webkit-dev] JPEG XL support?

[Sam Sneddon via webkit-dev]

> I don't have any strong opinion on JPEG XL, asides from the general 
> observation that adding more image decoders written in memory-unsafe 
> languages is a generally sad thing to do. (I'm still not happy about how we 
> were forced to support JPEG 2000 a couple years back due to websites using 
> Akamai Image Manager.) In particular, I notice that libjxl is quite a lot of 
> C++ code. On the other hand, given that WebKit is itself all C++, you could 
> reasonably say something about "people in glass houses should not throw 
> stones." :) So even though image decoders are quite sensitive, that shouldn't 
> be a blocker IMO.
> 
> The most important point you need to know is that Safari doesn't use WebKit's 
> image decoders at all, so if you want JPEG XL to work in Safari, contributing 
> JPEG XL support to WebKit is not likely going to achieve your goal. Even if 
> Safari did use our image decoders, which it doesn't, we don't copy 
> third-party projects into the WebKit source without a *very* exceptional 
> reason to do so (as for ANGLE or libwebrtc), so OS support for JPEG XL is 
> going to be key. There are two cases:
> 
> (1) Non-Apple platforms use image decoders under 
> Source/WebCore/platform/image-decoders. Depending on libjxl if it is 
> installed as a system library, and using it to implement a JPEG XL image 
> decoder under Source/WebCore/platform/images-decoders/jpegxl, seems OK to me. 
> (Whereas copying libjxl into the WebKit source repo would certainly not be 
> OK. That's way too much code.) There would need to be a CMake build option to 
> disable the dependency for systems where libjxl is not available as a system 
> library. It would only make sense to do this if somebody makes an effort to 
> package libjxl for at least a few major Linux distros, otherwise it won't be 
> used in practice. PlayStation and Windows ports can then build libjxl 
> themselves if they so choose.
> 
> (2) Apple platforms use CoreGraphics for image decoding, see 
> Source/WebCore/platform/graphics/cg/ImageDecoderCG.[cpp,h]. I don't know much 
> about this, but I don't think it's open source, so I would guess that 
> contributions are probably not possible. I'm not sure what to tell you here. 
> Hopefully somebody from Apple will comment.

This is pretty much accurate as far as the Apple port is concerned; image 
format support depends on OS library support, rather than anything in WebKit. 
And indeed, the relevant OS libraries aren’t open source. And to be clear, 
Apple’s OSes do not currently support JPEG XL.

/Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] JPEG XL support?

[Michael Catanzaro via webkit-dev]

Hi Sami,

I don't have any strong opinion on JPEG XL, asides from the general 
observation that adding more image decoders written in memory-unsafe 
languages is a generally sad thing to do. (I'm still not happy about 
how we were forced to support JPEG 2000 a couple years back due to 
websites using Akamai Image Manager.) In particular, I notice that 
libjxl is quite a lot of C++ code. On the other hand, given that WebKit 
is itself all C++, you could reasonably say something about "people in 
glass houses should not throw stones." :) So even though image decoders 
are quite sensitive, that shouldn't be a blocker IMO.


The most important point you need to know is that Safari doesn't use 
WebKit's image decoders at all, so if you want JPEG XL to work in 
Safari, contributing JPEG XL support to WebKit is not likely going to 
achieve your goal. Even if Safari did use our image decoders, which it 
doesn't, we don't copy third-party projects into the WebKit source 
without a *very* exceptional reason to do so (as for ANGLE or 
libwebrtc), so OS support for JPEG XL is going to be key. There are two 
cases:


(1) Non-Apple platforms use image decoders under 
Source/WebCore/platform/image-decoders. Depending on libjxl if it is 
installed as a system library, and using it to implement a JPEG XL 
image decoder under Source/WebCore/platform/images-decoders/jpegxl, 
seems OK to me. (Whereas copying libjxl into the WebKit source repo 
would certainly not be OK. That's way too much code.) There would need 
to be a CMake build option to disable the dependency for systems where 
libjxl is not available as a system library. It would only make sense 
to do this if somebody makes an effort to package libjxl for at least a 
few major Linux distros, otherwise it won't be used in practice. 
PlayStation and Windows ports can then build libjxl themselves if they 
so choose.


(2) Apple platforms use CoreGraphics for image decoding, see 
Source/WebCore/platform/graphics/cg/ImageDecoderCG.[cpp,h]. I don't 
know much about this, but I don't think it's open source, so I would 
guess that contributions are probably not possible. I'm not sure what 
to tell you here. Hopefully somebody from Apple will comment.


Good luck,

Michael


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] JPEG XL support?

[Sami Boukortt via webkit-dev]

Hello WebKit developers,

I am Sami from the team at Google+Cloudinary that is working on JPEG
XL . We are making good
progress on our integration in the Chrome browser
, and we would be delighted if there were
support for it in WebKit as well, to make JPEG XL useful to more
users. There appears to be growing interest in using the format (~100
stars on the Chrome bug), including from Facebook (comment #16).

So, we wonder: would you be open to an implementation of JPEG XL
decoding in WebKit using the reference implementation
?

Many thanks.

Best regards,
Sami Boukortt on behalf of the libjxl team
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev