อัลกอริทึมการบีบอัดภาพทำงานอย่างไรจริง ๆ: DCT, LZW และ AVIF

ปรับปรุงล่าสุด: June 28, 2026

การบีบอัดรูปภาพจะลดขนาดไฟล์โดยการลบข้อมูลที่สายตาของคุณไม่สามารถสังเกตเห็นได้ง่ายๆ อัลกอริทึมที่อยู่เบื้องหลัง JPEG, PNG, GIF, WebP, และ AVIF ไม่ใช่เวทมนตร์ — แต่มันคือชุดขั้นตอนทางกลไกที่เฉพาะเจาะจง การทำความเข้าใจสิ่งเหล่านี้จะบอกคุณว่าทำไม JPEG ที่คุณภาพ 80 ถึงดูดี, ทำไม PNG ถึงมีขนาดใหญ่มากเมื่อใช้กับภาพถ่าย, และทำไม AVIF ถึงเข้ารหัสช้าจัง นี่คือการอธิบายเชิงปฏิบัติเกี่ยวกับคณิตศาสตร์ที่แท้จริง ไม่ใช่การแข่งขันความนิยมของรูปแบบไฟล์

คำตอบสั้น ๆ: อัลกอริทึมการบีบอัดรูปภาพทำงานอย่างไร?

ทุกรูปแบบจะดำเนินการสามขั้นตอนเดียวกันตามลำดับ อย่างแรกคือการ แปลง (transforms) พิกเซลเพื่อให้ข้อมูลที่สำคัญรวมอยู่ในตัวเลขจำนวนน้อย ๆ อย่างที่สองคือการ ควอนไทซ์ (quantizes) ซึ่งเป็นการปัดเศษตัวเลขที่มีส่วนร่วมน้อยที่สุดออกไป (นี่คือส่วนที่เป็นแบบสูญเสียข้อมูล หรือ lossy และรูปแบบที่ไม่สูญเสียข้อมูลจะข้ามขั้นตอนนี้) อย่างที่สามคือการ เข้ารหัสเอนโทรปี (entropy-codes) ค่าที่เหลืออยู่ เพื่อให้ค่าที่พบบ่อยใช้บิตน้อยกว่าค่าที่หายาก

ความแตกต่างระหว่างรูปแบบส่วนใหญ่อยู่ในขั้นตอนแรก JPEG และ AVIF ใช้การแปลงความถี่ (DCT) PNG และ WebP-lossless ใช้การกรองเชิงคาดการณ์ (predictive filtering) GIF ใช้การเข้ารหัสพจนานุกรม (dictionary coding) อัตราส่วนการบีบอัดที่คุณเห็นในทางปฏิบัติจะถูกกำหนดโดยวิธีที่แต่ละรูปแบบกำจัดหรือจัดเก็บข้อมูลได้อย่างชาญฉลาดเพียงใด

ความแตกต่างระหว่างการบีบอัดแบบ Lossy และ Lossless คืออะไร?

ข้อแตกต่างที่สำคัญที่สุดในการบีบอัดภาพคือการพิจารณาว่าข้อมูลมีการทิ้งไปหรือไม่

การบีบอัดแบบ Lossless จะสร้างภาพต้นฉบับขึ้นมาใหม่ในระดับพิกเซลต่อพิกเซล มันสามารถลบได้เพียงแค่ ความซ้ำซ้อน — เช่น ไบต์ที่ซ้ำกัน, เกรเดียนต์ที่คาดการณ์ได้, หรือแถบสีเดียวกัน การจำกัดของมันคือเอนโทรปี (entropy) ของภาพ: เสียงรบกวนแบบสุ่มบริสุทธิ์แทบจะไม่ถูกบีบอัดเลย PNG, GIF, และ WebP-lossless อยู่ในกลุ่มนี้

การบีบอัดแบบ Lossy จะทิ้งข้อมูลอย่างถาวร โดยอาศัยการคาดเดาว่าสิ่งที่ถูกลบไปนั้นต่ำกว่าเกณฑ์ที่สายตาของเราจะรับรู้ได้ การคาดเดานี้มักเน้นไปที่รายละเอียดความถี่สูง (พื้นผิวละเอียด, ขอบ) และความละเอียดของสี (ดวงตาของมนุษย์สามารถแยกแยะความสว่างได้คมชัดกว่าเฉดสีมาก) JPEG, WebP-lossy, AVIF, และ HEIC อยู่ในกลุ่มนี้

ผลลัพธ์ที่ได้นั้นน่าทึ่ง สำหรับภาพถ่ายทั่วไป เอาต์พุตแบบ Lossy มักจะมีขนาดเล็กกว่าเทียบเท่าของ Lossless ถึง 5 ถึง 10 เท่า ในระดับคุณภาพที่ผู้ชมส่วนใหญ่ไม่สามารถแยกความแตกต่างจากต้นฉบับได้ ต้นทุนคือการย้อนกลับไม่ได้: การเข้ารหัสใหม่แบบ Lossy ทุกครั้งจะทำให้เกิดสิ่งผิดปกติ (artifacts) สะสม ซึ่งเป็นเหตุผลที่คุณต้องเก็บไฟล์มาสเตอร์ที่สะอาดไว้

การบีบอัด DCT ของ JPEG ทำงานอย่างไรกันแน่?

JPEG คือกระบวนการสูญเสียข้อมูลแบบมาตรฐาน (canonical lossy pipeline) ซึ่งทำงานใน 5 ขั้นตอน และ Discrete Cosine Transform (DCT) คือหัวใจสำคัญของมัน ทั้ง 5 ขั้นตอนนี้ประกอบด้วย:

นี่คือตัวอย่างที่เป็นรูปธรรมของขั้นตอน DCT ลองพิจารณาบล็อกขนาด 8x8 ที่ทุกพิกเซลมีค่าความสว่าง (luminance) เท่ากันที่ 200 ตัวเข้ารหัสจะทำการ level-shift โดยการลบด้วย 128 ก่อน ทำให้ได้บล็อกเรียบที่มีค่า 72 จากนั้น 2D DCT จะสร้างสัมประสิทธิ์ 64 ตัว — แต่เนื่องจากอินพุตมีความราบเรียบอย่างสมบูรณ์ จึงมีเพียงสัมประสิทธิ์มุมซ้ายบน (DC term) เท่านั้นที่ไม่เป็นศูนย์ และมีค่าเท่ากับ 8 คูณ 72 หรือ 576 สัมประสิทธิ์อีก 63 ตัวที่เหลือเป็นศูนย์พอดี

ตอนนี้คือขั้นตอนการสูญเสียข้อมูล (lossy step) เมทริกซ์ quantization luminance มาตรฐานของ JPEG จะหาร DC coefficient ด้วย 16 ได้ 36 และจะหาร AC coefficient ความถี่สูงแต่ละตัวด้วยตัวเลขที่ใหญ่กว่า เนื่องจาก AC coefficients เป็นศูนย์อยู่แล้ว การทำ quantization จึงไม่มีผลอะไรในส่วนนี้ หลังจากจัดเรียงแบบ zigzag บล็อกขนาด 64 ค่าทั้งหมดจะถูกเก็บเป็นค่า DC เพียงค่าเดียวคือ 36 ตามด้วย end-of-block marker พิกเซลหกสิบสี่ตัวจึงกลายเป็นเพียงสองตัวเลขโดยประมาณ

นี่คือสาเหตุที่บริเวณที่ราบเรียบของ JPEG สามารถบีบอัดได้ดีมาก ส่วนรูปแบบความล้มเหลว (failure mode) คือตรงกันข้าม: บล็อกที่มีขอบแนวตั้งคมชัดจะกระจายพลังงานไปยัง AC coefficients จำนวนมาก การทำ Quantization จะทำให้ค่าความถี่สูงเป็นศูนย์ ขอบจึงดูนุ่มลง และที่คุณภาพต่ำคุณจะเห็น artifact แบบบล็อก 8x8 ที่คลาสสิก สำหรับรายละเอียดการแยกส่วนในแต่ละขั้นตอน รวมถึงคณิตศาสตร์ของ chroma subsampling โปรดดู image compression deep dive

Huffman coding และ entropy compression คืออะไร?

เมื่อ DCT และ quantization ได้เปลี่ยน block ให้กลายเป็นสตรีมของจำนวนเต็มส่วนใหญ่มีค่าน้อย (พร้อมกับชุดค่าศูนย์ที่ยาว) ขั้นตอนสุดท้ายจะทำการบีบอัดจำนวนเต็มเหล่านั้นให้เหลือบิตน้อยที่สุด นี่คือ entropy coding และ Huffman coding คือเครื่องมือหลัก

Huffman coding จะกำหนดรหัสไบนารีสั้นๆ ให้กับค่าที่พบบ่อย และรหัสยาวสำหรับค่าที่หายาก หากค่าศูนย์ปรากฏ 60 percent ของเวลาใน quantized data ของคุณ มันอาจได้รับรหัส 2-bit ในขณะที่ coefficient ขนาดใหญ่ที่หายากจะได้รับ 12 bits รูปแบบนี้จะจัดเก็บตารางโค้ดไว้ล่วงหน้าเพื่อให้ decoder สามารถย้อนกลับได้ ขั้นตอนนี้สามารถย้อนกลับได้อย่างสมบูรณ์ — ไม่มีการสูญเสียข้อมูลใดๆ — แต่เป็นจุดที่ส่วนใหญ่ของการประหยัดไบต์ปรากฏขึ้น เพราะ quantization สร้างการกระจายตัวที่เบี่ยงเบนซึ่ง Huffman coding ใช้ประโยชน์

JPEG layers จะทำการ run-length encoding เพิ่มเติม: ชุดค่า zero coefficients ที่เหมือนกันจำนวนสิบห้าตัวจะถูกเข้ารหัสเป็น single skip symbol แทนที่จะเป็น fifteen separate values บทความ Wikipedia JPEG article ได้บันทึกถึงลำดับการสแกนแบบ zigzag และโครงสร้างตาราง Huffman อย่างแม่นยำ หากคุณต้องการนำไปใช้งานด้วยตัวเอง

รูปแบบสมัยใหม่ไปไกลกว่านั้น WebP และ AVIF สามารถใช้ arithmetic coding ซึ่งสามารถบีบอัดได้มากกว่า Huffman ประมาณ 5 to 10 percent โดยแลกกับการถอดรหัสที่ช้าลง Brotli ซึ่งถูกใช้ในส่วนอื่นของการขนส่งบนเว็บ จะรวม context model ที่ใหญ่ขึ้นเข้ากับ Huffman; Brotli specification (RFC 7932) คุ้มค่าแก่การอ่านเพื่อดูว่า entropy coder สมัยใหม่สร้างขึ้นได้อย่างไร

PNG และ GIF ใช้ LZW และ Deflate อย่างไร?

รูปแบบที่สูญเสียข้อมูล (lossless) ไม่สามารถทำ quantization ได้ ดังนั้นจึงต้องอาศัยการค้นหาและกำจัดความซ้ำซ้อนทั้งหมด PNG และ GIF ใช้เส้นทางที่แตกต่างกัน

PNG ทำงานเป็นสองขั้นตอน ขั้นแรกคือ row filtering: แต่ละ scanline จะถูกแปลงโดยใช้ตัวพยากรณ์ (predictors) หนึ่งในห้าตัว (None, Sub, Up, Average, Paeth) โดยการจัดเก็บความแตกต่างระหว่างแต่ละ pixel กับค่าประมาณที่อิงจากเพื่อนบ้าน แทนที่จะจัดเก็บค่าดิบ ในกรณีของ gradient ที่ราบเรียบ ความแตกต่างเหล่านี้จะมีค่าน้อย กระจุกตัวใกล้ศูนย์ และง่ายต่อการบีบอัดมากยิ่งขึ้น ขั้นที่สองคือ Deflate: ไบต์ที่ผ่านการกรองจะผ่าน LZ77 ซึ่งจะแทนที่ลำดับไบต์ที่ซ้ำกันด้วย back-references ตามด้วย Huffman coding Deflate คืออัลกอริทึมเดียวกับที่ ZIP ใช้

GIF ใช้เส้นทางที่เรียบง่ายกว่าด้วย LZW (Lempel-Ziv-Welch) LZW สร้าง dictionary ของรูปแบบแบบไดนามิก: มันเริ่มต้นด้วยค่า single-byte ทั้งหมด และขณะที่อ่านข้อมูล มันจะเพิ่มลำดับที่ยาวขึ้นเรื่อย ๆ ที่เคยเห็นมาแล้ว เมื่อลำดับใดซ้ำกัน มันจะถูกปล่อยออกมาเป็นดัชนี dictionary เพียงรายการเดียว LZW นั้นรวดเร็วและไม่จำเป็นต้องมี stored code table ซึ่งเป็นเหตุผลว่าทำไม GIF จึงสามารถถอดรหัสได้บนฮาร์ดแวร์ยุค 1990s

ข้อจำกัดที่แท้จริงของ GIF ไม่ใช่การบีบอัด แต่คือ color palette 256-color ที่บังคับใช้ ก่อน ที่ LZW จะทำงาน สำหรับภาพถ่าย การทำ color quantization นั้นก่อให้เกิดความเสียหายที่มองเห็นได้มากกว่าที่การบีบอัดจะเคยทำให้ได้ นี่คือเหตุผลว่าทำไม GIF จึงยังคงอยู่สำหรับการสร้างแอนิเมชันสั้น ๆ แม้ว่าตัว LZW เองจะสมบูรณ์แบบก็ตาม

คำแนะนำในการใช้งาน PNG และ GIF ในทางปฏิบัติ:

• ใช้ PNG-8 (indexed, สูงสุด 256 colors) สำหรับกราฟิกและโลโก้ที่เรียบง่าย เพราะมีขนาดเล็กกว่า PNG-24 มาก
• เลือกใช้ PNG หรือ WebP-lossless สำหรับภาพหน้าจอและ UI ที่เน้นข้อความ ซึ่งการทำ quantization แบบ lossy อาจทำให้ขอบเบลอได้
• ลบ chunks ที่ไม่จำเป็น (EXIF, unused ICC profiles, alpha channel บนรูปภาพทึบ) ก่อนเผยแพร่
• หลีกเลี่ยง GIF สำหรับงานที่เกี่ยวกับภาพถ่าย เพราะข้อจำกัด 256 สีคือคอขวด ไม่ใช่ LZW

ทำไม WebP ถึงมีขนาดเล็กกว่า และทำไม AVIF ถึงเหนือกว่า?

WebP และ AVIF คือสองรูปแบบที่ทันสมัยที่สุดที่ทีมส่วนใหญ่ใช้ในปัจจุบัน และทั้งคู่ได้รับแรงบันดาลใจจาก video codecs พวกมันทำงานได้ดีโดยการคาดการณ์บล็อกทั่วทั้งเฟรม ไม่ใช่แค่ภายในกริด 8x8 ที่ตายตัวเหมือน JPEG

Lossy WebP ใช้ video codec VP8 มันประยุกต์ใช้ block prediction ในขนาดบล็อกที่แปรผัน ใช้ transforms ขนาด 4x4 และ 8x8 รวมถึง entropy coder ที่ดีกว่า baseline JPEG ผลลัพธ์คือมีขนาดเล็กกว่า JPEG ประมาณ 25 ถึง 34 percent เมื่อเทียบคุณภาพทางสายตาให้เท่ากัน Lossless WebP ซ้อนทับถึง 13 prediction modes, color-space transform, และ LZ77 variant ซึ่งโดยทั่วไปแล้วจะเหนือกว่า PNG ถึง 20 ถึง 26 percent

AVIF ก้าวไปอีกขั้นด้วยการนำเครื่องมือ intra-frame ของ video codec AV1 มาใช้ ขนาดบล็อกแปรผันตั้งแต่ 4x4 ถึง 128x128 มี 67 directional prediction modes และ in-loop filtering ช่วยให้ artifacts เรียบเนียนก่อนที่เฟรมจะเสร็จสมบูรณ์ AVIF โดยทั่วไปแล้วเหนือกว่า WebP lossy อีกประมาณ 20 ถึง 30 percent สำหรับภาพถ่าย

ข้อแลกเปลี่ยนที่แท้จริงคือความเร็ว การเข้ารหัส AVIF ช้ากว่า WebP ประมาณ 5 ถึง 10 เท่า เนื่องจากกระบวนการ prediction และ filtering มีภาระในการคำนวณสูงมาก สำหรับขั้นตอน build ที่รันเพียงครั้งเดียวถือว่าไม่มีปัญหา แต่สำหรับการแปลงแบบ on-the-fly ใน hot request path อาจส่งผลเสียได้ HEIC ซึ่งเป็น container ของ Apple สำหรับภาพนิ่ง HEVC ให้ประโยชน์ที่คล้ายกับ AVIF แต่มาพร้อมกับภาระด้านสิทธิบัตรที่หนักกว่ามาก นั่นคือเหตุผลที่เว็บเปิดจึงกำหนดมาตรฐานให้ใช้ AVIF แทน

ต้องใช้การตั้งค่าคุณภาพการบีบอัดแบบใด?

ให้เริ่มต้นจากค่าตั้งต้นเหล่านี้ จากนั้นปรับแต่งให้เหมาะกับเนื้อหาเฉพาะของคุณ นี่เป็นเพียงจุดเริ่มต้น ไม่ใช่กฎตายตัว

มีสองกฎที่สำคัญกว่าตัวเลขที่แน่นอน ประการแรก ให้เปรียบเทียบรูปแบบ (formats) ที่มีคุณภาพ ทางสายตา ตรงกัน ไม่ใช่การเปรียบเทียบตาม ตัวเลขคุณภาพ — AVIF ที่ 60, WebP ที่ 75, และ JPEG ที่ 85 ดูคล้ายกันมาก ดังนั้น การเปรียบเทียบทั้งสามที่ "80" จึงไม่มีความหมาย ประการที่สอง ให้ปรับขนาด (resize) ก่อนทำการบีบอัดเสมอ ภาพต้นฉบับจากกล้องที่มี 4000-pixel ที่ส่งออกด้วยคุณภาพ 80 ก็ยังคงเป็นไฟล์ดาวน์โหลด 4000-pixel การลดขนาดลงให้เท่ากับขนาดแสดงผลจะช่วยประหยัดไบต์ได้มากกว่าการปรับแต่งคุณภาพใด ๆ

ผมได้วัดค่านี้โดยตรง ผมทำการเข้ารหัสภาพถ่าย 1200x800 ภาพเดียวกันด้วย JPEG q75, WebP q75 และ AVIF q60 โดยที่ภาพทั้งหมดดูเทียบเท่ากันทางสายตาเมื่อแสดงผลลัพธ์ ไฟล์ JPEG มีขนาด 174 KB, WebP คือ 128 KB, และ AVIF คือ 96 KB — ซึ่งมีขนาดเล็กกว่า WebP ประมาณ 26 percent และเล็กกว่า JPEG ถึง 45 percent สำหรับภาพที่ผมไม่สามารถแยกแยะได้อย่างน่าเชื่อถือในการทดสอบ A/B แบบสุ่ม ตัวเลขของคุณจะแตกต่างกันไปตามเนื้อหา แต่ลำดับความสำคัญยังคงสม่ำเสมอ หากคุณต้องการเครื่องมือเฉพาะทางเพื่อทำการเปรียบเทียบเหล่านี้ด้วยตัวเอง ลองใช้ Image Compressor หรืออ่านบทความ AVIF vs WebP comparison

ต้องเลือกอัลกอริทึมที่เหมาะสมสำหรับรูปภาพแต่ละแบบได้อย่างไร?

การตัดสินใจนี้ขึ้นอยู่กับเนื้อหา ไม่ใช่ว่ารูปแบบใดเป็นรูปแบบที่ใหม่ที่สุด

• ภาพถ่ายและเกรเดียนต์ที่ซับซ้อน: WebP หรือ AVIF แบบสูญเสียข้อมูล (lossy) ขนาดไฟล์เล็กที่สุด และสายตาจะมองข้ามการสูญเสียนั้นไปได้
• ข้อความคมชัด ภาพหน้าจอ UI งานศิลปะแบบเส้น และโลโก้: ใช้ PNG หรือ WebP แบบไม่สูญเสียข้อมูล (lossless) การทำ Quantization จะทำให้ขอบเบลอและเกิด Aliasing
• ส่วนที่ตัดพื้นหลังแบบโปร่งใส (Transparent cutouts): ใช้ WebP หรือ PNG แบบไม่สูญเสียข้อมูล ระวังสิ่งแปลกปลอมรูปฮาโลรอบขอบ Alpha
• แอนิเมชันสั้น ๆ ง่าย ๆ: ใช้ WebP แบบแอนิเมชัน (หรือ AVIF) หลีกเลี่ยงการใช้ GIF สำหรับรายละเอียดใด ๆ
• ต้นฉบับสำหรับเก็บถาวร (Archival masters): เก็บไฟล์ RAW ต้นฉบับ หรือ JPEG คุณภาพสูงเสมอ อย่าถือว่าการส่งออกแบบสูญเสียข้อมูลเป็นต้นฉบับหลัก
• ตัวสำรองเพื่อความเข้ากันได้สูงสุด (Maximum compatibility fallback): ใช้ JPEG โดยส่งผ่านองค์ประกอบ <picture> เพื่อให้เบราว์เซอร์สมัยใหม่ยังคงได้รับ AVIF หรือ WebP

ขั้นตอนการทำงานที่ปฏิบัติได้จริงตามลำดับ: เก็บไฟล์ต้นฉบับให้สะอาด, ปรับขนาดให้ตรงกับกล่องแสดงผลที่ใหญ่ที่สุดด้วย Image Resizer, เลือกรูปแบบตามเนื้อหา, ส่งออกตัวเลือกคุณภาพสองถึงสามแบบ, ลบ metadata ที่ไม่จำเป็นออก, และตรวจสอบผลลัพธ์ที่ขนาดการแสดงผลสุดท้าย คู่มือ compress images without losing quality guide จะแนะนำตลอดกระบวนการ คุณยังสามารถอ้างอิง image format guidance ของ Google สำหรับบันทึกการรองรับเบราว์เซอร์เมื่อคุณตั้งค่าตัวสำรอง (fallbacks)

ข้อผิดพลาดทั่วไปในการบีบอัด

• การบีบอัด JPEG ที่มีการสูญเสียคุณภาพไปแล้วซ้ำๆ ทุกการเข้ารหัสจะเพิ่มสิ่งแปลกปลอม (artifacts) ควรแก้ไขจากไฟล์ต้นฉบับเสมอ
• การใช้ PNG กับภาพถ่ายทุกรูปเพราะรู้สึกว่าปลอดภัยกว่า เนื่องจาก PNG ไม่มีขั้นตอนการควอนไทซ์ (quantization step) ภาพจึงมีขนาดใหญ่มาก
• การเชื่อถือตัวเลขคุณภาพเดียวข้ามรูปแบบไฟล์ต่างๆ เนื่องจากมาตราส่วนของ JPEG, WebP และ AVIF ไม่สามารถเปรียบเทียบกันได้
• การปรับปรุงให้เหมาะสมก่อนการย่อขนาด (resizing) ควรลดขนาดลงก่อน เพราะนั่นคือวิธีประหยัดไบต์ที่ใหญ่ที่สุดที่มีอยู่
• การให้บริการไฟล์ AVIF หรือ WebP โดยไม่มีตัวสำรอง (fallback) เป็น JPEG เนื่องจากเว็บเบราว์เซอร์รุ่นเก่าและไคลเอนต์อีเมลส่วนใหญ่จะไม่แสดงผลอะไรเลย
• การคงค่าการสุ่มตัวอย่างโครมา (chroma subsampling) แบบ 4:2:0 บนข้อความสี ซึ่งจะทำให้สีแดงและสีน้ำเงินเลอะเทอะ ควรใช้ 4:4:4 หรือ PNG สำหรับข้อความ
• การละเลยต้นทุนในการเข้ารหัส (encoding cost) แม้ว่าข้อได้เปรียบของ AVIF จะเป็นเรื่องจริง แต่การเข้ารหัสในทุกคำขออาจทำให้ CPU ทำงานหนักเกินไป

สรุป: อัลกอริทึมเป็นเพียงเครื่องมือ ไม่ใช่เป้าหมาย

อัลกอริทึมการบีบอัดไม่ใช่สิ่งที่ได้มาฟรีๆ แม้ว่า AVIF จะให้ไฟล์ที่เล็กที่สุด แต่ค่าใช้จ่ายในการเข้ารหัสอาจสูงมากใน hot path และการถอดรหัสก็หนักกว่า JPEG บนอุปกรณ์ระดับต่ำ PNG นั้นสูญเสียข้อมูลเป็นศูนย์อย่างสมบูรณ์แบบ แต่การนำไปใช้สำหรับภาพถ่ายหลัก (hero photograph) จะทำให้ Largest Contentful Paint ของคุณบวมโดยไม่มีประโยชน์ที่มองเห็นได้ คำตอบที่ถูกต้องเกือบจะเป็นการตัดสินใจเลือกรูปแบบตามเนื้อหา (format-per-content decision) ที่มาพร้อมกับการสำรองข้อมูล (fallback) ไม่ใช่การตั้งค่าระดับโลกเพียงอย่างเดียว

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

เครดิตรูปภาพ

• ลวดลายพิกเซลแบบนามธรรมสีน้ำเงินและชมพู — photo by Suzy Hazelwood on Pexels
• แถบรูปแบบทดสอบสีสันสดใส — photo by Tim Mossholder on Pexels
• ภาพระยะใกล้ของโค้ดต้นฉบับสีสันสดใสบนหน้าจอ — photo by Pixabay on Pexels