Hacker Newsnew | past | comments | ask | show | jobs | submit | quikoa's commentslogin

Didn't Google refuse adding JpegXL because they claimed there wasn't enough interest? I don't think they refused out of security concerns but maybe I'm misremembering that.

Google argued that duplicating largely (I know JpegXL does support a bit more, but from most users' perspectives, they're largely right) what AVIF provided while being written in an unsafe language was not what they wanted in terms in increasing the attack surface.

And it really was the right move at the time, imo. JXL however now has better implementations and better momentum in the wider ecosystem and not just yet another image format that gets put into chrome and de facto becomes a standard.



Hahaha perfect! Can't believe I never heard this story before.

I can confirm. I found multiple problems in the "official" cjxl encoder back in 2023 contrary to the webp2 (cwp2) implementation where I could not find any bug or error.

If the encoder have obvious problems it is not a big deal, but it doesn't bode well for the decoder.


CVE-2023-0645 in libjxl that year too, and several since

It's also a horrible API. Will start working on the rust lib then. Hopefully it's better, because I really want to use it.

Forcing other companies to override them is a way to prove momentum but it's not a good way to prove momentum.

> duplicating largely what AVIF provided

That's not a great bar since both of them showed up around the same time. And importantly JXL hits many use cases that AVIF doesn't.

> while being written in an unsafe language

They put little emphasis on that part when they were rejecting JXL. If they wanted to call for a safer implementation they could have done that.


Google refused to merge JpegXL as a strategy play to promote AVIF, which was in use by other teams (i think Photos?). Internally, chrome engineers were supportive of jxl but were overridden by leadership.

Do you have actual sources for this? Because the other people commenting about how the newer library removes most of the concerns explains this better than an unsubstantiated speculation about promoting AVIF.

If you look at the issue tracker, the creator of Webp killed it because of untrue claims there was no interest or advantages over existing formats.

Concerns about the implementation only came up after years of pushback forced google ton reconsider.


> If you look at the issue tracker, the creator of Webp killed it because of untrue claims

I think for most modern software it's difficult to name the creator, but if you had to for webp, it would be hard to argue that it's anyone but Jyrki Alakuijala, who is in fact one of the co-creators of jpegxl and the person backing up the long-term support of the rust jxl-rs implementation, so I'm not even going to ask for a source here because it's just not true.


AFAIK Jyrki came after WebP was already announced to add lossless support; rather I’d consider Skal the creator inasmuch as it was originally just an image container for VP8 intra. He was working on WebP2 at the time Google rejected JPEG-XL and also was not involved in that decision.

I designed the lossless format and its initial encoder. Zoltán Szabadka wrote the initial lossless decoder.

On2 Technologies had designed the lossy format and its initial encoder/decoder. Skal improved on the encoder (rewriting it for better quality, inventing workarounds for the YUV420 sampling quality issues), but did not change the format's image-related aspects that On2 Technologies had come up with for VP8 video use.

In the end stage of lossless productization (around February 2012) Skal had minor impact on the lossless format:

1. He asked it to have the same size limitations (16383x16383 pixels) like lossy.

2. He wanted to remove some expressivity for easier time for hardware implementations, perhaps a 0.5 % hit on density.

Skal also took care of integrating the lossless format into the lossy as an alpha layer.


>so I'm not even going to ask for a source here because it's just not true.

Well it is up to you to decide. The link was submitted a dozen of times on HN and the whole thing was well reported. And Jyrki Alakuijala already classify its creator status.


It's been 3 years, I might have people mixed up, but that was the justification at the time.

>an unsubstantiated speculation about promoting AVIF.

They deliberately made up a flawed test to show AVIF is better than JPEG XL. When most evidences shows contrary.


Bug tracker where they lied about "not enough interest".

Not quite. The ads themselves aren't deleted but only not displayed for a subset of keywords. If the ads were deleted no keyword would be able to show these.


If there are multiple ads (and why would there not be multiple ads?), deleting the one advertised using keyword X does nothing to the one advertised using keyword Y.


This website appears to be very AI heavy in articles. I think it's fair to say these articles are biased because of that.


You don't have to win from a megacorp. Just add a bit of friction to some of their actions. Many small frictions do stack up.


Someone correct me if I'm mistaken but don't CAD programs rely on a geometric modeling kernel? From what I understand this part is incredibly hard to get right and the best implementations are proprietary. No LLM is going to be able to get to that level anytime soon.


Sounds like GP is just in need for a G-Code to DXF converter when they mention "fringe stuff, cnc machine files from the 80's/90's" as answer to a sibling comment, though.

There are great FOSS CAD tools available nowadays (LibreCAD, FreeCAD, OpenSCAD etc.), especially for people who only need 2% of a feature set. But then again, I doubt that GP is really in need of a CAD software, or even writing one with the help of Gemini.


It would be nice if nuclear fusion had the AI budget.


Fusion will at best have a few dozen sales once it's commercially viable and then take decades to realise, but you can sell AI stuff to millions of customers for $20 / month each and do it today.


They rarely even provide the projects either or even the type of project. I'd like to see all these awesome results that are build with AI (preferably not web related).


Could you share a link to the coding live streams? I can't find it.


I found this in the article: https://www.youtube.com/watch?v=42AzKZRNhsk


Small developers need to be easy to contact. Meanwhile Google is notorious for being difficult to get human support. Seems fair.


These models could still be useful when rendered. But when animated or in a game probably less so. Maybe as a prototype to get funding and hire an artist.


There are countless troves of CC-licensed assets that would be better suited.


I'd like to see an AI trained to search for an asset!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: