เกิดอะไรขึ้นเมื่อเบราว์เซอร์บีบอัดภาพ

ไฟล์ที่ถูกบีบอัดถูกแปลงกลับเป็นตารางพิกเซล เบราว์เซอร์ทำงานนี้ด้วยโค้ดเนทีฟ พร้อมการเร่งความเร็วด้วยฮาร์ดแวร์เมื่อแพลตฟอร์มมีให้ และรองรับ JPEG, PNG, WebP และ AVIF รวมถึง HEIC บนแพลตฟอร์มของ Apple เพราะระบบปฏิบัติการมีตัวถอดรหัสนั้นติดมาอยู่แล้ว

การถอดรหัสไม่สูญเสียข้อมูลเมื่อเทียบกับตัวไฟล์ คุณได้พิกเซลตรงตามที่ไฟล์บรรยายไว้เป๊ะ ๆ ความสูญเสียเกิดขึ้นไปแล้วตั้งแต่ตอนที่อะไรก็ตามที่สร้างไฟล์นั้นเข้ารหัสมันออกมา

กล้องมือถือเก็บทิศทางดิบของเซนเซอร์เอาไว้ พร้อมแท็ก EXIF อีกอันแยกต่างหากที่บอกว่าต้องหมุนอย่างไร ซอฟต์แวร์ที่มองข้ามแท็กนั้นจะให้ภาพตะแคง การนำแท็กมาใช้หมายถึงการหมุนตารางพิกเซลจริง ๆ ก่อนที่อย่างอื่นจะเข้ามาแตะ หลังจากนั้นก็ไม่ต้องใช้แท็กนั้นอีก ซึ่งเป็นส่วนหนึ่งของเหตุผลที่การเข้ารหัสใหม่ทำให้ข้อมูลเมตาหายไป

ถ้าทำขนาดเป้าหมายไม่ได้ที่ความละเอียดเต็ม ภาพจะถูกย่อลง ตรงนี้คือจุดที่คุณภาพซึ่งตามองเห็นถูกได้มาหรือเสียไปแบบเงียบ ๆ ฟิลเตอร์บ็อกซ์แบบถูก ๆ เฉลี่ยพิกเซลข้างเคียงแล้วทำให้ทุกอย่างนุ่มลง ส่วนฟิลเตอร์ Lanczos ถ่วงน้ำหนักพิกเซลรอบข้างในวงที่กว้างกว่าและรักษาขอบให้คมไว้ได้

การสุ่มตัวอย่างใหม่ทำลายข้อมูลจริง พิกเซลที่ถูกทิ้งไปแล้วไม่กลับมาอีก แต่บ่อยครั้งมันเป็นวิธีที่ ทำลายน้อยที่สุด ในการไปให้ถึงเป้าหมายขนาดเล็ก เพราะมันตัดรายละเอียดที่ไม่อย่างนั้นตัวเข้ารหัสก็จะเอางบทั้งก้อนไปพยายามบรรยายแล้วทำไม่สำเร็จอยู่ดี

ส่วนที่สูญเสียข้อมูล JPEG แปลงภาพเป็นรูปแบบความสว่างบวกสี ทิ้งความละเอียดของสีไปบางส่วน ซึ่งสายตาแทบไม่รู้สึก แล้วซอยภาพเป็นบล็อกขนาด 8×8 แปลงแต่ละบล็อกให้เป็นองค์ประกอบเชิงความถี่ จากนั้นจึง ควอนไทซ์ คือปัดรายละเอียดความถี่สูงทิ้งไป ค่าพารามิเตอร์คุณภาพก็คือความหยาบของการปัดนั้น ทุกอย่างหลังจากนั้นเป็นการเข้ารหัสเอนโทรปีแบบไม่สูญเสียข้อมูล ซึ่งเป็นเหตุผลว่าทำไมตาราง Huffman ที่ปรับให้เหมาะสม หรือการสแกนแบบโพรเกรสซีฟ จึงประหยัดไบต์ได้แบบฟรี ๆ

ตัวเข้ารหัสที่ติดมากับเบราว์เซอร์เป็นกล่องดำ คุณสั่งได้แค่ตัวเลขคุณภาพเท่านั้น ไม่มีตารางเอนโทรปีที่ปรับให้เหมาะสม ไม่มีทางเลือกระหว่างเบสไลน์กับโพรเกรสซีฟ ไม่มีการควบคุมฟิลเตอร์สุ่มตัวอย่างใหม่ และไม่มีทางรู้ว่าค่าที่ตั้งไว้จะให้ไฟล์กี่ไบต์โดยไม่ลองทำจริง

โคเดกที่คอมไพล์เป็น WebAssembly คืนทั้งหมดนั้นกลับมาให้ โดยแลกกับไบต์ที่คุณเสียไปกับการดาวน์โหลดตัวมันเอง ToolZool รันทั้งกระบวนการแบบนั้น ทั้งการถอดรหัส การจัดทิศทาง การสุ่มตัวอย่างใหม่ และการเข้ารหัส ล้วนเป็น Rust ที่คอมไพล์เป็น WebAssembly ทำงานอยู่ใน worker เบื้องหลัง แทนที่จะโยนการถอดรหัสให้เบราว์เซอร์ เหตุผลมีสามข้อ และเป็นเหตุผลเชิงปฏิบัติทั้งหมด

• การไล่ค้นหาต้องเข้ารหัสหลายรอบ การไปให้ถึงขนาดที่เป๊ะหมายถึงการเข้ารหัสภาพเดิมห้าถึงหกครั้ง การเป็นเจ้าของตัวเข้ารหัสเองคือสิ่งที่ทำให้เรื่องนั้นถูกและทำซ้ำได้
• ตัวถอดรหัสต้องปฏิเสธเป็น ไฟล์ที่ประกาศว่าตัวเองมีขนาด 60,000 × 60,000 พิกเซลต้องถูกปฏิเสธก่อนที่มันจะจองหน่วยความจำ และไฟล์ที่ขาดกลางคันต้องล้มเหลวไปเลย ไม่ใช่คืนภาพมาให้ครึ่งใบ ตัวถอดรหัสของเบราว์เซอร์ตัดสินใจเรื่องนี้เอง ส่วนของเราประกาศขีดจำกัดไว้ชัดเจนและบังคับใช้ตามนั้น
• อินพุตเดียวกันต้องให้ผลลัพธ์เดียวกัน ตัวถอดรหัสของแต่ละเบราว์เซอร์จัดการเรื่องสีต่างกัน และปฏิบัติกับไฟล์ที่ผิดรูปแบบต่างกัน กระบวนการที่เป็นเจ้าของทั้งสองปลายจะให้ไบต์ชุดเดียวกันบนทุกเครื่อง ซึ่งเป็นสิ่งที่ทำให้ผลลัพธ์ตรวจสอบได้

ต้นทุนของมันตรงไปตรงมา เอนจินตัวนั้นคือไฟล์ที่ต้องดาวน์โหลด มันจะถูกดึงมาก็ต่อเมื่อคุณเลือกไฟล์แล้วเท่านั้น การอ่านหน้าอย่างหน้านี้จึงไม่ต้องจ่ายค่ามันเลย

เมื่อกำหนดขนาดไฟล์เป้าหมายมาแล้ว ความต่างระหว่างตัวเข้ารหัสที่ดีกับตัวที่เยี่ยมอยู่แค่ไม่กี่เปอร์เซ็นต์ แต่ความต่างระหว่างการเดาสไลเดอร์คุณภาพกับการไล่ค้นหาค่าที่ถูกต้องนั้นใหญ่กว่ามาก เพราะการเดาที่ไปหยุดอยู่ที่ 60% ของโควตาที่คุณมี คือการทิ้งคุณภาพที่คุณมีสิทธิ์ได้ไปหนึ่งในสาม นั่นคือแนวคิดทั้งหมดเบื้องหลังการบีบอัดให้ได้ขนาดเป๊ะ และการทำให้ภาพเหลือ 50 KB แสดงให้เห็นว่าการไล่ค้นหาซื้ออะไรให้คุณได้บ้างที่ปลายซึ่งโหดที่สุดของช่วง