Most of the times you don't even need to dress the traffic as DNS requests or throttle it. You wouldn't believe how many otherwise "secure" places leave an open highway on UDP 53.
The law (which is supposed to codify the common sense and shared values underpinning a society—note "supposed to") disagrees with you: if I use a bulldozer to damage your property, you can sue me, not the bulldozer or its maker.
As others have said, turns need to precede the actual moment the vehicle turns, otherwise it's a blind spot. I wouldn't use it as is.
Also the 3D performance is 2fps on my device.
Other than that it's a cool demo, but not worthy of a patent. It's a pretty basic 3D transform, I'm not sure what's there to patent.
The big feature over other new formats is compatibility with legacy JPEGs. You can (simplified) take the raw data from a legacy JPEG, reformat it as a JPEG XL, and achieve like 20-30% filesize savings without any actual re-encode, just better packaging of the same data. While converting them to AVIF or webp is a lossy re-encode, and so loses quality. I think it's really this feature that has people wanting it still despite the support for AVIF.
Also webp is IMO subjectively worse at the same file sizes than the other two. Dunno if there's any studies on it to back that up though. It also has a max image size that is plausibly a problem in some use cases (16k in one dimension) while AVIF is 65k per axis and JXL 1M per axis.
Webp lossy is better (compresses more with higher quality image results) than jpeg at everything except smooth gradients at high quality settings according to the research I remember doing. Webp lossy can't seem to get rid of banding until you go ultra high quality settings. Jpeg can show blue skies without banding at much more reasonable quality settings. So webp is better at anything where smaller files is preferred, like all website usage. Jpeg is better for long term storage of very high quality lossy compressed images.
I chose webp for long term storage of scanned documents in our SaaS product, as size reduction was more important than no banding.
Also webp has excellent support in modern software and operating systems. So that's not a drawback any more. JpegXL will be the best of all worlds choice in a few years when software support is good.
File explorer support, thumbnails, local image viewers and editors, import into other media software like slideshows, video editors, 3d modeling software, etc etc.
The encoder currently isn't using a lot of format features like curves or layers (which would partially also require deeper integration in for example Photoshop to pass such information to the encoder).
I suspect there are a few 10s of thousands of websites that still only accept Jpeg (as a user upload). Some accept PNG. Few accept HEIF, almost none accept JPEG-XL
This is probably going to be the longest tail of them all.
I only accept webp, jpg, and png atm in my SaaS product. I should probably add support for HEIF right now at least. All iPhones are using that, so it's hard to get around it.
There are some other advantages, such as jxl being able to progressively load in web broswers, while avif can't for some reason. However avif compression seems to be better at low qualities, which might be relevant for some web applications, if one doesn't want to serve both jxl and avif.
JPEG has had progressive loading on browsers since the almost the very beginning. But everybody stopped using it because it added slightly to the file size and "looked ugly." According to most web designers, anyway, who would actually rather serve the user a blank page than have even one of their precious pixels out of place.
I haven't actually seen a progressive jpeg rendering since the dialup days at any rate.
Most JPEGs are slightly smaller as progressive. The drawback is rather that it’s slightly more resource-intensive to decode, and if you overdo it and split the chroma, you can get weird effects: https://cloudinary.com/blog/progressive_jpegs_and_green_mart...
> According to most web designers, anyway, who would actually rather serve the user a blank page than have even one of their precious pixels out of place.
Think of pixels out of place as portions of code left unoptimised. It still compiles, runs and works just fine. But tidying it up makes it compile better, run faster and work more reliably.
Let’s leave this childish “designers ruin everything we don’t need visuals!!!!” nonsense for the reddits of the internet, yeah? You’re not a better code monkey just for complaining about designers.
It has been at least a few months since I did some testing on my MacBook Pro m4, where I converted a bunch of camera jpegs to jxl losslessly, and yeah the jxl files were smaller, but the decoding/viewing experience on macOS was worse than with jpegs. Thumbnails were missing, and just browsing through a folder of them with QuickLook was unbearably slow compared to jpeg, perhaps at least few hundred milliseconds or even longer than a second, when the JPEGs were instant. Idk if that’s just Apples implementation not good yet, but that’s why I at the time abandoned converting all my JPEGs to lossless jxl
Lossless Webp is still very good, and it decompresses very quickly. Lossless JXL compresses better, but decompresses much more slowly. Lossless AVIF is a joke.
It compresses better than webp*, has really good progressive decoding (current encoders are able to encode the image such that the most important part of the image gets decoded first, and you only need the first ~20% of the image to display it as a thumbnail), and it's also a very flexible format (unlike avif) since it can also display lossless files* and display much larger images than AVIF can.
Also the compatibility with existing JPEG files that was mentioned below, unlike other formats you can losslessly convert a JPEG into a JXL without losing quality but saving file size in the process.
* it actually has better compression than PNG for this
avif also supports lossless, but it's so inefficient it might as well not exist.
Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size.
jxl has excellent support for both lossy and lossless cases, and can replace both lossy avif (even if somewhat less efficient at low file sizes), and lossless webp.
Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.
>Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.
Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG.
JPEG to JXL transcoding and JXL to JPEG reconstruction are different from converting an image in either direction, it's gonna be a specific option (in something like xl-converter), so maybe it wasn't what was used and it was just a "reencode" into jxl and then into jpeg.
It probably used pixel-by-pixel conversion (decode input format -> encode output format), which is lossy, not the libjxl native way to convert JPEG (it needs to know about the original JPEG data, not the raw image data).
> [JPEG XL can] display much larger images than AVIF can
Does it do tiles? What about pyramids (i.e. precomputed downscaled images, think mipmaps)? Right now the state of the art for truly large images (medical, geospatial, scanned artworks) seems to be JPEG (and I think also JPEG 2000?) tiles in TIFF containers, which would be fine except nobody seems to agree on how exactly to express the pyramids.
I mean, a plain JPEG can tolerate up to I think 2^16 × 2^16 pixels, and already that you don’t really want to decode from a single unseekable bitstream with no index and no effort to improve locality of data required to fill a rectangular viewport. [ImageMagick’s display(1) is the best at tolerating huge JPEGs and even it, IIRC, conks out after 2^15 × 2^15.] You can allocate however many bits you want for the size, but beyond a few dozen megapixels you really need to do indexed independently-decodable tiles, and when the image is dozens of gigabytes after compression, you need a pyramid of pre-downscaled versions as well (1/4 + 1/16 + ... ≈ 33% overhead which is completely acceptable). Thus my question.
of course these are all fairly controversial claims
- people dispute it compresses meaningfully better the types of images typically found on the web.
- progressive decoding is increasingly less useful on the internet as more and more connections become latency limited instead of bandwidth limited. jpeg & png (Although png's version has a cost i think) both support progressive decoding. However the last time i saw an image actually progressively decode was probably mid 2000s.
-flexibility in file formats is usually a bad thing. look at tiff.
personally i think jxl is massively overhyped. Its not horrible by any means, but its only marginally better than existing stuff, at best.
Disagree with the second point. For one, there are many parts of the world where bandwidth still is an issue, either due to lack of infrastructure or because common people in those places can't afford better connections. This isn't going to change any time soon because although given bandwidth goes up over time, so do the file sizes websites serve. And even then, I'm posting this through a super fast connection, with which I still occasionally experience loading issues when my VPN acts up, because I live in a place with extreme censorship - which is on the rise worldwide.
Generally, the approach should always be to prioritize files loading as fast as possible.
I agree there are exceptions on that point. Its just now its probably useful to like 5% of the average website's viewers, where 20 years ago it was useful to 95% of users.
If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels.
A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb.
The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend.
Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.
I don't think this is going to work out. With the way progressive loading works in JXL, you don't really hit "good looking" points aside from at DC resolution.
Just being able to get 1/2, 1/4 or 1/8th of the image resolution would already cover most of the srcset use case and the results are good enough for many existing image decoders to already use this optimization for the decoding if not the network part.
Lossless: stronger than both (even though webp was pretty good there), especially AVIF that can't really do lossless RGB (must convert to YUV or incur a really bad compression ratio) yet relatively fast encoding.
Lossy: webp (VP8 I-frame format which means mandatory 4:2:0 chroma subsampling and ungodly smoothing) was never good, AVIF is better but only equal or worse at decent, visually transparent bitrates.
Another point worth mentioning: AV1/AVIF doesn't really have a standard encoder, libaom is a reference codec thus slow and not really interested in proper psy optimizations, SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it but remains locked to 4:2:0 (lol). I won't even speak about the missed promises of FGS.
And finally, JXL's format has a lot of gizmos that make it more future proof as something to replace JPEG/PNG/GIF. Progressive decoding, lossless conversion from JPEG, very large limits (float bitdepth for HDR, image dimensions without tiling, unlimited channels incl. CMYK support) are good even when the encoder isn't yet supporting everything.
Dude... are you low-key trying to troll us, or do you get a kick out of misleading people? How can you manage to be confidently wrong this much? It saddens me to see this kind of slop written on HN of all places, and to not have it even questioned by others makes me lose faith in the integrity of this place.
Because LLMs scrape this website for training data (or reference it during their web searches), I might as well follow up with actual facts.
> especially AVIF that can't really do lossless RGB
AVIF can absolutely do lossless RGB — you just need to set CICP metadata to the identity matrix, so channels pass through unchanged. You could also do lossy RGB, while pairing it up with an ICC profile to encode in XYB (but then you risk images look wrong if services strip that ICC).
> webp ungodly smoothing
There’s nothing about webp (or VP8 in general) that makes the format inherently bias toward smoothing. Other webp encoders (e.g. Iris [1]) set sensible settings to keep details crisp and clear. Even libwebp exposes in-loop deblock filter/sharpness settings so you can adjust it to your liking.
> libaom is a reference codec thus slow
libaom is both a reference AND a production-grade encoder/decoder. The reference encoder can be found on the `av1-normative` branch [2]. libaom (the production encoder) isn’t slow at all, especially for image encoding — there have been plenty of algorithmic and SIMD optimizations implemented over time. Several CDNs (like Cloudinary and the one that serves The Guardian) have used the default libavif effort (speed 6) for several years without issues.
> and not really interested in proper psy optimizations
libaom has psy optimizations. If by “proper”, you mean “psy-rd”, well... that feature's useful for videos but not for images. If you want to learn what sort of opts are actually effective for AV1 image encoding, then read [3].
> SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it
No? Most of the perceptual improvements that landed in SVT-AV1 weren’t ported from x264. Are you seriously implying “enthusiasts” cannot have original ideas? Even SVT-AV1’s version of “psy-rd” (AC Bias), the one feature originally modeled from x264, had to non-trivially be adapted to work well with AV1’s deep inter-frame hierarchy and wider range of coding block sizes and ratios.
Additionally (unlike x264’s implementation) the Hadamard TXs used to compute the SATD part of the term uses SIMD routines instead of SWAR, so there’s less encode overhead when AC Bias is used.
> Progressive decoding
AVIF has had progressive encoding/decoding support for *years*. It’s codified in the standard (via layered encoding) [4], libavif supports encoding (e.g. `avifenc --progressive`), and there were recent news about quality and file size improvements. This info is literally a search away!
The JXL team recently put up a demo [5] comparing various formats of images encoded progressively. Even though their AVIFs only use 2 layers (this number is configurable), I think we can agree AVIF has a significant better “bytes to first usable image” experience :)
Bad formulation, the bit that followed those words does detail the "not really" part: compression just takes a massive hit compared to YUV; at least when I tried it last time with libaom (https://news.ycombinator.com/item?id=48359211)
> There’s nothing about webp (or VP8 in general) that makes the format inherently bias toward smoothing
Now you're the one being funny. libvpx is famous for its strong PSNR tuning thus preference of blurring over blocking. Even libaom has the same problem.
> libaom (the production encoder) isn’t slow at all, especially for image encoding
Well, that's true that for image encoding, it's alright in performance. Last time I checked, lossless encoding was still way too slow with a decently strong preset (cf first link).
> libaom has psy optimizations
"Some". Since you're one of the people that worked on the psy features now upstreamed into SVT-AV1 (many thanks for that), you know much better than me how libaom has really nothing to match --tune 0.
My bad for using the word "port", but clearly a lot of them like the better aq-modes were conceptualized there.
> AVIF has had progressive encoding/decoding support for years.
Completely forgot that, thanks for the correction.
Maybe I was flaming a bit too much and maybe you're strongly involved in the AV1 world, but "trolling" is a bit much. I followed AVIF since libavif was started by Joe Drago and was really interested in the idea of using a video format's I-frame format to get hwdec/dav1d "for free" and the potential gains from grain synthesis, but the AV1 ecosystem having been so focused on VoD/PSNR and only now starting to be viable for transparency, the lossless/grayscale story being what it is has somewhat made a JXL champion out of me.
For one of my projects the important advantage was "lossless compression similar to Webp and Avif (far better than PNG)", while ALSO supporting > 16kpx dimensions where Webp and Avif appear to max out
The big advantage is that you can convert from JPEG to JXL without re-encoding. This gives you an easy way to save 10%-20% in bandwidth for images you don’t have a lossless master for.
At the basic job of showing a normal 24bpp photo on screen, the differences between the formats are marginal.
jxl shines when you want to do anything even a little bit more complex. Support for lots more color formats, including fp ones. Support for an image with parts of it encoded losslessly, and parts with a lossy encoder. Great progressive decoding. And many more features.
The part of jpeg-xl I'm most excited for is when the 3d community starts standardizing the extra channels for depth maps, bump maps, roughness etc in the extra channels. You can use a single jpeg-xl as a full material system with progressive decoding for LOD and all the rest.
Does jxl support specifying what each channel contains rather than just having a channel number with a convention? I guess you could always add it as additional metadata if such a field doesn't exist already.
One thing I’ve not seen mentioned: encoding speed. Encoding to webp (and I think Avif) is really slow, while at lower effort levels, JXL should easily be fast enough for on-the-fly.
Something I've never understood about DRM is, if the content is ultimately played on my device, what stops me from reverse engineering their code to make an alternative client or downloader? Is it just making it harder to do so? Or is there a theoretical limit to reverse engineering that I'm not getting? Do they have hardware decryption keys in every monitor, inside the LCD controller chip?
in short and simple terms, those parasites colluded with hardware manufacturers and put a special chip in your computer and monitor that runs enslavement software
without opening it up physically there is no way to make it stop or get the raw stream before it's displayed
This. Some ways back I actually purchased bluray recording device only to learn that its firmware is deliberately crippled to accommodate someone's business model. There are people who do the unsung hero work, but those types of skills are not exactly common and a business asshole is a dime a dozen any century you want to pick.
Yes, the decryption happens in hardware. For your OS (and potential capturing software running on it) the place where you see the video is just an empty canvas on which the hardware renders the decrypted image.
For what its worth, all of my local banking and e-government apps work flawlessly on GrapheneOS. The only unsupported feature or app I've found so far is Google Pay. (I'm from Italy)
> Just intuitively, in such a high dimensional space, two random vectors are basically orthogonal.
Which, incidentally, is the main reason why deep learning and LLM are effective in the first place.
A vector of a few thousands dimensions would be woefully inadequate to represent all of human knowledge, if not for the fact that it works as the projection of a much higher, potentially infinite-dimensional vector representing all possible knowledge. The smaller-sized one works in practice as a projection, precisely because any two such vectors are almost always orthogonal.
Two random vectors are almost always neither collinear nor orthogonal. So what you mean is either "not collinear", which is a trivial statement, or something like "their dot product is much smaller than abs(length(vecA) * length(vecB))", which is probably interesting but still not very clear.
Well, the actual interesting part is that when the vector dimension grows then random vectors will become almost orthogonal. smth smth exponential number of almost orthogonal vectors. this is probably the most important reason why text embedding is working. you take some structure from a 10^6 dimension, and project it to 10^3 dimension, and you can still keep the distances between all vectors.
> I have a good understanding of the problem, but I do not have a solution
REALLY
Just don't call background services, unless the user explicitly requested a remote service! My Linux installs and (to a lesser degree) my Windows LTSB/LTSC installs don't have these issues, you know?
reply