I fail to see any unique argument in this. That is to say you can replace Ontario with San Jose and it'll all work.
> Digital sovereignty and privacy is at stake.
This is the most strongest argument, and luckily that's the first one. Many ways to solve this so not really a big problem.
> Ontarians’ jobs risk being outsourced
What jobs are being displaced by driverless cars? The best argument here is uber drivers are going to be affected. Who would you rather drive you at 3am if you're a drunk woman? An uber driver or Waymo?
> Public transit could lose riders
What is the goal here? The goal is to move people efficiently and decrease the reliance on human driving, which can cause deaths. Public transportation is vital but again, there are times when subway / buses wont work.
Also, if public transit is a major concern, shouldnt we be asking Uber (see point #2) to go away?
The last two points are super generic, it isnt even worth discussion.
I'm only casually following JPEG-XL and my impression from previous reading here on HN was that JPEG-XL was the best solution available for a wide variety of usecases, but it looks like numbers dont match that claim?
JPEG-XL is not the best solution if you want small low-quality images, to reduce your costs for hosting some Web site. AVIF seems appropriate for that goal.
JPEG-XL seems to be the best solution for storing and distributing high-quality images. For myself, I want high-quality images, so JPEG-XL is what matters, both for new images and for compressing the old archives of JPEG images.
While I have my own Web server, it is for private use and not for commercial purposes, so I have no interest in using AVIF to achieve the smallest image sizes, but at a lower quality than I want.
Most of the comparisons are not about what I would call "high quality" images.
And the article supports what I have said.
Quotation from the article:
> But JPEG XL catches up at very high quality. Around SSIMULACRA2 85, libjxl's default matches AVIF's default, and at maximum efforts, jixel 'extraslow' is ~6% smaller than AVIF s0. jixel 'slow' is 10–13% smaller than AVIF's default from SSIMULACRA2 80 upwards.
There’s also data that isn’t needed in the final delivery format but is needed for editing. 8bit vs 16bit color for example. 8 bit is visually all you need for an image, but if you edit it to say being up the shadows, 8 bit will show banding because you’ve stretched it to the point the bands are visible. While 16bit has so much extra data it still looks perfect after being stretched.
JPEG XL is the ideal high end photography format. AVIF seems better for a space efficient web format.
Human eyes can quite reliably see greater than 8 bit color. While the eye is only able to differentiate about 10 million colors at any given brightness, because its sensitive to brightness in a logarithmic fashion the eye needs about 24 bits of per channel depth to see no banding.
Presumably this is for HDR. In the SDR space I don’t think you’d see the difference between 8 and 16bit. And the way it’s encoded is logarithmic so you can express the visible range with less bits where your eyes are less sensitive.
I think many people disliked Google's control of Chrome blocking JPEG XL rather than it being able to compete on its merits.
JPEG XL also has some big benefits for many use cases like lossless re-encoding and supporting higher resolution. AVIF images have a max size of 8192x4352 last I checked. That's not a problem for web images almost all of the time, but there's certainly uses where you might want more. I think AFIV might be limited to 12bit overall while JPEG XL can do 32bit. Again, is that something many will take advantage of on the web? No, but if it's something you care about it might be really meaningful to you.
Also, if you care about the 90% quality level, JPEG XL often outshines AVIF, but when I'm putting images on the web it's often well below that.
Some of it was bad information. I saw some people saying JPEG XL being way less computationally intensive (even less than WebP) and offering much better compression. Some of it was selective data - do you only test things at 95% quality level and declare a winner?
But I think the big thing is that a lot of people wanted the two formats to succeed or fail based on their merits. I think a lot of people don't like AVIF because it isn't well supported outside of browsers - and there can be a hope that the JPEG name would mean JPEG XL would get the kind of adoption JPEG did.
And it's hard to truly compare formats - or benchmark in general. As the article shows, different JPEG XL encoders offer vastly different performance. And when we're dealing with lossy compression, sometimes it can be a bit of personal preference. At some point, people started enjoying the way that MP3 garbled symbols (the instrument) and that was the sound they expected a symbol to make.
> coded image items compliant to the AVIF Baseline profile may not have a number of pixels greater than 8912896, a width greater than 8192 or a height greater than 4352.
I'm assuming if both the encoder and decoder support more than the baseline profile, then higher resolutions up to 64k x 64k are possible, although I would worry the file would be incompatible with some software.
It's been a few years since I last tried, so hopefully no longer an issue, but trying to encode 8192 × 5464 images from a Canon R5 a few years ago with libavif, and avifEncoderAddImage() would return a generic error.
If I reduced the res a bit, then it worked, so there did seem to be a limit there somewhere. height and width are stored as u32s internally though, so yes, the format itself technically supports it...
I never looked into it more, so might have been a libavif issue, or maybe the way I was using it (maybe it has defaults or profiles?)
For a wide variety of usecases, not for every isolated usecase. Today, AVIF is better for showing people ads^W^W^W web content delivery. This article is titled “JPEG XL vs. AVIF for web use-cases”. The other article recently discussed¹ is subtitled “Investigating JPEG XL's place as a Web image codec” and ends:
> JPEG XL isn't useless; it is genuinely compelling technology for use cases beyond the Web.
It extracts the already quantized DCT coefficients and related data from the JPEG bitstream and re-encodes them with JPEG XL’s more efficient entropy coding and container,
Think of it as zip compression that is specially designed for JPEG and putting the JPEG data in a different/better container.
JPEG is a lossy format. JPEG -> AVIF adds a second loss operation. JPEG to JPEG-XL is lossless but with a smaller file size. So one does not further degrade the jpegs beyond what they were already degraded in creating them in the first place.
AVIF ( or even AV1 itself ) has had massive increase in quality improvements over the past 6 years. JPEG XL was close to release in 2020 and finalised in 2021. A lot of the sentiments hold true back then.
JPEG XL has always been targeting high quality encoding metric first before the lower end low BPP images, which AV1 excels at with or without the last 6 years of improvements.
The current top comments about MP3 and LAME is again about how encoder extract maximum potential. JPEG XL was may be the best in 2021, but has been fighting for survival since then.
There a lot of different images that JPEG XL encode better. Screenshots with text is known to be not something they have optimised for or think it could be good at. Lossless mode may be better. Edit: As one of the other comment here proved my point.
Had all of these, even just a hint of AVIF improvement be told, may be the sentiments would have been a little different. But then again I am not one who would trust the same people who sold me WebP and AOM roadmaps.
But at least AV2 is coming. And JPEG XL is finally in every browser. Hopefully we can all have something even better in the future.
Your impression is correct; when JPEG XL was first introduced, it did just as well or better than AVIF in many cases. But in short, work on JPEG XL encoders slowed down, so they fell behind, and JPEG XL now loses to AVIF in some areas.
As the article points out, this might change yet again in the future, depending on how much AVIF keeps improving and whether JPEG XL development picks up steam again and how far it’ll go.
> I always thought the reasons Apple snubbed Facebook were out of values and principles not business.
Apple is showing a masterclass of how to tow the line perfectly. Or more candily "have the cake and eat it too".
If you ask anyone, what's one company that'll stand up to government requests, most reasonable people would say Apple. Yet, Apple is extremely strategic when it comes to China. It thrives in that country, without being associated with CCP.
Same here - they are happy to partner with Meta, without getting any of the bad "aura".
To be clear, all companies do this just that Apple alone has a successful strategy here. Tim Cook personally gifted the current adminstration with a gold plaque, something none of the other "dirty" CEOs did. Such a public gesture, yet nobody would think that Apple is in bed with the current administration. Its marvelous to see this happen in real time.
> If you ask anyone, what's one company that'll stand up to government requests, most reasonable people would say Apple. Yet, Apple is extremely strategic when it comes to China. It thrives in that country, without being associated with CCP.
You can stand up to government requests when it is legal to do so. Eventually you have to decide to abide by the law or leave the market.
Most people who say this didnt go through the pain of why IE was such a PITA. IE held back web development by years because either they refused to add features or they added features that only worked with Microsoft approved.
Chrome came along and accelerated web platform development since their products relied on a thriving web ecosystem. They did it using open source software, and built out consensus using web platforms.
Chrome is the new IE will only be true if other browsers are out innovating Chrome (not true), or Chrome has abandoned web platform (not true).
There's only one browser that drags their feat adding features, and that's ironically Safari. Firefox too to an extend, but that's mostly mismanagement and lack of resources. Apple has no excuses.
Chrome is the new IE in that it has become an engine/frontend monoculture. Remember those little "Best viewed in IE" badges that used to litter the web because devs stopped testing their sites in Netscape? That's where we're headed now with Chromium/Blink and it's just as bad of a thing now as it was then.
Also worth noting that some of the discrepancies in capability are in features that Google decided to push despite opposition from other members of the consortium (like WebUSB).
I remember the "Best view in Chrome" notices that I get today browsing Japanese web sites. It is already a problem and I have to spoof the browser agent for some web sites to get around Javascript blocks that only allow Chrome through.
> Chrome is the new IE in that it has become an engine/frontend monoculture
That's a strange argument. I dont see HN saying this year all of us are going to buy Android, because iOS has become too popular. That sentiment is only valid is iOS is dragging their feat and if they stop innovating, effectively holding the market back.
I still havent seen an example where Chrome is holding everyone back. If anything, the complaint is the other way - they are doing way too much and we want them to stop.
And for HN crowd to be against that is very silly.
The web is an open standard (nominally, at least), but ceases to be so if a single company controls it. At that point the company’s vision is instead the standard in which nobody else gets meaningful say.
It’s not just Apple. Mozilla has pushed back against Google’s proposals plenty of times too. Google doesn’t always know best and often acts more in their self-interest than in that of the web.
So the issue isn’t that Google is moving too fast or doing too much, but that they’re unilaterally deciding the future of the web, which is not something any single party should be capable of.
> but ceases to be so if a single company controls it.
How does Google or any company control the web? I can launch a website fuckgoogle.com today and Google can do nothing with it. However, I cannot publish fuckapple on Mac Store or App Store.
It's the direction of the web they control, with the various specs involved becoming ever more complex and more difficult to implement in new web engines (complexity as a moat) and with many of the APIs getting added being better suited for surveillance capitalism or as a project for somebody's promotion within Google than for building high quality software.
> Most people who say this didn't go through the pain of why IE was such a PITA.
I did and "Chrome is the new internet explorer" is more accurate than what has been uttered since Chrome split from WebKit, "Safari is the new internet explorer".
IEs problem wasn't that it was behind in features, it was that it used IE-specific plugins and was heavily integrated with Windows Explorer. Safari is and has not been either of those.
But there's also not consumer choice now. If devs are so lazy as to only test on Safari because they absolutely have to, you can bet your bottom dollar they aren't testing Firefox or anything else if it comes along. Therefore, if Apple keeps the Safari monopoly on their platform, you have only the choice of Safari on iOS, and only the choice of Chrome everywhere else. So there's no consumer choice even if you get your preferred outcome here.
Diversity is not an intrinsic good. It only is good inasmuch as it enables other things which are good. If the browser diversity we have (limited though it is) isn't actually providing choice to consumers, I don't see how it provides any value even if we do preserve it.
I think you're being unreasonably uncharitable. Any and all software contains bugs, and I can assure you the piece of code you wrote has bugs. My code has bugs. Google's code has bugs. iOS has bugs. rocket launching software has bugs.
We can put in systems in place to catch bugs. And that's the system that's working here.
Now to the second part of the question -
How did they not catch it before? If it were "easy", it would not have been worth 90k, and hindsight is 20/20 - once you know where to look for, it is all very very obvious.
We haven't built a ComfyUI integration; but all the weights and inference code are available to download. So, it should be pretty easy to point Codex/Claude to it and have it re-arrange stuff to be compatible.
From our POV, this quite an experimental checkpoint. That's why we've dubbed it a research release. Our goal is to share our findings (and checkpoints) along the way to a legit image and video release for Linum v3.
Image release should be out in the coming weeks, so stay tuned for that. Video will take a little longer (we're doing on-going research atm on pixel-space video training).
this is just not true. the market for new grads is extremely bad. Microsoft could easily invest in more early career people, instead they're hiring more senior H1-Bs.
Bad market for new grads is overdetermined. AI, interest rates, etc.
But a contributing fact is flooding the tech market with H-1B visas spikes labor supply, kills workers' leverage and lets companies cheap out on salaries instead of bidding them up.
Yeah but those new grads are too uppity. We tried throwing money at them, but they're more interested in productivity destroying quality of life improvements.
The imported worker, on the other hand, is a more efficient and compliant machine. Maybe if we make those youths as poor as the workers we import, they'll eventually learn some gratitude.
> sure, but there's the obvious counterfactual: if those engineers were scarcer, that level would likely be paid more
There's another option: without a sufficient workforce, the projects just happen somewhere else. Then the local market stagnates, and you end up with very little competition between employers. And the salaries go down to match.
This is not a conjecture. The European tech sector is experiencing exactly this phenomenon. Even in large tech companies, the salaries for the same positions are about 50-100% higher in the US.
Employers benefit from regulations that exist to benefit employers. We should have completely open borders or actually do what's best for citizen workers.
Employers would have to pay more competitive wages if the candidate pool was smaller. Then there is the free legal services given to some workers and not others, that leaves less budget overall for compensation.
They would be employed by another company, and contracted to Microsoft. This is the arrangement for the majority of H1-B employees in general, but I do not know if Microsoft does this.
Tech companies do not generally do this for their product teams, but may do it for their internal IT and reporting systems.
Microsoft does this. my friend an electrical engineer on an h1b worked for them this way. Microsoft contracted a 3rd party where my friend was employed.
and how much pressure do they feel to raise the band over time when theres a constant stream of people coming in form another country who accept anything presented because its still higher than back home
> Digital sovereignty and privacy is at stake.
This is the most strongest argument, and luckily that's the first one. Many ways to solve this so not really a big problem.
> Ontarians’ jobs risk being outsourced
What jobs are being displaced by driverless cars? The best argument here is uber drivers are going to be affected. Who would you rather drive you at 3am if you're a drunk woman? An uber driver or Waymo?
> Public transit could lose riders
What is the goal here? The goal is to move people efficiently and decrease the reliance on human driving, which can cause deaths. Public transportation is vital but again, there are times when subway / buses wont work.
Also, if public transit is a major concern, shouldnt we be asking Uber (see point #2) to go away?
The last two points are super generic, it isnt even worth discussion.
Not convinced with the approach here.
reply