Google mengembalikan JPEG XL ke Chrome
Google mengumumkan decoding JPEG XL dimulai dengan Chrome 155 setelah eksperimen sebelumnya dihapus.
Google mengumumkan decoding JPEG XL dimulai dengan Chrome 155 setelah eksperimen sebelumnya dihapus. Edisi 7 Oktober ini mengulas umpan balik pengembang, decoder Rust yang baru, klaim kompresi yang bersaing, dan fallback penerapan, kemudian melihat artefak bukti matematika yang baru diterbitkan OpenAI dan desain hash-in-flash sinkhole DNS ESP32-C3.
Baca edisi tertulis (Inggris) ↗
Isi video ini
- Pengumuman Chrome diterbitkan pada 6 Oktober 2026 dan menyebutkan Chrome 155. Ini tidak menetapkan bahwa setiap pengunjung situs web sudah menjalankan versi yang didukung.
- Google menghargai umpan balik pengembang yang gigih dan proses Interop. Decoder jxl-rs menggunakan Rust dan operasi vektor yang dioptimalkan, sementara area unsafe kecil yang telah diperiksa dan sandbox browser tetap ada.
- Peningkatan kompresi 30–50% yang diiklankan Google menggunakan JPEG sebagai dasar. Penghematan sebenarnya tergantung pada gambar, pengaturan encoder, dan kualitas visual.
- Perbandingan encoder Gianni Rosato pada bulan September mendukung AVIF di seluruh rentang fidelitas lossy yang diujinya. Dia mengembangkan alat AVIF yang bersaing; hasilnya dan klaim dasar JPEG Google mengukur perbandingan yang berbeda.
- Bandingkan format pada gambar representatif dan pertahankan fallback yang kompatibel. JPEG XL juga mendukung transcoding lossless yang dapat dibalik dari file JPEG yang ada.
- OpenAI merilis 722 manuskrip yang dikelompokkan menjadi 372 keluarga, dengan verifikasi bervariasi dan banyak formalisasi Lean. Model tersebut tetap tidak dirilis, dan angka komputasi setara Pro bukanlah harga eceran maupun jaminan waktu yang berlalu.
- Pembuat ESP32-C3 melaporkan penggunaan RAM sekitar 50 KB dengan menyimpan hash domain yang diurutkan dalam flash. Pemblokiran tingkat DNS memiliki batasan domain yang sama dan resolver alternatif; benturan hash dapat menyebabkan overblocking. Hasil perangkat keras tidak diukur secara independen untuk episode ini.
Transkrip terjemahan
Diterjemahkan dari narasi asli bahasa Inggris. Audio dan teks tersedia yang dikontrol oleh YouTube.
Mengapa Chrome mengembalikan JPEG XL?
0:00 Anda mungkin berpikir Google mengubur JPEG XL. Chrome mengembalikannya, setelah menghapus dukungan eksperimental, dan Rust membantunya masuk. Dalam video ini, mengapa Google membalikkan arah? Dan haruskah Anda mengubah pipeline gambar Anda? Ini hari Rabu, tujuh Oktober, dan ini adalah The Daily Diff. Ingat satu detail. JPEG Anda yang sudah ada memiliki cara untuk kembali.
0:20 Pada hari Selasa, Google mengumumkan decoding JPEG XL dimulai dengan Chrome seratus lima puluh lima. Hari ini pengumuman tersebut naik ke Hacker News, bersamaan dengan bukti matematika OpenAI dan papan dua dolar yang memblokir domain iklan. Eksperimen Chrome sebelumnya berakhir pada dua puluh dua puluh tiga.
Mengapa format yang ditolak mendapat kesempatan lagi?
0:35 Penjelasan Google mencakup kurangnya minat ekosistem, yang canggung ketika browser terbesar mengontrol apakah ekosistem dapat benar-benar menggunakan milik Anda. Posting baru ini menghargai umpan balik pengembang yang gigih, termasuk proses Interop. Orang-orang yang meminta ini terus meminta, dan Google sekarang menunjuk pada tes browser yang dimaksudkan untuk membuat format berperilaku konsisten. Pengumuman tersebut menghargai kontributor termasuk Helmut Januschka.
0:57 Terkadang roadmap yang paling efektif adalah menolak untuk menutup masalah tersebut.
Apa yang berubah di dalam decoder?
1:01 Perubahan implementasi terbesar adalah decoder bernama jay ex ell R S, ditulis dalam Rust. Decoder gambar memasukkan file rumit yang disediakan oleh orang asing, yang menjadikannya tempat yang spektakuler untuk secara tidak sengaja mempercayai internet. Rust membantu mencegah kelas kesalahan memori sebelum menjadi kerentanan browser. Google masih mempertahankan sandbox, dan implementasinya masih mengandung area unsafe kecil yang telah ditinjau dengan cermat. Keamanan memiliki lapisan, karena kenyataan terus menemukan celah.
1:27 Google mengatakan fuzzing dan tinjauan kode AI tidak menemukan bug keamanan memori dalam sejarah decoder ini. Itu adalah laporan yang berguna dari tim yang mengirimkannya. Penyerang di masa depan tidak mungkin menerima postingan blog sebagai kontrak yang mengikat. Pertanyaan pertama terjawab. Tekanan pengembang dan decoder Rust yang dioptimalkan membuka kembali pintu. Google membalikkan keputusan dengan rekayasa di baliknya, yang diizinkan bahkan di internet. Sekarang benchmark slide deck.
Apakah file yang lebih kecil mengalahkan AVIF?
1:48 Google mengiklankan kompresi tiga puluh hingga lima puluh persen lebih baik daripada JPEG. Unduhan yang lebih kecil dapat membantu pengguna dan tagihan bandwidth Anda, tetapi rentang itu tergantung pada apa yang Anda encode dan bagaimana Anda membandingkan kualitas. Insinyur kompresi Gianni Rosato menerbitkan perbandingan September di mana encoder avif modern mengalahkan JPEG XL di seluruh rentang fidelitas yang diujinya. Dia mengerjakan alat avif yang bersaing, jadi simpan insentif itu di samping grafik. Perbandingan ini menggunakan dasar yang berbeda.
2:12 Mengalahkan JPEG lama menyisakan ruang bagi avif untuk memenangkan beban kerja. Google sendiri merekomendasikan untuk mencoba kedua format, yang merupakan saran yang luar biasa praktis untuk pengumuman peluncuran. Daya tarik JPEG XL lainnya termasuk rentang dinamis tinggi, gambar lossless, dan decoding progresif yang detail. Komunitas menerbitkan demo interaktif untuk menjelajahi format. Audiens Anda dapat melihat gambar yang berguna saat sisanya tiba. Untuk penerapan, pertahankan gambar fallback, dan verifikasi dukungan di browser yang
2:37 benar-benar dijalankan pelanggan Anda. Pengumuman tersebut menyebutkan Chrome seratus lima puluh lima. Itu memberi Anda versi target, dan analitik Anda memberi tahu Anda kapan audiens Anda mencapainya. Pertanyaan kedua terjawab. Uji gambar asli Anda sebelum mengubah pipeline, dan pertahankan jalur kompatibilitas. Format gambar yang menghemat byte berguna. Migrasi yang menyembunyikan tombol checkout Anda adalah interpretasi minimalisme yang mahal. Sementara itu, OpenAI menerbitkan manuskrip matematika dan artefak
Apa sebenarnya yang diterbitkan OpenAI?
3:00 bukti pendukung pada hari Selasa. Repositori tersebut berisi tujuh ratus dua puluh dua manuskrip, dikelompokkan ke dalam keluarga terkait. Hitungan utama mencakup argumen pendamping dan bukti alternatif, jadi baca apa yang sebenarnya diklaim oleh setiap makalah. Banyak yang memiliki bukti formal dalam Lean, yang memungkinkan komputer memeriksa deduksi matematika. Yang lain masih menunggu formalisasi, dan OpenAI secara eksplisit memperingatkan bahwa
3:21 beberapa hasil yang tidak terformalisasi mungkin memiliki masalah. Repositori ini menyerahkan materi yang dapat diperiksa dan ditantang oleh para peneliti. Model tersebut tetap tidak dirilis. OpenAI mengatakan setiap hasil menggunakan sekitar tiga jam komputasi berpikir setara ChatGPT Pro rata-rata. Itu menggambarkan upaya komputasi. Itu tidak memberi Anda jaminan waktu nyata maupun harga eceran untuk menghasilkan sebuah teorema.
3:40 Rilis ini mengikuti konsultasi dengan kelompok penasihat matematika independen, dan mencakup proses revisi dan kutipan. Akademi mendapatkan tumpukan tugas baru, ditambah kemampuan yang jauh lebih berguna untuk menunjuk ke halaman persis yang perlu diperbaiki. Pengelola Lean merekomendasikan untuk mengompilasi bagian-bagian kecil pada satu waktu. Bahkan terobosan matematika akhirnya bertemu musuh kuno perangkat lunak, menyelesaikan pembangunan.
Bagaimana papan dua dolar memblokir domain?
4:03 Akhirnya, pemblokir iklan DNS sumber terbuka berjalan pada papan mikrokontroler dua dolar kecil. Trik pembuatnya adalah menyimpan hash domain yang diurutkan dalam flash, sehingga daftar blokir tidak harus berada di memori kerja yang langka. Proyek ini melaporkan penggunaan RAM sekitar lima puluh kilobyte. Ini mencari domain yang diminta di tabel flash, memblokir yang cocok dan meneruskan kueri lain ke hulu. Router Anda dapat memperoleh penjaga kecil dengan daftar tamu yang sangat spesifik. Penyaringan DNS bekerja pada tingkat domain.
4:28 Iklan yang disajikan dari domain yang sama dengan konten yang berguna dapat lolos, dan klien yang menggunakan resolver lain dapat melewatinya. Pertahankan ekspektasi Anda lebih kecil dari papan, yang merupakan target ukuran yang menuntut. Dan detail tentang JPEG Anda yang sudah ada?
Bisakah JPEG Anda yang sudah ada bergabung dalam kembalinya?
4:40 JPEG XL mendukung transcoding JPEG lossless, dengan jalur untuk merekonstruksi JPEG asli. Itu memberi arsip gambar lama opsi migrasi tanpa kehilangan kualitas generasi lain. Uji trade-off penyimpanan dan pengiriman. Jika Anda lebih suka membaca ini daripada mendengarkannya, the diff mendarat di kotak masuk Anda setiap pagi, gratis di the daily diff dot dev, tautan di bawah. Jadi putusan hari ini, SHIP IT.
Mengapa saya harus mengirimkan decoder dan menguji migrasi?
4:58 Saya akan mengirimkan decoder tambahan karena dukungan browser memberi pengembang pilihan nyata, dan saya akan menguji migrasi pada gambar kami sendiri. Berlangganan, tekan bel, dan beri tahu saya di komentar jika Anda akan mengecapnya secara berbeda. Dan itu perbedaannya untuk hari ini. Saya Niko dari Axrisi. Gabungkan secara bertanggung jawab. Gabungkan secara bertanggung jawab.
Sumber
- Shipping JPEG XL in ChromeChrome for Developers
- JPEG XL prototype and November 2022 removal discussionChromium Blink developers
- Contemporaneous JPEG XL deprecation commentaryFree Software Foundation
- The case against JPEG XL — competing-encoder benchmarkGianni Rosato
- JPEG XL FAQ and reversible JPEG transcodingJPEG XL community
- HTML picture element and fallback selectionMDN Web Docs
- Progressive loading demoJPEG XL community
- Distance versus effort visualizerJPEG XL community
- Sharing AI progress in mathematicsOpenAI
- Mathematical manuscripts and proof artifactsOpenAI on GitHub
- Lean formalization library build notesOpenAI on GitHub
- ESP32-C3 hash-in-flash DNS ad blockerM-Abozaid on GitHub



