How much work is actually involved in adding support for this format? Like is it just plugging an existing implementation into the abstractions they already have for other image formats? or is there more to it?
Request: Re-open JPEG XL issue
71–80 of 164 posts
Re: Request: Re-open JPEG XL issue
#72As a photographer I am looking forward to it. I process photos in ProPhoto RGB and I’m in the process of switching up my process to always publish images to the web as Display P3 which can be done just fine in JPEG and WEBP by attaching a color profile. Display P3 is moderately larger than the old standard sRGB; you are trading some color resolution in the “mainstream” area for more saturated greens and reds. 4K TV’s…
> 4K TV’s use Rec 2020 Is defined by some standard to be able to be declared "4K", or is it just what seems to be happening because all/most of the panel makers just threw it in?
The video is supposed to be encoded in Rec 2020. The panel is what it is. TV manufacturers negotiated to get a green primary close to what they could manufacture but really the panel is likely to be a little different and be color managed.
My main monitor is a Dell that is very close to Adobe RGB which is great for print work because it covers the CYMK gamut well.
I am interested in getting something better but it is not so clear to me that you can really get a Rec 2020 computer monitor other than a crazy expensive monitor from Dolby. Maybe I gotta download a bunch of monitor profiles so I can know what various monitors really support as I’ve already developed a system for simulating how channel separation works for red-cyan stereograms even on monitors I don’t have.
A better TV has been on the agenda too except somehow people keep giving me free TVs on the railing edge such as a Walmart TV which had great sound (better than many sound bars) that had the backlight burn out, then I got gifted a Samsung which sucks but is working fine in my TV nook downstairs. My main AV room doesn’t have room for anything bigger than what I’ve got unless I move everything which I don’t have a good plan for…
Re: Request: Re-open JPEG XL issue
#73Earlier quoted context omitted.
Oh please, Google’s parent company is worth 1.64 trillion USD. They can afford a few programmers to maintain a codec. Lack of popularity hasn’t stop them from supporting webp and AVIF.
>They can afford a few programmers to maintain a codec. This is a bad argument because with that money they can also afford to do almost anything. They could also add any random file format to the browser, but that increases costs to support the web for more than just Google. Meanwhile adding a polyfill to support the format is performant without adding complexity to the web.
It’s also a bad argument because it confuses market cap with “money available to invest in developing products” (not that Google isn’t swimming in dumb money for other reasons).
Re: Request: Re-open JPEG XL issue
#74So, all it takes to consider a small community requested change in Chromium is a massive protest from thousands of users, small businesses, and Fortune 500 companies for almost a year... Or maybe they are just trying to keep feature parity with Safari.
Of course Apple adding support in Safari is far more important than Internet outrage! At this point adding new {image, audio, video, compression} codecs to browsers is probably a net negative, unless there's a good chance they get deployed across the entire browser ecosystem. Safari is generally the browser that's most conservative about implementing anything new, so their support makes a huge difference in the viabi…
I would guess that Apple make business decisions based on metrics that others do not have access to, including those unknown to Google and average internet users.
Re: Request: Re-open JPEG XL issue
#75Earlier quoted context omitted.
JPEG has 12-bit somewhere in the standard, not sure on where it's implemented.
I'm not aware of any photo editing software that can export 12bit JPEG (although to be fair I don't know many), I am aware though that JPEG 2000 supports 12bit color and that JPEG XT supports up to 16bit color, perhaps that's whats causing the confusion?
Darktable supports it under JPEG2000: https://docs.darktable.org/usermanual/4.0/en/overview/suppor...
(Darktable also supports JPEG XL)
Re: Request: Re-open JPEG XL issue
#76As a photographer I am looking forward to it. I process photos in ProPhoto RGB and I’m in the process of switching up my process to always publish images to the web as Display P3 which can be done just fine in JPEG and WEBP by attaching a color profile. Display P3 is moderately larger than the old standard sRGB; you are trading some color resolution in the “mainstream” area for more saturated greens and reds. 4K TV’s…
Here are visual comparisons between AVIF and JPEG XL on some test images with various bitrates / quality levels:
https://afontenot.github.io/image-formats-comparison/#end-of...
It seems AVIF has better compression at lower bit rates. At high bit rates they seem similar. AVIF especially shines for pictures with large homogeneous surfaces like the sky.
However, AVIF is missing some important features, such as progressive image loading. The maximum resolution is apparently also quite limited.
Re: Request: Re-open JPEG XL issue
#77How much work is actually involved in adding support for this format? Like is it just plugging an existing implementation into the abstractions they already have for other image formats? or is there more to it?
Integration of a new decoder is not all that complicated code wise. What is complicated is the effects of the change and ongoing support.
1. Binary size cost, in my experience working on Firefox this is in the 100s of KiB range when adding a new decoder.
2. Ongoing costs increased compile times, new integration tests, functional tests and so forth. Keeping those tests passing and non-flaky.
3. Once something is accepted into the web ecosystem the intention is to support it for 10s of years if not forever. Web feature deprecation is quite slow, ex & . The web has not deprecated a primary image format.
4. Security, a 'new' binary format is a place for security vulnerabilities, crashes and hangs. The web is actively hostile place for web browsers.
Re: Request: Re-open JPEG XL issue
#78Earlier quoted context omitted.
I'm not aware of any photo editing software that can export 12bit JPEG (although to be fair I don't know many), I am aware though that JPEG 2000 supports 12bit color and that JPEG XT supports up to 16bit color, perhaps that's whats causing the confusion?
Darktable supports it under JPEG2000: https://docs.darktable.org/usermanual/4.0/en/overview/suppor... (Darktable also supports JPEG XL)
JPEG2000 is a different format, just as JPEG XL isn't the same as original JPEG.
Re: Request: Re-open JPEG XL issue
#79Earlier quoted context omitted.
If anything, it'd be AVIF. WebP is obsolete. It's still based on VP8 codec, which in video has been replaced by VP9 long time ago. AVIF is based on AV1, which is a successor to VP10. So WebP is a few generations behind in the VPx lineage, and is no match for modern codecs.
We haven't even switched to WebP yet, and it's already obsolete? What hope is there for anything?
WebP was the classic Google “ship the prototype” move - they were hoping Chrome could muscle it through but it delivered only modest compression improvements (10-15% real world - the marketing papers promised 30% based on comparisons to unoptimized JPEGs) but it was missing features and had very primitive software support, making it harder to produce, deliver, or share (when Facebook switched, a common complaint was someone downloading a picture and finding it didn’t work in another app or when they sent it to a friend).
Very few sites pay for so much outgoing image bandwidth to make that compatibility cost lower than a 15% savings.
Re: Request: Re-open JPEG XL issue
#80How much work is actually involved in adding support for this format? Like is it just plugging an existing implementation into the abstractions they already have for other image formats? or is there more to it?
For a browser, it means permanent, forever, support for the format and continued maintenance and security patching for the library. Any CVE, any issue that might cause the browser to be insecure will be blamed on the browser and the developers will have to make sure any codec they use is safe forever.
That's the cost for the maintainers. Codecs are historically one of the most problematic sources of security issues (they're complex code that handles malicious downloaded files) and supporting a new one is a rather big maintenance burden for everyone involved.
And if Chrome gets backdoored by a JXL library security hole, everyone will blame Google for it.
If, by any chance, supporting JXL becomes too much of a burden, everyone will again blame Google for being evil if they ever remove it from Chrome.