Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The case for JPEG XL

cloudinary.com

Post reply on HN
Print view View original

121–130 of 210 posts

Re: The case for JPEG XL

#121

Post by ayushnix »

account42 wrote: post #116

Unrelated to the content, but isn't it silly that browsers start hiding the scroll bar only for websites to implement their own ad-hoc reading progress bars.

I find both solutions to be flawed. The traditional scrollbar introduces layout shift when going from one page without a scrollbar to a page with a scrollbar. The new overlay scrollbar is sometimes harder to click and activate, especially in Chromium. Firefox's overlay scrollbar seems to do the right thing. The reading progress bars are a distraction and probably harmful to one's attention span and reading ability.

I guess scrollbar-gutter can fix the traditional scrollbar but then people have to give up using their fancy banners in headers. I'm (mostly) fine with Firefox's overlay scrollbar for now.

Re: The case for JPEG XL

#122

Post by account42 »

enimodas wrote: post #94

Tangentially, in his linked page "hall of shame" https://jon-cld.s3.amazonaws.com/test/ahall_of_fshame_SSIMUL... , he argues humans prefer row A to row C. Personally in most cases I prefer row C. It may have less color accuracy, but is often a lot sharper, which in my eyes stands out a lot more.

It's also comparing two overly compresses images with encoders which produce very different kind of artificats (bluriness vs. blocks of wrong colors). Which one is better is always going to be subjective (or at least application-specific). Really, as long as the model rates both as shit it is not necessarily a bad model.

Re: The case for JPEG XL

#123

Post by account42 »

ayushnix wrote: post #121
account42 wrote: post #116

Unrelated to the content, but isn't it silly that browsers start hiding the scroll bar only for websites to implement their own ad-hoc reading progress bars.

I find both solutions to be flawed. The traditional scrollbar introduces layout shift when going from one page without a scrollbar to a page with a scrollbar. The new overlay scrollbar is sometimes harder to click and activate, especially in Chromium. Firefox's overlay scrollbar seems to do the right thing. The reading progress bars are a distraction and probably harmful to one's attention span and reading ability. I…

At least on a desktop we have enough horizontal space to always display the vertical scrollbar, which solves all issues. But even without that, the layout difference between pages with or without scrollbar is so tiny that IMO its a nonissue.

Mobile is a tricky tradeoff. There I am mostly used to Firefox, which has a tiny overlay scrollbar that is 50% grey making it almost invisibile in most cases.

Re: The case for JPEG XL

#124

Post by palotasb »

janwas wrote: post #48
mastax wrote: post #44

> One final significant benefit of JPEG XL is that it has a broad scope: while it is a great format for web delivery, this is not the only use case it was designed for. JPEG XL can also be used as a capture format, where it can play a role similar to current camera raw formats: high precision, high dynamic range, lossless or minimal lossy compression. It can also be used as an authoring format, supporting named layer…

Disclaimer: I co-chaired the JPEG XL working group; opinions are my own. The JPEG XL format is most certainly not a nightmare internally. Compare the spec lengths: 681 pages for https://aomediacodec.github.io/av1-spec/av1-spec.pdf , 101 for https://www.iso.org/standard/77977.html . Or code sizes: 6.6 MB uncompressed for libjxl (encoder+decoder), 9.5 MB for dav1d (decoder only) plus 34.2 MB for SVT-AV1 (encoder). Feat…

Is there a "latest draft" standard available legally and for free for wider audiences? C++, also ISO standardized, does this and I believe it has contributed greatly to its adoption and post-C++11 renaissance. See https://en.cppreference.com/w/cpp/links#C.2B.2B_Language_and... . For now, JPEG XL might as well be a proprietary closed format for most hackers here.

Re: The case for JPEG XL

#125

Post by worldofmatthew »

jl6 wrote: post #68
DaiPlusPlus wrote: post #49

Earlier quoted context omitted.

Preface: It's difficult to write about stuff like this and I know reading it back to myself after will leave me wanting to redraft it 5 times over but it's 1am already. But, if this post is wrong/incorrect or is missing other factors that are too important to leave out then please let me know and I'll amend or even delete it. My focus is on the technical side of things. So anyway: > why it itsn't the case for other i…

There’s a Twitter thread by a JPEG XL dev who tries to explain some of this in terms of the XYB color space giving more bits to dark tones: https://mobile.twitter.com/jonsneyers/status/155021585930558... But I’m not clear if this was a design goal of JPEG XL, or a theoretical side-benefit, or something you would need an HDR screen to appreciate (I couldn’t tell the difference in any of the example images, but those m…

Besides that jokes you can make at that tweet in how it claims a image codec can be racist. If you know how to limit the image quality range in AVIF (and how to reduce smoothing which can be done), you can get images that have dark areas that are near to that of JPEG-XL.

I have been able to (by both reducing the quality range and turning smoothing off) to get much better results on a high contrast image with most of its details in darker, having far-more details in those dark area with AVIF than JPEG-XL (not small differences either as you could see brick work that was destroyed by compression artifacts in JPEG-XL).

libavif default settings suck.

Re: The case for JPEG XL

#126

Post by jonsneyers »

palotasb wrote: post #124
janwas wrote: post #48

Earlier quoted context omitted.

Disclaimer: I co-chaired the JPEG XL working group; opinions are my own. The JPEG XL format is most certainly not a nightmare internally. Compare the spec lengths: 681 pages for https://aomediacodec.github.io/av1-spec/av1-spec.pdf , 101 for https://www.iso.org/standard/77977.html . Or code sizes: 6.6 MB uncompressed for libjxl (encoder+decoder), 9.5 MB for dav1d (decoder only) plus 34.2 MB for SVT-AV1 (encoder). Feat…

Is there a "latest draft" standard available legally and for free for wider audiences? C++, also ISO standardized, does this and I believe it has contributed greatly to its adoption and post-C++11 renaissance. See https://en.cppreference.com/w/cpp/links#C.2B.2B_Language_and... . For now, JPEG XL might as well be a proprietary closed format for most hackers here.

Recent drafts do tend to get circulated amongst the image compression community. For wide audiences I don't think this type of document is very readable nor relevant; the number of people who are going to make their own independent implementation is relatively small. In this sense the spec audience is not quite the same as that of a spec for a programming language, which is important not just for compiler implementers but also for programmers in general.

That said, I do hope that ISO will change its policy to put specs behind a paywall.

Re: The case for JPEG XL

#128

Post by nigeltao »

JyrkiAlakuijala wrote: post #113
nigeltao wrote: post #47

From the "Lossless Compression Performance" section of the article: > JPEG XL can do lossless image compression in a way that beats existing formats (in particular PNG) in all ways: it can be faster to encode, produces smaller files, and more... Does "in all ways" include any decode (not encode) speed numbers? Such numbers are dependent on the test suite, and I might be holding it wrong, but on my measurements, JPEG…

I believe that density is 100x to 1000x more important for fast experience and computational cost than the near instantaneous decoding speed of common lossless formats.

I agree that compression ratio is the primary metric (but not the only important metric). I just found "[better] in all ways", explicitly calling out encode speed, incongruous with simply ignoring decode speed.

As for which is more important out of encode and decode speed, I would personally rank decode speed higher. For example, app icons on your home screen were encoded once (by the graphic artist) but are decoded zillions of times (by every user every day).

Re: The case for JPEG XL

#129

Post by webmobdev »

account42 wrote: post #118

Another argument: JXL actually supports losless compression of RGB bitmaps and cjxl (the JXL reference encoder) actually supports color spaces correctly when converting from PNG unlike Google's WEBP, which only supports losless YUV compression and the conversion from RGB to YUV is not entirely lossless and cwebp (Google's WEBP reference encoder) doesn't support all the ways color spaces can be encoded in PNGs, result…

Yeah, if I remember right, when I was converting some high resolution uncompressed TIFF images to lossless HEIF / HEIC on macOS preview, most of them looked off because colour space conversion was happening (I think from RGB to YUV). (Not to mention many actually failed to convert because none of the HEIF / HEVC encoder I tried could handle very large image sizes). I finally opted for JPEG2000 format to archive those images. I've been waiting for JPEG XL for sometime now to be ready - by my rough calculations, I may be able to get an extra 10 GB space by converting these images to JPEG XL, without any quality loss or issues.

Re: The case for JPEG XL

#130

Post by JyrkiAlakuijala »

account42 wrote: post #118

Another argument: JXL actually supports losless compression of RGB bitmaps and cjxl (the JXL reference encoder) actually supports color spaces correctly when converting from PNG unlike Google's WEBP, which only supports losless YUV compression and the conversion from RGB to YUV is not entirely lossless and cwebp (Google's WEBP reference encoder) doesn't support all the ways color spaces can be encoded in PNGs, result…

WebP lossless is also RGB lossless. I designed it and this was one of the main functional requirements I chose for it.

Particularly, WebP lossless does not use YUV compression. It does (optionally) reduce component correlations by the 'subtract green' transform.

It might be possible to construct an ICC profile in that formalism that would go close to YUV, but that is definitely not supported currently in cwebp.

Post reply on HN