# Google ນໍາ JPEG XL ກັບຄືນສູ່ Chrome

Published: 2026-10-07

Google ປະກາດການຖອດລະຫັດ JPEG XL ໂດຍເລີ່ມຕົ້ນດ້ວຍ Chrome 155 ຫຼັງຈາກການທົດລອງກ່ອນໜ້ານີ້ຖືກລຶບອອກ. ສະບັບວັນທີ 7 ຕຸລານີ້ກວດກາຄໍາຄິດເຫັນຂອງນັກພັດທະນາ, ເຄື່ອງຖອດລະຫັດ Rust ໃໝ່, ການຮຽກຮ້ອງການບີບອັດທີ່ແຂ່ງຂັນ ແລະ ການສໍາຮອງການນໍາໃຊ້, ຈາກນັ້ນພິຈາລະນາສິ່ງປະດິດສ້າງການພິສູດທາງຄະນິດສາດທີ່ OpenAI ເຜີຍແຜ່ໃໝ່ ແລະ ການອອກແບບ hash-in-flash ຂອງ ESP32-C3 DNS sinkhole.

Canonical: https://thedailydiff.dev/lo/video/chrome-jpeg-xl-comeback/

## ສິ່ງທີ່ວິດີໂອນີ້ກວມເອົາ

- ການປະກາດ Chrome ຖືກເຜີຍແຜ່ໃນວັນທີ 6 ຕຸລາ 2026 ແລະ ຕັ້ງຊື່ Chrome 155. ມັນບໍ່ໄດ້ຢືນຢັນວ່າທຸກຜູ້ເຂົ້າຊົມເວັບໄຊທ໌ໄດ້ໃຊ້ເວີຊັນທີ່ຮອງຮັບແລ້ວ.
- Google ຍົກຍ້ອງຄໍາຄິດເຫັນຂອງນັກພັດທະນາຢ່າງຕໍ່ເນື່ອງ ແລະ ຂະບວນການ Interop. ເຄື່ອງຖອດລະຫັດ jxl-rs ໃຊ້ Rust ແລະ ການປະຕິບັດງານ vector ທີ່ດີທີ່ສຸດ, ໃນຂະນະທີ່ພື້ນທີ່ທີ່ບໍ່ປອດໄພຂະໜາດນ້ອຍທີ່ໄດ້ຮັບການກວດກາ ແລະ sandbox ຂອງ browser ຍັງຄົງຢູ່.
- ການປັບປຸງການບີບອັດ 30–50% ທີ່ Google ໂຄສະນາໃຊ້ JPEG ເປັນພື້ນຖານ. ການປະຢັດຕົວຈິງແມ່ນຂຶ້ນກັບຮູບພາບ, ການຕັ້ງຄ່າເຄື່ອງເຂົ້າລະຫັດ ແລະ ຄຸນນະພາບສາຍຕາ.
- ການປຽບທຽບເຄື່ອງເຂົ້າລະຫັດໃນເດືອນກັນຍາຂອງ Gianni Rosato ສະໜັບສະໜູນ AVIF ໃນທົ່ວຊ່ວງຄວາມສັດຊື່ແບບສູນເສຍທີ່ລາວທົດສອບ. ລາວພັດທະນາເຄື່ອງມື AVIF ທີ່ແຂ່ງຂັນກັນ; ຜົນໄດ້ຮັບຂອງລາວ ແລະ ການຮຽກຮ້ອງພື້ນຖານ JPEG ຂອງ Google ວັດແທກການປຽບທຽບທີ່ແຕກຕ່າງກັນ.
- ປຽບທຽບຮູບແບບໃນຮູບພາບທີ່ເປັນຕົວແທນ ແລະ ຮັກສາການສໍາຮອງທີ່ເຂົ້າກັນໄດ້. JPEG XL ຍັງຮອງຮັບການປ່ຽນລະຫັດແບບປີ້ນກັບກັນໄດ້, ບໍ່ສູນເສຍຄຸນນະພາບຂອງໄຟລ໌ JPEG ທີ່ມີຢູ່ແລ້ວ.
- OpenAI ປ່ອຍເອກະສານ 722 ສະບັບທີ່ຈັດກຸ່ມເປັນ 372 ຄອບຄົວ, ດ້ວຍການກວດສອບທີ່ຫຼາກຫຼາຍ ແລະ ການສ້າງແບບ Lean ຢ່າງເປັນທາງການຈໍານວນຫຼາຍ. ຮູບແບບຍັງບໍ່ຖືກປ່ອຍອອກມາ, ແລະ ຕົວເລກການຄິດໄລ່ທີ່ທຽບເທົ່າກັບ Pro ບໍ່ແມ່ນລາຄາຂາຍຍ່ອຍ ຫຼື ການຮັບປະກັນເວລາທີ່ຜ່ານໄປ.
- ຜູ້ສ້າງ ESP32-C3 ລາຍງານການໃຊ້ RAM ປະມານ 50 KB ໂດຍການເກັບຮັກສາ hashes ໂດເມນທີ່ຈັດຮຽງໄວ້ໃນ flash. ການບລັອກລະດັບ DNS ມີຂໍ້ຈໍາກັດຂອງໂດເມນດຽວກັນ ແລະ ຕົວແກ້ໄຂທາງເລືອກ; ການຂັດກັນຂອງ hash ສາມາດບລັອກເກີນໄປ. ຜົນໄດ້ຮັບຂອງຮາດແວບໍ່ໄດ້ຖືກວັດແທກເອງສໍາລັບຕອນນີ້.

## ບົດ

- 0:00 ເປັນຫຍັງ Chrome ຈຶ່ງນໍາ JPEG XL ກັບຄືນມາ?
- 0:33 ເປັນຫຍັງຮູບແບບທີ່ຖືກປະຕິເສດຈຶ່ງໄດ້ຮັບໂອກາດອີກ?
- 1:01 ມີຫຍັງປ່ຽນແປງພາຍໃນເຄື່ອງຖອດລະຫັດ?
- 1:47 ໄຟລ໌ທີ່ນ້ອຍກວ່າຊະນະ AVIF ບໍ?
- 2:56 OpenAI ໄດ້ເຜີຍແຜ່ຫຍັງແທ້ໆ?
- 4:03 ແຜ່ນສອງໂດລາບລັອກໂດເມນໄດ້ແນວໃດ?
- 4:38 JPEG ທີ່ມີຢູ່ແລ້ວຂອງທ່ານສາມາດເຂົ້າຮ່ວມການກັບມາໄດ້ບໍ?
- 4:58 ເປັນຫຍັງຂ້ອຍຈຶ່ງຕ້ອງສົ່ງເຄື່ອງຖອດລະຫັດ ແລະ ທົດສອບການຍ້າຍ?

## ບົດບັນທຶກທີ່ແປແລ້ວ

ແປຈາກຄຳບັນຍາຍຕົ້ນສະບັບພາສາອັງກິດ. ສຽງ ແລະ ຄຳບັນຍາຍທີ່ມີໃຫ້ແມ່ນຄວບຄຸມໂດຍ YouTube.

### ເປັນຫຍັງ Chrome ຈຶ່ງນໍາ JPEG XL ກັບຄືນມາ?

0:00 ເຈົ້າອາດຈະຄິດວ່າ Google ຝັງ JPEG XL. Chrome ກໍາລັງນໍາມັນກັບຄືນມາ, ຫຼັງຈາກລຶບການຮອງຮັບການທົດລອງອອກ, ແລະ Rust ໄດ້ຊ່ວຍໃຫ້ມັນຜ່ານເຂົ້າໄປໄດ້. ໃນວິດີໂອນີ້, ເປັນຫຍັງ Google ຈຶ່ງປ່ຽນໃຈ? ແລະເຈົ້າຄວນປ່ຽນທໍ່ສົ່ງຮູບພາບຂອງເຈົ້າບໍ? ມັນແມ່ນວັນພຸດ, ວັນທີເຈັດຕຸລາ, ແລະນີ້ແມ່ນ The Daily Diff. ຈື່ລາຍລະອຽດໜຶ່ງໄວ້. JPEG ທີ່ມີຢູ່ແລ້ວຂອງທ່ານມີວິທີທີ່ຈະກັບມາຄັ້ງນີ້.

0:20 ໃນວັນອັງຄານ, Google ໄດ້ປະກາດການຖອດລະຫັດ JPEG XL ໂດຍເລີ່ມຕົ້ນດ້ວຍ Chrome ໜຶ່ງຮ້ອຍຫ້າສິບ ຫ້າ. ມື້ນີ້ການປະກາດໄດ້ຂຶ້ນ Hacker News, ພ້ອມກັບການຖິ້ມການພິສູດທາງຄະນິດສາດຂອງ OpenAI ແລະ ແຜ່ນສອງໂດລາທີ່ບລັອກ ໂດເມນໂຄສະນາ. ການທົດລອງກ່ອນໜ້ານີ້ຂອງ Chrome ສິ້ນສຸດລົງໃນປີສອງພັນຊາວສາມ.

### ເປັນຫຍັງຮູບແບບທີ່ຖືກປະຕິເສດຈຶ່ງໄດ້ຮັບໂອກາດອີກ?

0:35 ຄໍາອະທິບາຍຂອງ Google ປະກອບມີຄວາມສົນໃຈຂອງລະບົບນິເວດບໍ່ພຽງພໍ, ເຊິ່ງເປັນເລື່ອງທີ່ໜ້າອຶດອັດເມື່ອ browser ທີ່ໃຫຍ່ທີ່ສຸດຄວບຄຸມວ່າລະບົບນິເວດສາມາດ ໃຊ້ສິ່ງຂອງເຈົ້າໄດ້ແທ້ໆ. ຂໍ້ຄວາມໃໝ່ຍົກຍ້ອງຄໍາຄິດເຫັນຂອງນັກພັດທະນາຢ່າງຕໍ່ເນື່ອງ, ລວມທັງຂະບວນການ Interop. ຄົນທີ່ຮ້ອງຂໍສິ່ງນີ້ຍັງສືບຕໍ່ຮ້ອງຂໍ, ແລະ Google ປະຈຸບັນຊີ້ໄປຫາການທົດສອບ browser ທີ່ມີຈຸດປະສົງເພື່ອເຮັດໃຫ້ຮູບແບບເຮັດວຽກຢ່າງສອດຄ່ອງ. ການປະກາດຍົກຍ້ອງຜູ້ປະກອບສ່ວນລວມທັງ Helmut Januschka.

0:57 ບາງຄັ້ງແຜນທີ່ເສັ້ນທາງທີ່ມີປະສິດທິພາບທີ່ສຸດແມ່ນການປະຕິເສດທີ່ຈະປິດບັນຫາ.

### ມີຫຍັງປ່ຽນແປງພາຍໃນເຄື່ອງຖອດລະຫັດ?

1:01 ການປ່ຽນແປງການປະຕິບັດທີ່ໃຫຍ່ທີ່ສຸດແມ່ນເຄື່ອງຖອດລະຫັດທີ່ເອີ້ນວ່າ jay ex ell R S, ຂຽນໃນ Rust. ເຄື່ອງຖອດລະຫັດຮູບພາບ ingest ໄຟລ໌ທີ່ສັບສົນທີ່ສະໜອງໂດຍຄົນແປກໜ້າ, ເຊິ່ງເຮັດໃຫ້ພວກມັນເປັນບ່ອນທີ່ດີເລີດທີ່ຈະໄວ້ວາງໃຈອິນເຕີເນັດໂດຍບັງເອີນ. Rust ຊ່ວຍປ້ອງກັນປະເພດຂອງຂໍ້ຜິດພາດຂອງໜ່ວຍຄວາມຈໍາກ່ອນທີ່ພວກມັນຈະກາຍເປັນຈຸດອ່ອນຂອງ browser. Google ຍັງຮັກສາ sandbox ໄວ້, ແລະການປະຕິບັດຍັງ ມີພື້ນທີ່ທີ່ບໍ່ປອດໄພຂະໜາດນ້ອຍທີ່ຖືກກວດສອບຢ່າງລະອຽດ. ຄວາມປອດໄພມີຫຼາຍຊັ້ນ, ເພາະວ່າຄວາມເປັນຈິງຍັງສືບຕໍ່ຊອກຫາຮອຍຕໍ່.

1:27 Google ກ່າວວ່າການ fuzzing ແລະການກວດສອບລະຫັດ AI ບໍ່ພົບຂໍ້ບົກພ່ອງດ້ານຄວາມປອດໄພຂອງໜ່ວຍຄວາມຈໍາໃນປະຫວັດຂອງເຄື່ອງຖອດລະຫັດນີ້. ນັ້ນແມ່ນລາຍງານທີ່ເປັນປະໂຫຍດຈາກທີມທີ່ສົ່ງມັນ. ຜູ້ໂຈມຕີໃນອະນາຄົດບໍ່ໜ້າຈະຍອມຮັບບົດຄວາມ blog ເປັນສັນຍາຜູກມັດ. ຄໍາຖາມທໍາອິດໄດ້ຮັບຄໍາຕອບແລ້ວ. ຄວາມກົດດັນຂອງນັກພັດທະນາ ແລະ ເຄື່ອງຖອດລະຫັດ Rust ທີ່ດີທີ່ສຸດໄດ້ເປີດປະຕູຄືນໃໝ່. Google ໄດ້ປ່ຽນການຕັດສິນໃຈດ້ວຍວິສະວະກໍາຢູ່ເບື້ອງຫຼັງ, ເຊິ່ງໄດ້ຮັບອະນຸຍາດແມ້ແຕ່ຢູ່ໃນອິນເຕີເນັດ. ຕອນນີ້ຄະແນນການທົດສອບສະໄລ້.

### ໄຟລ໌ທີ່ນ້ອຍກວ່າຊະນະ AVIF ບໍ?

1:48 Google ໂຄສະນາການບີບອັດທີ່ດີກວ່າ JPEG ສາມສິບຫາຫ້າສິບເປີເຊັນ. ການດາວໂຫຼດທີ່ນ້ອຍກວ່າສາມາດຊ່ວຍຜູ້ໃຊ້ຂອງທ່ານ ແລະ ຄ່າໃຊ້ຈ່າຍແບນວິດ, ແຕ່ຊ່ວງນັ້ນຂຶ້ນຢູ່ກັບສິ່ງທີ່ທ່ານເຂົ້າລະຫັດ ແລະ ວິທີທີ່ທ່ານປຽບທຽບຄຸນນະພາບ. ວິສະວະກອນການບີບອັດ Gianni Rosato ໄດ້ເຜີຍແຜ່ ການປຽບທຽບໃນເດືອນກັນຍາທີ່ທັນສະໄໝ ເຄື່ອງເຂົ້າລະຫັດ avif ຊະນະ JPEG XL ໃນທົ່ວຊ່ວງຄວາມສັດຊື່ທີ່ລາວທົດສອບ. ລາວເຮັດວຽກກ່ຽວກັບເຄື່ອງມື avif ທີ່ແຂ່ງຂັນກັນ, ດັ່ງນັ້ນຈົ່ງຈື່ແຮງຈູງໃຈນັ້ນໄວ້ຂ້າງກາຟ. ການປຽບທຽບເຫຼົ່ານີ້ໃຊ້ພື້ນຖານທີ່ແຕກຕ່າງກັນ.

2:12 ການເອົາຊະນະ JPEG ເກົ່າເຮັດໃຫ້ມີບ່ອນຫວ່າງໃຫ້ avif ຊະນະການເຮັດວຽກ. Google ເອງກໍແນະນໍາໃຫ້ລອງທັງສອງຮູບແບບ, ເຊິ່ງເປັນຄໍາແນະນໍາທີ່ໃຊ້ໄດ້ຈິງຜິດປົກກະຕິສໍາລັບການປະກາດເປີດຕົວ. ສິ່ງດຶງດູດອື່ນໆຂອງ JPEG XL ລວມມີ High Dynamic Range, ຮູບພາບທີ່ບໍ່ສູນເສຍຄຸນນະພາບ ແລະ ການຖອດລະຫັດແບບກ້າວໜ້າຢ່າງລະອຽດ. ຊຸມຊົນເຜີຍແຜ່ການສາທິດແບບໂຕ້ຕອບສໍາລັບການສໍາຫຼວດຮູບແບບ. ຜູ້ຊົມຂອງທ່ານສາມາດເຫັນຮູບພາບທີ່ເປັນປະໂຫຍດໃນຂະນະທີ່ສ່ວນທີ່ເຫຼືອມາຮອດ. ສໍາລັບການນໍາໃຊ້, ໃຫ້ຮັກສາຮູບພາບສໍາຮອງ, ແລະ ກວດສອບການຮອງຮັບໃນ browser ທີ່ ລູກຄ້າຂອງທ່ານໃຊ້ແທ້ໆ.

2:37 ການປະກາດຕັ້ງຊື່ Chrome ໜຶ່ງຮ້ອຍຫ້າສິບຫ້າ. ນັ້ນເຮັດໃຫ້ທ່ານມີເວີຊັນເປົ້າໝາຍ, ແລະ ການວິເຄາະຂອງທ່ານບອກທ່ານວ່າຜູ້ຊົມຂອງທ່ານ ໄປຮອດນັ້ນເມື່ອໃດ. ຄໍາຖາມທີສອງໄດ້ຮັບຄໍາຕອບແລ້ວ. ທົດສອບຮູບພາບຕົວຈິງຂອງທ່ານກ່ອນທີ່ຈະປ່ຽນທໍ່ສົ່ງ, ແລະ ຮັກສາເສັ້ນທາງທີ່ເຂົ້າກັນໄດ້. ຮູບແບບຮູບພາບທີ່ປະຢັດໄບຕ໌ແມ່ນມີປະໂຫຍດ. ການຍ້າຍຖິ່ນທີ່ເຊື່ອງປຸ່ມຊໍາລະເງິນຂອງທ່ານແມ່ນການຕີຄວາມໝາຍທີ່ແພງຂອງ ຄວາມນ້ອຍທີ່ສຸດ. ໃນຂະນະດຽວກັນ, OpenAI ໄດ້ເຜີຍແຜ່ເອກະສານທາງຄະນິດສາດແລະການສະໜັບສະໜູນ ສິ່ງປະດິດສ້າງການພິສູດໃນວັນອັງຄານ.

### OpenAI ໄດ້ເຜີຍແຜ່ຫຍັງແທ້ໆ?

3:00 ບ່ອນເກັບຂໍ້ມູນປະກອບດ້ວຍເອກະສານເຈັດຮ້ອຍຊາວສອງສະບັບ, ຈັດກຸ່ມເປັນຄອບຄົວທີ່ກ່ຽວຂ້ອງ. ຈໍານວນຫົວຂໍ້ຂ່າວລວມມີການໂຕ້ຖຽງປະກອບ ແລະ ຫຼັກຖານທາງເລືອກ, ດັ່ງນັ້ນອ່ານສິ່ງທີ່ເອກະສານແຕ່ລະສະບັບຮຽກຮ້ອງແທ້ໆ. ຫຼາຍສະບັບມີຫຼັກຖານທາງການໃນ Lean, ເຊິ່ງເຮັດໃຫ້ຄອມພິວເຕີກວດສອບການຫັກລົບທາງຄະນິດສາດ. ອື່ນໆຍັງລໍຖ້າການສ້າງແບບຢ່າງເປັນທາງການ, ແລະ OpenAI ເຕືອນຢ່າງຈະແຈ້ງວ່າ ຜົນໄດ້ຮັບທີ່ບໍ່ໄດ້ສ້າງແບບຢ່າງເປັນທາງການບາງອັນອາດຈະມີບັນຫາ.

3:21 ບ່ອນເກັບຂໍ້ມູນມອບອຸປະກອນໃຫ້ນັກຄົ້ນຄວ້າທີ່ພວກເຂົາສາມາດກວດກາແລະທ້າທາຍໄດ້. ຮູບແບບຍັງບໍ່ຖືກປ່ອຍອອກມາ. OpenAI ກ່າວວ່າແຕ່ລະຜົນໄດ້ຮັບໃຊ້ເວລາປະມານສາມຊົ່ວໂມງຂອງການຄິດໄລ່ທີ່ທຽບເທົ່າກັບ ChatGPT Pro ໂດຍສະເລ່ຍ. ນັ້ນອະທິບາຍຄວາມພະຍາຍາມໃນການຄິດໄລ່. ມັນບໍ່ໄດ້ໃຫ້ການຮັບປະກັນ ເວລາຂອງໂມງຝາ ແລະບໍ່ແມ່ນລາຄາຂາຍຍ່ອຍສໍາລັບການຜະລິດ

3:40 ທິດສະດີ. ການປ່ອຍອອກມາແມ່ນຫຼັງຈາກການປຶກສາຫາລືກັບກຸ່ມທີ່ປຶກສາຄະນິດສາດເອກະລາດ, ແລະລວມມີຂະບວນການແກ້ໄຂແລະອ້າງອີງ. ວິທະຍາສາດໄດ້ຮັບວຽກບ້ານໃໝ່, ບວກກັບຄວາມສາມາດທີ່ມີປະໂຫຍດຫຼາຍກວ່າທີ່ຈະຊີ້ ໄປຫາໜ້າທີ່ຕ້ອງການແກ້ໄຂຢ່າງແນ່ນອນ. ຜູ້ຮັກສາ Lean ແນະນໍາໃຫ້ລວບລວມສ່ວນນ້ອຍໆໃນແຕ່ລະຄັ້ງ. ແມ້ແຕ່ການຄົ້ນພົບທາງຄະນິດສາດກໍຍັງ ພົບກັບສັດຕູເກົ່າແກ່ຂອງຊອບແວ, ການເຮັດໃຫ້ການສ້າງສໍາເລັດ.

### ແຜ່ນສອງໂດລາບລັອກໂດເມນໄດ້ແນວໃດ?

4:03 ສຸດທ້າຍ, ຕົວບລັອກໂຄສະນາ DNS ແຫຼ່ງເປີດເຮັດວຽກເທິງແຜ່ນ microcontroller ສອງໂດລາຂະໜາດນ້ອຍ. ເຄັດລັບຂອງຜູ້ສ້າງແມ່ນການເກັບຮັກສາ hashes ໂດເມນທີ່ຈັດຮຽງໄວ້ໃນ flash, ດັ່ງນັ້ນລາຍການບລັອກບໍ່ຈໍາເປັນຕ້ອງຢູ່ໃນໜ່ວຍຄວາມຈໍາທີ່ຂາດແຄນ. ໂຄງການລາຍງານການໃຊ້ RAM ປະມານຫ້າສິບກິໂລໄບຕ໌. ມັນຄົ້ນຫາໂດເມນທີ່ຮ້ອງຂໍໃນຕາຕະລາງ flash, ບລັອກທີ່ກົງກັນ ແລະ ສົ່ງຄໍາຖາມອື່ນໆຂຶ້ນສູ່ລະບົບ. ເຣົາເຕີຂອງທ່ານສາມາດໄດ້ຮັບຜູ້ກວດກາຂະໜາດນ້ອຍທີ່ມີລາຍຊື່ແຂກທີ່ລະບຸໄວ້ຫຼາຍ. ການກັ່ນຕອງ DNS ເຮັດວຽກໃນລະດັບໂດເມນ.

4:28 ໂຄສະນາທີ່ໃຫ້ບໍລິການຈາກໂດເມນດຽວກັນກັບເນື້ອຫາທີ່ເປັນປະໂຫຍດສາມາດຫຼຸດລອດໄດ້, ແລະລູກຄ້າທີ່ໃຊ້ຕົວແກ້ໄຂອື່ນໆສາມາດຂ້າມຜ່ານໄດ້. ຮັກສາຄວາມຄາດຫວັງຂອງທ່ານໃຫຍ່ກວ່າແຜ່ນ, ເຊິ່ງເປັນເປົ້າໝາຍຂະໜາດທີ່ຕ້ອງການ. ແລະລາຍລະອຽດກ່ຽວກັບ JPEGs ທີ່ມີຢູ່ແລ້ວຂອງທ່ານ?

### JPEG ທີ່ມີຢູ່ແລ້ວຂອງທ່ານສາມາດເຂົ້າຮ່ວມການກັບມາໄດ້ບໍ?

4:40 JPEG XL ຮອງຮັບການປ່ຽນລະຫັດ JPEG ທີ່ບໍ່ສູນເສຍຄຸນນະພາບ, ດ້ວຍເສັ້ນທາງທີ່ຈະສ້າງ JPEG ເດີມຄືນ. ນັ້ນເຮັດໃຫ້ໄຟລ໌ຮູບພາບເກົ່າມີທາງເລືອກການຍ້າຍຖິ່ນໂດຍບໍ່ມີ ການສູນເສຍຄຸນນະພາບອີກລຸ້ນໜຶ່ງ. ທົດສອບການປະນີປະນອມການເກັບຮັກສາແລະການສົ່ງ. ຖ້າທ່ານຕ້ອງການອ່ານສິ່ງນີ້ຫຼາຍກວ່າທີ່ຈະໄດ້ຍິນຂ້ອຍເວົ້າ, The Daily Diff ຈະສົ່ງເຂົ້າໃນ inbox ຂອງທ່ານ ທຸກໆເຊົ້າ, ຟຣີທີ່ thedailydiff.dev, ລິ້ງຂ້າງລຸ່ມນີ້.

### ເປັນຫຍັງຂ້ອຍຈຶ່ງຕ້ອງສົ່ງເຄື່ອງຖອດລະຫັດ ແລະ ທົດສອບການຍ້າຍ?

4:58 ສະນັ້ນຄໍາຕັດສິນຂອງມື້ນີ້, SHIP IT. ຂ້ອຍຈະສົ່ງເຄື່ອງຖອດລະຫັດເພີ່ມເຕີມເພາະວ່າການຮອງຮັບ browser ໃຫ້ນັກພັດທະນາມີທາງເລືອກທີ່ແທ້ຈິງ, ແລະຂ້ອຍຈະທົດສອບການຍ້າຍຖິ່ນໃນຮູບພາບຂອງພວກເຮົາເອງ. ສະໝັກ, ກົດກະດິ່ງ, ແລະ ບອກຂ້ອຍໃນຄໍາເຫັນວ່າເຈົ້າຈະປະທັບຕາມັນ ແຕກຕ່າງກັນບໍ່. ແລະນັ້ນແມ່ນ The Daily Diff ສໍາລັບມື້ນີ້. ຂ້ອຍແມ່ນ Niko ຈາກ Axrisi. ລວມກັນຢ່າງມີຄວາມຮັບຜິດຊອບ.

## ແຫຼ່ງຂໍ້ມູນ

- [Shipping JPEG XL in Chrome](https://developer.chrome.com/blog/jpeg-xl-in-chrome) — Chrome for Developers
- [JPEG XL prototype and November 2022 removal discussion](https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k) — Chromium Blink developers
- [Contemporaneous JPEG XL deprecation commentary](https://www.fsf.org/blogs/community/googles-decision-to-deprecate-jpeg-xl-emphasizes-the-need-for-browser-choice-and-free-formats) — Free Software Foundation
- [The case against JPEG XL — competing-encoder benchmark](https://giannirosato.com/blog/post/case-against-jxl/) — Gianni Rosato
- [JPEG XL FAQ and reversible JPEG transcoding](https://jpegxl.info/resources/faqs.html) — JPEG XL community
- [HTML picture element and fallback selection](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/picture) — MDN Web Docs
- [Progressive loading demo](https://jpegxl.info/resources/progressive-loading-demo.html) — JPEG XL community
- [Distance versus effort visualizer](https://jpegxl.info/resources/distance-vs-effort-visualizer.html) — JPEG XL community
- [Sharing AI progress in mathematics](https://openai.com/index/sharing-ai-progress-in-mathematics/) — OpenAI
- [Mathematical manuscripts and proof artifacts](https://github.com/openai/math) — OpenAI on GitHub
- [Lean formalization library build notes](https://github.com/openai/math/blob/main/lean/README.md) — OpenAI on GitHub
- [ESP32-C3 hash-in-flash DNS ad blocker](https://github.com/M-Abozaid/esp32-c3-adblock) — M-Abozaid on GitHub