ปรับขนาดภาพก่อน แล้วค่อยวางคิวอาร์โค้ด

เราเริ่มจาก URL แคมเปญสมมติ 12 รายการ ปลายทางสี่ประเภทแทนเวิร์กช็อป หนังสือของครีเอเตอร์ สินค้า และคลาสถ่ายภาพ แต่ละประเภทมี URL แบบสั้น แบบใส่พารามิเตอร์แคมเปญ และแบบยาวที่เพิ่มพารามิเตอร์อีก ทุกครั้งที่เปรียบเทียบขั้นตอนผลิต เราใช้ URL แบบเต็มที่เหมือนกัน

แต่ละ URL เข้ารหัสด้วยระดับการแก้ไขข้อผิดพลาดสองระดับและบันทึกเป็นไฟล์สองรูปแบบ จึงได้ 48 ไฟล์ต่อขั้นตอนส่งออกในแต่ละขนาดภาพ นี่คือการนำ URL 12 รายการมาทดลองซ้ำด้วยเงื่อนไขต่างกัน ไม่ใช่ลูกค้า 48 ราย แคมเปญ 48 แคมเปญ หรือการทดลองอิสระ 48 ครั้ง ก่อนเริ่มเปรียบเทียบไฟล์ส่งออก โปรแกรมทั้งสองอ่านภาพต้นฉบับขนาดใหญ่ครบทั้ง 24 ภาพได้สำเร็จ^[1]

ความต่างชัดที่สุดที่ขนาด 540 × 540 พิกเซล เมื่อย่อภาพที่ทำเสร็จแล้ว โปรแกรมทั้งสองกู้คืน URL ได้ตรงต้นฉบับจาก 16 ใน 48 ไฟล์ เมื่อย่อพื้นหลังก่อนแล้วใส่คิวอาร์โค้ดในขนาดสุดท้าย โปรแกรมทั้งสองกู้คืนได้ครบ 48 ไฟล์ ผลที่ดีขึ้นพบทั้งสองระดับการแก้ไขข้อผิดพลาด และทั้ง PNG กับ JPEG

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

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

คิวอาร์โค้ดคือตารางของช่องสี่เหลี่ยมเล็ก ๆ ที่เรียกว่าโมดูล ลิงก์และการตั้งค่าเข้ารหัสเป็นตัวกำหนดตารางนี้ DENSO WAVE ผู้พัฒนา QR Code อธิบายว่าข้อมูลที่ยาวขึ้นและการตั้งค่าการแก้ไขข้อผิดพลาดที่ต่างกันอาจต้องใช้ตารางใหญ่ขึ้น คิวอาร์โค้ดมาตรฐานยังต้องเว้นพื้นที่ว่างรอบทั้งสี่ด้าน ด้านละสี่โมดูล พื้นที่นี้เรียกว่า quiet zone^[2][3]

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

ตัวอย่างที่วัดได้ช่วยให้เห็นภาพ URL เวิร์กช็อปแบบยาวมี 199 ไบต์ เมื่อใช้การแก้ไขข้อผิดพลาดระดับ M จะได้ตาราง 57 × 57 โมดูล หากรวมขอบว่างจะกว้าง 65 โมดูล ภาพต้นฉบับใช้ห้าพิกเซลต่อโมดูล พื้นที่รวมขอบว่างจึงกว้าง 325 พิกเซล

เมื่อย่อภาพให้กว้าง 540 พิกเซล พื้นที่นั้นจะถูกย่อลงเหลือความกว้างเชิงคำนวณ 81.25 พิกเซล และระยะระหว่างขอบโมดูลเท่ากับ 1.25 พิกเซล โปรแกรมทั้งสองไม่สามารถกู้คืน URL จาก PNG ที่ได้ แต่เมื่อวาดตารางเดิมโดยตรงในขนาดสุดท้าย จะใช้หนึ่งพิกเซลต่อโมดูลและกินพื้นที่เล็กลงเหลือ 65 พิกเซล โปรแกรมทั้งสองกลับกู้คืน URL ได้ครบ

นี่คือการเปรียบเทียบขั้นตอนส่งออกสองแบบทั้งกระบวนการ ขนาดที่โค้ดใช้จริง ตำแหน่ง และการกรองภาพเปลี่ยนไปพร้อมกัน จึงไม่ได้แยกทดสอบสาเหตุใดสาเหตุหนึ่ง แต่ช่วยอธิบายว่าทำไมคำสั่งว่า “ทำคิวอาร์โค้ดในต้นฉบับให้ใหญ่ขึ้น” จึงยังไม่ครบ ในตัวอย่างนี้ โค้ดที่เล็กกว่าในไฟล์สุดท้ายกลับเป็นโค้ดที่โปรแกรมอ่านได้

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

เมื่อดูทุกขนาด จะเห็นขอบเขตการใช้ผลหลักได้ชัดขึ้น ที่ความกว้าง 1,080, 720 และ 540 พิกเซล โปรแกรมทั้งสองอ่านไฟล์ที่ใส่โค้ดขั้นตอนสุดท้ายได้ทุกไฟล์ แต่การย่อภาพที่ทำเสร็จแล้วให้ผลอีกแบบหนึ่ง คือผ่านทั้งสองโปรแกรม 32, 37 และ 16 ไฟล์ตามลำดับ จาก 48 ไฟล์ในแต่ละขนาด

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

ที่ความกว้าง 360 พิกเซล พื้นที่คิวอาร์โค้ดเหลือเพียง 60 × 60 พิกเซล บางตารางต้องการความกว้างรวมขอบว่าง 65 หรือ 85 โมดูล จึงใส่ไม่ได้แม้จะใช้เพียงหนึ่งพิกเซลต่อโมดูล เราบันทึก 24 กรณีนี้ว่าไม่สามารถสร้างตามขั้นตอนใส่โค้ดสุดท้ายได้ ไม่ได้นับเป็นความล้มเหลวของโปรแกรมอ่าน

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

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

การแก้ไขข้อผิดพลาดช่วยให้โปรแกรมอ่านกู้คืนข้อมูลที่เข้ารหัสไว้เมื่อข้อมูลบางส่วนเสียหาย การเพิ่มระดับอาจทำให้ต้องใช้ตารางใหญ่ขึ้นแม้เนื้อหาเท่าเดิม การเปรียบเทียบ M กับ H ของเราจึงมีข้อแลกเปลี่ยนจริงภายในพื้นที่จำกัด การตั้งค่าสูงขึ้นไม่ได้เพียงเพิ่มการป้องกันให้ภาพที่เหมือนเดิมทุกอย่าง^[7]

ที่ความกว้าง 540 พิกเซล ภาพที่ย่อหลังจัดวางเสร็จผ่านทั้งสองโปรแกรมห้าจาก 12 ไฟล์เมื่อใช้ M และสามไฟล์เมื่อใช้ H ในแต่ละรูปแบบไฟล์ แต่ H ดีกว่าในคู่เปรียบเทียบอื่น ได้แก่ URL แบบละเอียดแปดคู่ที่ขนาด 1,080 พิกเซล และ PNG ของ URL แบบมีพารามิเตอร์แคมเปญสองคู่ที่ขนาด 720 พิกเซล การบอกว่า “เลือกระดับต่ำกว่าเสมอ” จึงไม่ตรงกับผลทดลอง

รูปแบบไฟล์ก็ไม่ได้มีอันดับที่ตายตัว ที่ขนาด 720 พิกเซลและระดับ M โปรแกรมทั้งสองอ่านไฟล์จากการย่อภาพเสร็จแล้วได้ 10 ไฟล์สำหรับ PNG และ 12 ไฟล์สำหรับ JPEG ไม่ได้หมายความว่า JPEG เป็นตัวเลือกที่ปลอดภัยกว่าโดยทั่วไป แต่แสดงว่าผลของรูปแบบหนึ่งไม่ควรถูกนำไปใช้กับอีกรูปแบบโดยอัตโนมัติ

โปรแกรมทั้งสองให้ผลไม่ตรงกันใน 54 จาก 360 ไฟล์ที่สร้าง ที่ขนาด 1,080 และ 720 พิกเซล ZXing-C++ อ่านได้ทุกไฟล์ ส่วนผลของ quirc ทำให้จำนวนที่ผ่านทั้งสองโปรแกรมต่ำลง ที่ขนาด 540 พิกเซล ผลของแต่ละโปรแกรมดีขึ้นแยกกันเมื่อใส่คิวอาร์โค้ดสุดท้าย เราใช้ผลที่ตรงกันเป็นผลลัพธ์หลัก และเก็บผลรายโปรแกรมไว้ในไฟล์ดาวน์โหลด

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

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

แคมเปญและการใช้งาน: [ระบุชื่อแคมเปญ สิ่งที่ต้องการให้ผู้ใช้ทำหลังอ่านโค้ด และตำแหน่งที่จะใช้ภาพนี้] ผู้ดูแลลิงก์: [ระบุผู้มีสิทธิ์อนุมัติปลายทางและพารามิเตอร์] URL แบบเต็มที่อนุมัติแล้ว: [วางข้อความตรงตามต้นฉบับ รวมพารามิเตอร์ที่จำเป็นและรหัสเปอร์เซ็นต์ทุกตัว]

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

การเข้ารหัสและส่งออก: [ระบุเครื่องมือสร้าง ระดับการแก้ไขข้อผิดพลาด และตัวเลือกที่เกี่ยวข้อง] ลำดับการเตรียม: [ระบุว่าใส่โค้ดเมื่อได้ขนาดสุดท้ายแล้วหรือไม่] รูปแบบที่บันทึก: [PNG หรือ JPEG พร้อมการตั้งค่า] ไฟล์ส่งมอบ: [บันทึกชื่อไฟล์หรือตัวระบุที่ชัดเจนว่าเป็นไฟล์ใด]

ตรวจไฟล์: [ระบุโปรแกรมอ่านที่ใช้ ไฟล์ที่ทดสอบ และผล] URL ที่อ่านได้: [เปรียบเทียบข้อความที่คืนมาทั้งหมดกับ URL ที่อนุมัติ] ผลที่ยังไม่แก้ไข: [บันทึกการอ่านไม่สำเร็จ ผลไม่ตรงกัน หรือปัญหาใส่โค้ดไม่พอ พร้อมผู้รับผิดชอบแก้ไข] อย่าใส่เครื่องหมายผ่านแทนผลที่ยังไม่ได้ทดสอบ

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

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

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

URL ที่อนุมัติคือตัวอย่างเวิร์กช็อป 199 ไบต์ในไฟล์ดาวน์โหลด ชื่อแคมเปญคือ autumn_2026 สื่อคือ qr และช่อง content ระบุครีเอเตอร์พาร์ตเนอร์สมมติ รายละเอียดเหล่านี้อยู่ใน URL ของทั้งสองขนาด ครีเอเตอร์ไม่ลบออกเพื่อลดปริมาณข้อมูลในโค้ด

บันทึกส่งมอบตัวอย่างระบุ PNG ขนาด 540 × 540 พิกเซล พร้อมพื้นที่คิวอาร์โค้ด 90 × 90 พิกเซล เริ่มที่ x=378, y=378 ใช้การเข้ารหัสระดับ M ที่วัดไว้ คือกริด 57 โมดูล ขอบว่างสี่โมดูล และหนึ่งพิกเซลเต็มต่อโมดูล พื้นที่รวมสุดท้ายมีขนาด 65 × 65 พิกเซล วางกึ่งกลางบริเวณที่กันไว้

ดีไซเนอร์ย่อพื้นหลังก่อนแล้วจึงใส่ตารางโค้ดนั้น บันทึกระบุไฟล์ที่บันทึกและผลที่วัดได้ว่า ZXing-C++ กับ quirc คืน URL ต้นฉบับได้ครบถ้วนทั้งคู่ พร้อมบันทึกผลของอีกวิธีว่าไม่มีโปรแกรมใดกู้คืน URL จาก PNG คู่กันที่ย่อจากต้นฉบับซึ่งทำเสร็จแล้วได้ ผลสองรายการนี้มาจากการทดลอง ไม่ใช่แคมเปญลูกค้าจริง

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

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

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

เรากำหนด URL สมมติ 12 รายการ เค้าโครงภาพ ขนาด และการตั้งค่าก่อนอ่านไฟล์ทดสอบ URL ใช้ example.com และเราไม่เคยส่งคำขอไปยัง URL เหล่านั้น ปลายทางสี่กลุ่มมีรูปแบบข้อมูลกลุ่มละสามแบบ ยาว 39–203 ไบต์ ทดสอบการแก้ไขข้อผิดพลาด M และ H ความกว้างภาพสี่ขนาด และรูปแบบไฟล์สองแบบ รวมสองขั้นตอนเป็นเงื่อนไขไฟล์ที่วางแผนไว้ 384 เงื่อนไข^[1]

Segno 1.6.6 สร้างคิวอาร์โค้ดมาตรฐานในโหมดไบต์ โดยปิดการเพิ่มระดับการแก้ไขข้อผิดพลาดอัตโนมัติ แต่ละคู่ URL กับระดับการแก้ไขถูกเข้ารหัสครั้งเดียว และทั้งสองขั้นตอนใช้เมทริกซ์เดียวกันทุกจุด ภาพต้นฉบับเป็นสี่เหลี่ยมกว้าง 2,160 พิกเซล Pillow 13.0.0 ย่อด้วย LANCZOS หนึ่งครั้ง JPEG ใช้คุณภาพ 85 และปิดการลดความละเอียดข้อมูลสี ทุกโค้ดเป็นสีดำบนพื้นขาวพร้อมขอบว่างสี่โมดูล^[4]

โปรแกรมทั้งสองได้รับภาพที่บันทึกทั้งใบเหมือนกัน หลังแปลงเป็นภาพระดับเทา 8 บิต เราใช้ ZXing-C++ 3.1.1 และ quirc รุ่นบิลด์ที่ตรึงไว้พร้อมการตั้งค่าคงที่ การกู้คืนแบบตรงต้นฉบับต้องได้ไบต์ URL เดิม และไม่มีผลถอดรหัสสำเร็จอื่นที่ขัดแย้งกัน ไม่มีการตัดภาพเพิ่ม ขยายแล้วลองใหม่ หรือช่วยแก้ด้วยมือ แพ็กเกจเก็บการตั้งค่าโปรแกรมอ่าน รูปทรงและตำแหน่งรายไฟล์ และผลลัพธ์ไว้^[5]

ต้นฉบับทั้ง 24 ภาพผ่านโปรแกรมทั้งสอง จากไฟล์ส่งออกที่วางแผนไว้ 384 เงื่อนไข สร้างได้ 360 ไฟล์ และ 24 เงื่อนไขสร้างด้วยวิธีใส่โค้ดสุดท้ายไม่ได้ จึงเหลือคู่เปรียบเทียบขั้นตอน 168 คู่ เราเก็บทุกเงื่อนไขไว้ รวมผลไม่ตรงกัน ไฟล์ที่สร้างได้แต่ไม่ผ่าน และคู่ที่ระดับการแก้ไขข้อผิดพลาดฝ่ายใดฝ่ายหนึ่งทำได้ดีกว่า ผลอธิบายไฟล์สังเคราะห์และซอฟต์แวร์บิลด์เหล่านี้ ไม่ใช่อัตราการสแกนของผู้บริโภค

คำแนะนำที่มีอยู่แล้วอธิบายความสำคัญของพื้นที่ ขอบว่าง และคุณภาพภาพ QRotto ยังเผยแพร่การเปรียบเทียบความละเอียดต้นฉบับหลังปรับสเกลและทำภาพเบลอ งานของเรามีขอบเขตแคบกว่า คือเปรียบเทียบตำแหน่งของขั้นตอนวางคิวอาร์โค้ดในกระบวนการส่งออกภาพ โดยรักษา URL แบบเต็มและเมทริกซ์ที่เข้ารหัสให้เหมือนกันในแต่ละคู่ ตารางทั้งหมดและรายละเอียดการเตรียมอยู่ด้านล่าง^[6]