frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Open in hackernews

Why JPEG XL Ignoring Bit Depth Is Genius (and Why AVIF Can't Pull It Off)

https://www.fractionalxperience.com/ux-ui-graphic-design-blog/why-jpeg-xl-ignoring-bit-depth-is-genius
53•Bogdanp•2h ago

Comments

kiicia•1h ago
jpeg xl is fantastic, yet autocratic google wants to force inferior format
homebrewer•1h ago
Mozilla also isn't interested in supporting it, it's not just Google. I also often see these articles that tout jpeg-xl's technical advantages, but in my subjective testing with image sizes you would typically see on the web, avif wins every single time. It not only produces fewer artifacts on medium-to-heavily compressed images, but they're also less annoying: minor detail loss and smoothing compared to jpeg-xl's blocking and ringing (in addition to detail loss; basically the same types of artifacts as with the old jpeg).

Maybe there's a reason they're not bothering with supporting xl besides misplaced priorities or laziness.

Retric•1h ago
JPEG-XL is optimized for the low to zero levels of compression which isn’t as commonly used on the web, but definitely fills a need.

Google citied insufficient improvements which is a rather ambiguous statement. Mozilla seems more concerned with the attack surface.

formerly_proven•7m ago
JPEG XL seems optimally suited for media and archival purposes and of course this is something you’d want to mostly do through webapps nowadays. Even relatively basic uses cases like Wiki Commons is basically stuck on JPEG for these purposes.

For the same reason it would be good if a future revision of PDF/A would include JPEG XL, since it doesn't really have any decent codecs for low-loss (but not losless) compression (e.g. JPEG sucks at color schematics/drawings and losless is impractically big for them). It did get JP2 but support for that is quite uncommon.

OneDeuxTriSeiGo•1h ago
> Mozilla also isn't interested in supporting it

Mozilla is more than willing to adopt it. They just won't adopt the C++ implementation. They've already put into writing that they're considering adopting it when the rust implementation is production ready.

https://github.com/mozilla/standards-positions/pull/1064

masklinn•1h ago
You have a really strange interpretation of the word “consider”.
mistercow•1h ago
Seems like the normal usage to me. The post above lists other criteria that have to be satisfied, beyond just being a Rust implementation. That would be the consideration.
masklinn•43m ago
Mozilla indicates that they are willing to consider it given various prerequisite. GP translates that to being “more than willing to adopt it”. That is very much not a normal interpretation.
OneDeuxTriSeiGo•30m ago
From the link

> To address this concern, the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust, and integrate this decoder into Firefox. If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it.

That is a perfectly clear position.

m-schuetz•1h ago
Now I'm feeling a bit less bad for not using Firefox anymore. Not using it because it's C++ is <insert terms that may not be welcome on HN>
mistercow•1h ago
Multiple severe attacks on browsers over the years have targeted image decoders. Requiring an implementation in a memory safe language seems very reasonable to me, and makes me feel better about using FF.
kouteiheika•57m ago
So you think it's silly to not want to introduce new potentially remotely-exploitable CVEs in one of the most important pieces of software (the web browser) on one's computer? Or are you implying those 100k lines of multithreaded C++ code are bug-free and won't introduce any new CVEs?
archerx•39m ago
It’s crazy how people think using Rust will magically make your code bug and vulnerability free and don’t think that the programmer more than the languages contribute to those problems…
OneDeuxTriSeiGo•34m ago
It's not about being completely bug free. Safe rust is going to be reasonably hardened against exploitable decoder bugs which can be converted into RCEs. A bug in safe rust is going to be a hell of a lot harder to turn into an exploit than a bug in bog standard C++.
mistercow•28m ago
> and don’t think that the programmer more than the languages contribute to those problems

This sounds a lot like how I used to think about unit testing and type checking when I was younger and more naive. It also echoes the sentiments of countless craftspeople talking about safety protocols and features before they lost a body part.

Safety features can’t protect you from a bad programmer. But they can go a long way to protect you from the inevitable fallibility of a good programmer.

drob518•20m ago
Straw-man much?
OneDeuxTriSeiGo•36m ago
It's not just "C++ bad". It's "we don't want to deal with memory errors in directly user facing code that parses untrusted contents".

That's a perfectly reasonable stance.

demetris•57m ago
I did some reading recently, for a benchmark I was setting up, to try and understand what the situation is. It seems things have started changing in the last year or so.

Some links from my notes:

https://www.phoronix.com/news/Mozilla-Interest-JPEG-XL-Rust

https://news.ycombinator.com/item?id=41443336 (discussion of the same GitHub comment as in the Phoronix site)

https://github.com/tirr-c/jxl-oxide

https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 (land initial jpegxl rust code pref disabled)

In case anyone is curious, here is the benchmark I did my reading for:

https://op111.net/posts/2025/10/png-and-modern-formats-lossl...

AlienRobot•1h ago
I wish they separated the lossless codec into "WebPNG." WebP is better than PNG, but it's too risky to use (and tell people to use) a lossless format that is lossy if you forget to use a setting.
est•1h ago
> JPEG XL’s Radical Solution: Float32 + Perceptual Intent

So 2^32 bit depth? 4 bytes seems an overkill.

fps-hero•1h ago
Did you miss the point of the article? JPEG-XL encoding doesn't rely on quantisation to achieve its performance goals. Its a bit like how GPU shaders use floating point arithmetic internally but output quantised values for the bit depth of the screen.
est•54m ago
> Did you miss the point of the article?

Sorry I missed. How is the "floating point" stored in .jxl files?

Float32 has to be serialized one way or another per pixel, no?

jstanley•43m ago
No, JPEG is not a bitmap format.
wongarsu•14m ago
The cliff notes version is that JPEG and JPEG XL don't encode pixel values, they encode the discrete cosine transform (like a Fourier transform) of the 2d pixel grid. So what's really stored is more like the frequency and amplitude of change of pixels than individual pixel values, and the compression comes from the insight that some combinations of frequency and amplitude of color change are much more perceptible than others
diffuse_l•1h ago
I think the article could be better and get the point across with half the length and without the second half of it being full of ai generated list of advantages, or using that space to give some more technical information
evertedsphere•1h ago
the article could be better if it weren't entirely "ai generated"
zokier•1h ago
Working with single fixed bit depth is imho different than being bit-depth agnostic. Same argument could be made about color spaces too.
WithinReason•58m ago
Yes, this is great, but why don't we make the same argument for resolution too? I think we should!
colonwqbang•15m ago
So they "ignore" bit depth by using 32 bits for each sample. This may be a good solution but it's not really magic. They just allocated many more bits than other codecs were willing to.

It also seems like a very CPU-centric design choice. If you implement a hardware en/decoder, you will see a stark difference in cost between one which works on 8/10 vs 32 bits. Maybe this is motivated by the intended use cases for JPEG XL? Or maybe I've missed the point of what JPEG XL is?

Declarative database schema migrations – yay or nay?

1•astronautas•2m ago•0 comments

Solusi aman cara membatalkan pengajuan shopee pinjam

1•tampan•6m ago•0 comments

Annual hours worked per worker in OECD countries

https://figure.nz/chart/uzEoMsIEuL9cjdBS
1•surprisetalk•6m ago•0 comments

"Let people enjoy things "

https://tadaima.bearblog.dev/poptimism-backlash/
1•surprisetalk•6m ago•0 comments

How to Implement an Operation Warp Speed for Rare Earths

https://ifp.org/how-to-implement-an-operation-warp-speed-for-rare-earths/
1•surprisetalk•7m ago•0 comments

Explaining the Standard Model [video]

https://www.youtube.com/watch?v=0yjxqMoX-y8
1•surprisetalk•7m ago•0 comments

There's no realistic alternative to AWS and the other hyperscalers

https://mastodon.world/@Mer__edith/115445701583902092
1•Vinnl•8m ago•0 comments

"Plant Math" Can Help Predict the Climate's Future

https://nautil.us/how-plant-math-can-help-predict-the-climates-future-1237997/
2•fleahunter•8m ago•0 comments

People are having fewer kids. Their choice is transforming the economy

https://www.npr.org/2025/10/27/nx-s1-5576355/population-babies-capitalism
1•cebert•9m ago•1 comments

Show HN: Wranglr – A programmable CLI for tracking dev work

https://github.com/everettraven/wranglr
1•everettraven•10m ago•0 comments

US pushes regulators on connecting data centers to grid

https://www.reuters.com/business/energy/us-pushes-regulators-connecting-data-centers-grid-2025-10...
1•giuliomagnifico•13m ago•0 comments

AI Attempts to Guess the Popularity of Linux DEs: Gnome, KDE, Hyprland, and More

https://grigio.org/ai-attempts-to-guess-the-popularity-of-linux-desktop-environments-gnome-kde-hy...
1•grigio•14m ago•0 comments

Show HN: Estimating startup viability using Nobel Prize economics

https://tom-dickson.com/blog/startup-viability-calculator/
1•tajd•15m ago•0 comments

Show HN: SSL Certificate Expiration in Calendar App

https://sslcalendar.com
1•weddpros•15m ago•0 comments

MiniMax-M2, a Mini open-source model built for Max coding and agentic workflows

https://huggingface.co/MiniMaxAI/MiniMax-M2
1•grigio•16m ago•0 comments

Bats eat the birds they pluck from the sky while on the wing

https://arstechnica.com/science/2025/10/tracking-bats-as-they-hunt-birds-in-the-skies-above-europe/
2•sipofwater•16m ago•0 comments

eBPF Observability and Continuous Profiling with Parca

https://fatihkoc.net/posts/ebpf-parca-observability/
1•fatihkocnet•17m ago•0 comments

Screenwriter Eric Heisserer on Lights Out, the Rules of Horror

https://filmmakermagazine.com/99327-screenwriter-eric-heisserer-lights-out-the-rules-of-horror-an...
1•suioir•20m ago•0 comments

My math setup (as a software engineer)

https://danielfalbo.substack.com/p/my-math-setup
1•danielfalbo•20m ago•0 comments

How Much Does It Cost to Charge an Electric Vehicle?

https://www.caranddriver.com/news/a45036169/electric-vehicle-ev-cost-to-charge/
1•cebert•23m ago•0 comments

NASA, DEI, fraud and the failure of Orion [video]

https://www.youtube.com/watch?v=FIONXPbIkVo
3•MrBuddyCasino•24m ago•0 comments

Challenge: An asymmetric key system that does everything

1•oiko_nomikos•24m ago•0 comments

The Chinese Box and Turing Test: Is AI really intelligent?

https://www.theregister.com/2025/10/27/ai_intelligence_opinion/
1•sipofwater•26m ago•0 comments

Real Estate Is Entering Its AI Slop Era

https://www.wired.com/story/real-estate-is-entering-its-ai-slop-era/
3•thm•28m ago•0 comments

MapTiler GeoSplats

https://www.maptiler.com/geosplats/
1•maelito•28m ago•0 comments

Show HN: Automate Robot Data Quality Improvement

https://github.com/RoboticsData/score_lerobot_episodes
1•machinelearning•32m ago•1 comments

Kannada __ Robert J. Zydenbos __

https://hasp.ub.uni-heidelberg.de/catalog/book/736
1•CZEC•33m ago•5 comments

'The sound changes': To electrify boats, make them fly

https://www.bbc.com/future/article/20251023-how-hydrofoil-boats-could-cut-emissions-from-water-tr...
1•caidan•33m ago•0 comments

The perfect AWS storm has blown over, but the climate is only getting worse

https://www.theregister.com/2025/10/27/aws_outage_opinion/
2•sipofwater•34m ago•0 comments

RSS Feeds Discovery Strategies

https://blog.burkert.me/posts/rss_discovery_strategies/
2•curioussquirrel•37m ago•0 comments