181–190 of 210 posts
Earlier quoted context omitted.
Personally, the name always turned me off. I saw the option in photoshop when saving files, but my thinking went "jpg bad, jpg XL is a weird name, must be a minor incremental improvement over jpg".
Why would you think "XL" would be minor improvement?
Earlier quoted context omitted.
Firefox was slow as hell and resource hungry Also, the ui doesn’t feel naive at all
No UIs feel native these days, everybody invents their own UI kits.
Right click on text, there's no dictionary lookup menu item
The border around input fields look weird
Earlier quoted context omitted.
fjxl is the "JXL_Lossless/f" lines in my full_benchmarks.txt link. It's about mid-table in terms of encode speed. I clocked it at about 10x faster than libpng, not 100x faster. If you look solely at encode speed, fjxl loses to fpnge (also listed in full_benchmarks.txt) so I'm not convinced yet that JPEG XL beats PNG in all ways. I believe that Apple have an unofficial PNG extension that facilitates multi-threaded dec…
Did you compile fjxl with or without SIMD? That makes a big difference. And yes, fpnge is slightly faster than fjxl but also compresses significantly worse. It is likely that you could make an even faster but slightly worse version of fjxl that would beat fpnge. But I think the speed of fjxl is already good enough in practice. The problem with PNG extensions for multi-threading is that it only works if you control th…
I had not. Thanks for the tip. Fjxl encoding speed is now about 20x faster than libpng, not 10x, but still mid-table. Decoding speed is unaffected.
https://github.com/nigeltao/qoir/commit/c2fec840
> If existing deployments need to be replaced anyway, you can just as well use a new format altogether.
There's still an operational difference between rolling out multi-threaded PNG versus multi-threaded $OTHER_FORMAT.
At the file format level, MT PNG can be designed to be backwards compatible. Older PNG decoders simply ignore the new non-critical chunk.
At the software level, you can roll out encoders that emit MT-capable PNGs without having to also roll out new decoders everywhere (or 99% everywhere, or 'on all major browsers'). You can roll out new decoders only partially, and those upgraded places enjoy the benefits, but you don't break the decoders you don't control.
Also, in terms of additional code size, upgrading your PNG library from version N to version N+1 is probably smaller than adding a whole new $OTHER_FORMAT library.
Earlier quoted context omitted.
It's relevant because there is no doubt that Firefox would not have axed a promising open format despite users asking for it. It is possible that FF won't continue the work of implementing it if they see no future without the oligarch in the field, but we'll see
Mozilla did not want to ship WebP at all, despite users asking for it, and only added it after too many Chrome-only sites forced them to. All browser vendors are pretty reluctant to add new codecs, because there's always going to be yet another promising codec to add, but they're left maintaining all of them forever, even after they're not cool and new any more.
Earlier quoted context omitted.
Mozilla did not want to ship WebP at all, despite users asking for it, and only added it after too many Chrome-only sites forced them to. All browser vendors are pretty reluctant to add new codecs, because there's always going to be yet another promising codec to add, but they're left maintaining all of them forever, even after they're not cool and new any more.
I don't think there was ever a good case for WebP, but JPEG XL sounds promising. The problem of course, is the monopoly browser developer made WebP, and the monopoly browser developer sees JPEG XL as a competitor to their in-house format.
> A unique feature of JPEG XL is that it is possible to recompress existing JPEG images (of which there are a lot out there!) to a JPEG XL file that is on average about 20% smaller, without introducing any loss. In fact, the bit-exact same JPEG file can be reconstructed from the JPEG XL file. I wasn't aware of this and this is actually crazy, and freaking brilliant from a migration point of view. I wonder how that wa…
The journey to JPEG XL started with guetzli (which started with butteraugli to guide loss in JPEG encoding) and brunsli. Guetzli is a great (but very very slow) JPEG encoder. Brunsli is a classic JPEG1 recompressor. We mixed those and got the first version of PIK. We added some forced format-level progression, adaptive quantization, filtering, larger DCTs, integerated HUIF as lossless/super-progressive coder, and ado…
Earlier quoted context omitted.
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.
It annoyed to me enough to make me activate overlay scrollbar on Firefox and inject custom CSS with scrollbar-gutter on Chromium. Otherwise, when moving from a repo home page (without a scroll bar) to the another page (let's say the contents a folder with a scrollbar), the box containing the contents of the repo experiences layout shift.
This is still an issue on GitHub and many other sites.
Earlier quoted context omitted.
Be careful with this website. Cloudinary is a developer of JPEG XL, is an affiliated party, so there is absolutely no reason to expect a fair comparison. Instead visit https://storage.googleapis.com/demos.webmproject.org/webp/cm... and you will see that JPEG XL has color fringing and ringing artifacts.
There is some irony on calling out benchmarks from an affiliated party and then linking to benchmarks from an affiliated party of the competing format. > The source images were stripped of any metadata, EXIF, XMP, color profile etc. including the gAMA PNG chunk. Just so happens that cjxl correctly supports PNG color profile/gamma data while cwebp doesn't.
Earlier quoted context omitted.
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.
… and unfortunately it's not draggable, either.
Earlier quoted context omitted.
Some of it relates to the modeling of spontaneous excitation bias of opsin molecule releasing their energy in the retina. These are modeled in the compression curve in JPEG XL by a bias before the compression non-linearity, whereas other codecs don't have that bias unless they use sRGB -- sRGB has modeled the bias as a short linear slope, but compresses in wrong directions (RGB) in the color space, not LMS. In JPEG X…
Hi Jyrki, this is all very interesting. A couple questions for you, while you’re in this thread: - where is the best documentation for the Butteraugli metric? I’ve found it quite difficult to find a high-level rationale/design notes for the metric. - I also understand that JXL doesn’t try to explicitly optimize against Butteraugli distance unless you invoke the higher effort levels, and then, it uses a slightly diffe…
Butteraugli is largerly a 'learned' metric, just very small with its ~200 parameters. I implemented possible components and tuned them and their interactions using methods similar to machine learning.
Describing it to humans should be possible, but going all the way is going to be the same as describing DNNs.
SSIMULACRA 2 is taking the same approach and getting far better results than a previous effort SSIMULACRA.
2) butteraugli distance invoked in the higher effort levels
JXL heuristics are optimized to give good butteraugli scores. These heuristics are mostly used at speeds 6 and 7.
Speed 8 and 9 no longer trust solely on the heuristics, but they try to optimize a constant butteraugli score. It is important to note that they don't do RD-optimization, so they are quite bad at lower quality -- they will drive the quality bad no matter what. There is a hard limit for not reducing the quality too much in relation to the heuristics at speeds 6 and 7, but it is not RD optimization. Small savings can lead to large degradations. This is ok with near visually lossless (quality 90+), but not good for low quality (Butteraugli has slightly evolved through the times, the latest version is available in libjxl and used by cjxl at effort 8 and 9.
3) -d 1 “an image with at most Butteraugli distance 1” ?
It used to work that way, but there was some inflation of this concept, and often the maximum score is twice the asked value. Ideally the maximum should be the given value, but it is very expensive to guarantee. In guetzli we have such guarantees, but it runs 1000x slower.
4) p-norm
usual metrics (SSIM, PSNR, VMAF) aggregate error over the image to a single number using the 2nd norm
we use a higher norm, and actually a combination of norms. If you ask for a 3rd norm, it is an equal combination of 3rd, 6th and 12th norm. Using higher norms puts more emphasis on large errors somewhere than 2nd norm.
The better the quality in image compression, best human rater correlations can be found in higher norms. 3rd norm is a good allrounder, I'd usually use 6th norm myself. A lower norm can be better for automated optimization since the cost function will have less wrinkles.
5) colorspace
we don't have a good write up other than possibly the JPEG XL spec. there is a javascript implementation of xyb here: https://gist.github.com/mattdesl/c0ad8d54b3491c7fd39e222e698...
Please consider joining the JPEG XL discord. I'm available for guiding you to learn more if you like.