หากภาพหมุนแบบไม่มีการสูญเสียขนาดไฟล์จะเปลี่ยนทำไม?

ฉันค้นหาวิธีการหมุนภาพแบบไม่สูญเสียและเกิดขึ้นกับคำถามนี้ซึ่งอธิบายได้ค่อนข้างดี:

การหมุน "ตัวแสดงภาพถ่ายของ Windows" หายไปหรือไม่

ดังนั้นฉันจึงสร้าง JPEG ขนาด 256 × 256 พร้อมพิกเซลแบบสุ่ม (ตัวกรองคลาวด์ Photoshop) แล้วหมุนมันโดยใช้ Windows Picture Viewer หลังจากการหมุนขนาดไฟล์เพิ่มขึ้นจริง แต่เฉพาะในการหมุนครั้งแรก ทุกครั้งที่มีการหมุนตามลำดับขนาดไฟล์จะคงที่ ฉันรู้ว่ามันหมุนแบบไม่สูญเปล่าเพราะฉันหมุนไปหลายครั้งโดยไม่มีการสูญเสียคุณภาพที่เห็นได้ชัดเจนในขณะที่ภาพ 257 × 257 ที่ถูกหมุน 20 ครั้งกลายเป็นว่าเสียมาก

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

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

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

• ทางเลือกของการเข้ารหัสทางคณิตศาสตร์ (หายาก แต่อาจมีประสิทธิภาพมากกว่าเคยใช้การจดสิทธิบัตร) กับการเข้ารหัส Huffman (ง่ายกว่ามาตรฐาน);
• ตัวเลือกลำดับต่อเนื่อง (บล็อก 8x8 พิกเซลแต่ละรายการจะถูกเข้ารหัสทีละรายการ) เทียบกับแบบก้าวหน้า (ส่วนประกอบความถี่ต่ำของบล็อกทั้งหมดจะถูกเข้ารหัสก่อนส่วนประกอบความถี่สูงมักจะมีขนาดเล็กกว่าเล็กน้อย) ลำดับการเข้ารหัส
• ตัวเลือกในการใช้ตารางสัญลักษณ์ Huffman มาตรฐาน (เร็วกว่าง่ายกว่าอาจมีประสิทธิภาพสำหรับรูปภาพขนาดเล็กมาก) เทียบกับตารางแบบกำหนดเองที่ปรับให้เหมาะสมสำหรับแต่ละรูปภาพ (โดยทั่วไปจะมีประสิทธิภาพมากกว่าสำหรับรูปภาพขนาดใหญ่ช้าลงและซับซ้อนกว่าในการเข้ารหัส)
• หากใช้ตาราง Huffman แบบกำหนดเองตัวเข้ารหัสที่แตกต่างกันอาจสร้างตารางที่แตกต่างกันสำหรับข้อมูลภาพเดียวกัน
• รายละเอียดระดับต่ำต่าง ๆ ของกระบวนการเข้ารหัสเองเช่นว่าจะรวมตัวทำเครื่องหมายรีสตาร์ทในสตรีมข้อมูลหรือไม่และเมื่อใดอาจแตกต่างกันระหว่างตัวเข้ารหัส

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

โดยเฉพาะอย่างยิ่งข้อมูลเมตาของ JFIF / Exif อาจมีภาพขนาดย่อหนึ่งภาพหรือมากกว่าและซอฟต์แวร์ที่หมุนภาพควรสร้างภาพขนาดย่อใหม่ (หรือหมุนแบบไม่สูญเสีย!) เพื่อให้ตรงกับทิศทางใหม่ของภาพขนาดเต็ม ภาพขนาด สิ่งนี้เพียงอย่างเดียวสามารถอธิบายความแตกต่างของขนาดที่สังเกตได้อย่างง่ายดาย

ฉันไปข้างหน้าและทำการทดสอบซ้ำอีกครั้งเพื่อดูว่าฉันสามารถทราบได้ว่าเกิดอะไรขึ้น

ขั้นตอน

ฉันสร้างภาพ RGB ขนาด 256 x 256 พิกเซลแบบสุ่มโดยใช้ฟิลเตอร์ "Solid Noise" ใน GIMP (ตัวกรอง> Render> Clouds> Solid Noise ... ) โดยใช้การตั้งค่าเริ่มต้น (ดังที่แสดงด้านล่าง):

และผลลัพธ์:

จากนั้นฉันบันทึกภาพเป็น JPEG โดยใช้การตั้งค่าเริ่มต้น:

จากนั้นฉันถ่ายโอนรูปภาพไปยัง Windows และเปิดรูปภาพด้วย Windows Photo Viewer โดยคลิกขวาที่รูปภาพใน File Explorer และเลือกดูตัวอย่างจากเมนู จากนั้นฉันหมุนภาพโดยใช้ปุ่มที่ด้านล่างและบันทึกภาพโดยไปที่ภาพถัดไปโดยใช้ปุ่มลูกศร

สำหรับการทดสอบด้านล่างแต่ละครั้งฉันเริ่มต้นด้วยการคัดลอกภาพต้นฉบับและหมุน (คลิกที่ปุ่มหมุน) จำนวนครั้งที่สอดคล้องกันก่อนที่จะบันทึก นี่คือขนาด reslting ( ls -l -r):

                    size in bytes    last-modified date 
                          VVVVV        VVVVV
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:24 original.jpg
-rwxrwx--- 1 root vboxsf  23645 Nov  8 11:30 cw.jpg
-rwxrwx--- 1 root vboxsf  23636 Nov  8 11:30 cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:30 cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:27 cw-cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:31 cw-cw-cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:29 ccw.jpg
-rwxrwx--- 1 root vboxsf  23636 Nov  8 11:29 ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf  23645 Nov  8 11:29 ccw-ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:27 ccw-ccw-ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:30 ccw-ccw-ccw-ccw-ccw.jpg

สังเกตได้ทันที

• Windows Photo Viewer (WPV) เพิ่มขนาดอย่างรวดเร็ว จำนวนเพิ่มขึ้นประมาณสี่เท่าในการทดสอบนี้!
• รูปภาพใหม่ทั้งหมดจะเพิ่มขนาดใกล้เคียงกัน แต่ไม่เหมือนกัน
• WPV ไม่ได้เข้ารหัสซ้ำอีกครั้งหรือแม้กระทั่งบันทึกภาพอีกครั้งเมื่อมันหมุนไปหลายรอบ 360 องศา (การประทับเวลา 11:27 คือเมื่อไฟล์ถูกคัดลอกครั้งแรก)

การใช้cmp -lไฟล์ที่ควรมีเนื้อหาเหมือนกันทำให้เราเห็นว่าไฟล์แตกต่างกันอย่างไร

robert@unity ../jpeg-rotate-test % cmp -l cw.jpg ccw-ccw-ccw.jpg
 2223  63  62
 2224  60  71
 2226  60  64
 2227  60  66
robert@unity ../jpeg-rotate-test % cmp -l cw-cw.jpg ccw-ccw.jpg
 2223  63  62
 2224  60  71
 2226  60  64
 2227  62  64
robert@unity ..jpeg-rotate-test % cmp -l ccw.jpg cw-cw-cw.jpg
 2223  62  63
 2224  71  60
 2226  64  60
 2227  61  64
robert@unity ../jpeg-rotate-test % cmp -l cw.jpg cw-cw-cw-cw-cw.jpg
 2221  60  61
 2223  63  61
 2224  60  66
 2226  60  61
 2227  60  61
robert@unity ../jpeg-rotate-test % cmp -l ccw.jpg ccw-ccw-ccw-ccw-ccw.jpg
 2223  62  63
 2224  71  60
 2226  64  65
 2227  61  64

ไฟล์เหล่านี้แตกต่างกันในสี่ไบต์เท่านั้น (จริง ๆ แล้วในการประทับเวลา), หมายความว่า WPV กำลังทำสิ่งเดียวกันทุกครั้ง; ตอนนี้เราแค่ต้องหาว่ามันคืออะไร

การสังเกตอย่างละเอียด

สำหรับเรื่องนี้ฉันใช้JPEGsnoopเพื่อดูว่าสิ่งที่อยู่ในภาพ

ตั้งแต่เอาท์พุทจะค่อนข้างนานฉันได้เชื่อมโยงกับพวกเขาเป็นส่วนสำคัญ นี่คือบทสรุปของความแตกต่าง:

• GIMP ใช้เฉพาะส่วนAPP0(JFIF) และCOM(ความคิดเห็น) สำหรับข้อมูลเมตา WPV ออกจากAPP0ส่วนที่ไม่ได้แตะ แต่อยากรู้อยากเห็นเพิ่มเป็นโมฆะไบต์ไปที่ความคิดเห็น (เพื่อให้มันถูกยกเลิก null)

• WPV เพิ่มสองAPP1ส่วนซึ่งเป็นข้อมูลเมตา Exif และ XMP กลุ่มเหล่านี้มี 4286 และ 12726 ไบต์ตามลำดับ พวกเขาช่วยกันคิดว่าเพิ่มขนาดไฟล์เกือบทั้งหมด

• GIMP สร้าง JPEG แบบโปรเกรสซีฟในขณะที่ WPV จะสร้าง JPEG แบบพื้นฐาน (แบบไม่ก้าวหน้า) ด้วยเหตุนี้รูปภาพของ GIMP จึงมีหลายส่วนการสแกนในขณะที่รูปภาพ WPV มีเพียงส่วนเดียว จากประสบการณ์ของฉันภาพความก้าวหน้าบางครั้งก็เล็กกว่าเล็กน้อย

• คนพิการใช้การสุ่มตัวอย่าง chroma 1 × 1 ในขณะที่ WPV ใช้การสุ่มตัวอย่างแบบ 2 × 2 สิ่งนี้ทำให้ฉันเชื่อว่า WPV ไม่ได้ใช้การหมุนแบบไม่สูญเสีย "ของจริง" ยกเว้นว่าจะสามารถตรวจจับได้ว่านี่เป็นภาพขาวดำ

เพื่อแก้ไขปัญหาเหล่านี้ฉันได้ทำการทดสอบครั้งที่สอง

ขั้นตอน

ฉันทำตามขั้นตอนที่คล้ายคลึงกับการทดสอบครั้งแรก ฉันสร้างภาพ RGB แบบสุ่ม 256 × 256 โดยใช้ตัวกรองสัญญาณรบกวน RGB (ตัวกรอง> จมูก> จมูก RGB ... ) ด้วยการตั้งค่าต่อไปนี้:

นี่คือผลลัพธ์:

ฉันส่งออกไฟล์เป็น JPEG โดยใช้การตั้งค่าต่อไปนี้:

Progressiveถูกปิดใช้งาน แต่Subsamplingยังคงถูกตั้งค่าเป็น 4: 4: 4 (ซึ่งเป็นอีกชื่อหนึ่งสำหรับSubsampling 1 × 1) คุณภาพเพิ่มขึ้นเป็น 98

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

ผล

-rwxrwx--- 1 root vboxsf 159774 Nov  8 16:21 original-random.jpg
-rwxrwx--- 1 root vboxsf 222404 Nov  8 16:24 cw-random.jpg
-rwxrwx--- 1 root vboxsf 222467 Nov  8 16:24 cw-ccw-random.jpg

แม้ว่าการเพิ่มขึ้นในครั้งนี้จะน้อยกว่าในแง่ที่เกี่ยวข้อง (ประมาณ 40%) การเพิ่มขึ้นแน่นอนนั้นยิ่งใหญ่กว่า - ประมาณ 62 kB สิ่งนี้ชี้ให้เห็นว่า WMV ใช้การเข้ารหัสที่มีประสิทธิภาพน้อยกว่า

ฉันจะใช้ImageMagickเพื่อเปรียบเทียบภาพสองภาพ:

robert@unity ../jpeg-rotate-test % compare -verbose -metric AE original-random.jpg cw-ccw-random.jpg null:
original-random.jpg JPEG 256x256 256x256+0+0 8-bit sRGB 160KB 0.000u 0:00.009
cw-ccw-random.jpg JPEG 256x256 256x256+0+0 8-bit sRGB 222KB 0.010u 0:00.010
Image: original-random.jpg
  Channel distortion: AE
    red: 0
    green: 0
    blue: 0
    all: 0
original-random.jpg=> JPEG 256x256 256x256+0+0 8-bit sRGB 0.050u 0:00.020

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

อัลกอริธึมการบีบอัด JPEG แบ่งภาพออกเป็นบล็อกขนาด 8 × 8 พิกเซล หนึ่งในบล็อกเหล่านี้แต่ละครั้งจะถูกยัดเยียดไปแล้วโคไซน์ไม่ต่อเนื่อง Transform (DCT) สัมประสิทธิ์ DCT ที่ได้นั้นอธิบายถึงบล็อกว่าเป็นผลรวมของคลื่นความถี่ที่แตกต่างกัน อัลกอริทึม "โยน" ข้อมูลบางอย่างในคลื่นความถี่สูงที่ตรงกับเสียงรบกวนและรายละเอียดที่น้อยมาก กระบวนการถอดรหัสจะกลับ DCT เพิ่มคลื่นที่จัดเก็บไว้ด้วยกันเพื่อกลับบล็อก

เป็นไปได้ที่จะหมุน "คลื่น" DCT โดยไม่ต้องยกเลิกและทำการแปลงซ้ำ (โดยทั่วไปคุณเปลี่ยนคลื่นแนวนอนทั้งหมดเป็นคลื่นแนวตั้งและในทางกลับกัน) สิ่งที่ฉันคิดว่าเกิดขึ้นใน WPV คือภาพถูกถอดรหัสหมุนแล้วเข้ารหัสใหม่ ในระหว่างกระบวนการเข้ารหัสอีกครั้งเนื่องจากขนาดของภาพของเราเป็น 8 เท่าในทั้งสองมิติแต่ละบล็อกใหม่จะสอดคล้องกับหนึ่งในบล็อกเดิม ที่สำคัญเนื่องจากแต่ละบล็อกไม่มีส่วนประกอบที่มีความถี่สูงอัลกอริทึมจึงไม่ทิ้งข้อมูลใด ๆ และค้นหาส่วนประกอบ DCT ที่ถูกต้องที่การหมุนแบบไม่สูญเสีย "ที่แท้จริง" จะมี

สุดท้ายนี้ฉันจะดูส่วนประกอบของไฟล์ JPEG อีกครั้ง ผลลัพธ์จะถูกเชื่อมโยงอีกครั้งในฐานะส่วนสำคัญ เปรียบเทียบทั้งสอง:

• อิมเมจ WPV มีขนาดพิเศษ 4286 + 2 ไบต์ของข้อมูลเมตา Exif, 1 ไบต์พิเศษในความคิดเห็นและ 12,726 + 2 ไบต์ของข้อมูลเมตา XMP นี่คือเมตาดาต้าเพิ่มเติมทั้งหมด 17,017 ไบต์ ข้อมูลทั้งหมดที่ใช้มีไว้เพื่ออะไร? ฉันอ่านไฟล์ด้วยโปรแกรมแก้ไข hex ที่เชื่อถือได้และสำเนามาตรฐานที่เกี่ยวข้อง:

  • Exif เมตาดาต้าที่มีโครงสร้างเช่นรูปแบบ TIFF ซึ่งมีจำนวนของแท็ก (มีวิธีอื่น ๆ อีกมากมายซับซ้อน แต่ฉันจะมองข้ามไปได้) ไบต์ส่วนใหญ่ในส่วน Exif มีอยู่ในสองแท็กเหมือนกันที่มีหมายเลขแท็กEA1C(59,932 ทศนิยม) หมายเลขแท็กนั้นไม่ได้บันทึกไว้ทุกที่ที่ฉันพบ แท็กทั้งสองมีประเภท "ไม่ได้กำหนด" 2060 ไบต์ซึ่งเป็นไบต์ว่างทั้งหมดยกเว้นหกตัวแรก ( 1C EA 00 00 00 08) ฉันไม่รู้ว่าแท็กเหล่านี้คืออะไรทำไมมีสองแท็กและทำไมต้องเป็น 2 kB

  • ข้อมูลเมตา XMP เป็นเอกสาร XML แบบฝังทั้งหมดที่มีเนมสเปซและ UUID แบบยาวซึ่งเพิ่งมีสตริงรุ่น WPV (ที่มีอยู่แล้วในข้อมูลเมตาของ Exif) อย่างไรก็ตามบัญชีนั้นมีขนาดประมาณ 400 ไบต์เท่านั้น ส่วนที่เหลือของส่วนที่เป็น122 ซ้ำ 100 เว้นวรรคตามด้วยการขึ้นบรรทัดใหม่ นั่นคือพื้นที่ว่างมากกว่า 12,000 ไบต์

• เช่นเดียวกับการทดสอบก่อนหน้านี้ GIMP และ WPV ใช้ตารางการควอนตัม DCT เดียวกัน ซึ่งหมายความว่าพวกเขาควรจะคำนวณค่าสัมประสิทธิ์ DCT ที่แน่นอนเหมือนกันซึ่งเป็นสาเหตุที่ภาพเหมือนกันทุกประการ ฉันไม่แน่ใจว่า WPV เพิ่งจะใช้ตาราง quantization เดียวกันหรือถ้ามันคัดลอกตารางจากอินพุต

• แตกต่างจากการทดสอบก่อนหน้าเวลานี้ WPV ใช้การสุ่มตัวอย่าง 1 × 1 ดังนั้นจึงอาจตรวจพบว่านี่เป็นภาพสี

• GIMP และ WPV ใช้ตาราง Huffman ที่แตกต่างกัน (ส่วนหนึ่งของขั้นตอนการเข้ารหัสเอนโทรปี) ตารางสำหรับ WPV มีขนาดใหญ่ขึ้นโดยรวม 279 ไบต์และในกรณีหนึ่งมี 7 ครั้งเป็นรหัสจำนวนมาก

  เมื่อดูสถิติของ JPEGsnoop เราจะเห็นว่าบางรหัสเหล่านี้ไม่ค่อยได้ใช้ ตัวอย่างเช่นในID: 1, Class: ACตารางของรหัส 119 16 บิตที่กำหนดจะใช้เพียง 23 ตัวเท่านั้น โดยรวมส่วนการสแกนจริงจะใหญ่กว่า 28.5% ในรุ่น WPV

สรุป

• WPV อาจไม่ทำการหมุนแบบ "สูญเสีย" ที่แท้จริง แต่การหมุนดูเหมือนจะไม่สูญเสียไปในทางปฏิบัติ

• ขนาดพิเศษบางส่วนเกิดจากการเพิ่มข้อมูลเมตาคงที่และบางส่วนเนื่องจากการเข้ารหัสเอนโทรปีมีประสิทธิภาพน้อยลง

ข้อมูลรุ่น:

• ระบบปฏิบัติการ (Linux) ( uname -a):

  Linux unity 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux
  

• ระบบปฏิบัติการ (Windows):

  

• GIMP (Linux): 2.8.14 (จากแพ็คเกจgimp, รุ่น2.8.14-1+deb8u1)

  

• Window Photo Viewer (ตามข้อมูลเมตาของรูปภาพ):

  Microsoft Windows Photo Viewer 10.0.10586.0
  

^{แก้ไข : คำตอบนี้ถูกโพสต์ก่อนที่ฉันจะรู้ว่าไฟล์มีขนาดเพิ่มขึ้นประมาณ 9 KiB (9055 bytes สำหรับภาพ 256 × 256, 9612 KiB สำหรับภาพ 512 × 512)}

ในทุกโอกาสเมื่อคุณหมุนภาพเป็นครั้งแรกตัวแสดงรูปภาพของ Windows ทำสิ่งใดสิ่งหนึ่งต่อไปนี้ (หรือทั้งสองอย่าง):

1. เพิ่มแท็ก EXIF ​​ที่ไม่ได้อยู่ในภาพ JPEG ดั้งเดิม (อาจเป็นแท็กการวางแนว)
2. แก้ไข / เพิ่มข้อมูลลงในแท็กที่มีอยู่แล้ว (อาจเป็นซอฟต์แวร์ประมวลผลหรือแท็กซอฟต์แวร์ภาพ)

ทำให้ขนาดไฟล์เพิ่มขึ้นเนื่องจากมีแท็ก EXIF ​​เพิ่มเติม (และ / หรือข้อมูลเพิ่มเติมไปยังแท็กที่มีอยู่)

การหมุนครั้งต่อมาไม่ได้เพิ่มขนาดไฟล์เนื่องจากแท็กและ / หรือข้อมูลแท็กทั้งหมดที่ WPV จะมีการเพิ่ม / แก้ไขมีอยู่แล้ว มีการเปลี่ยนแปลงเฉพาะค่าแท็กการวางแนว(และอาจเป็นค่าแท็กวันที่ / เวลาด้วย)

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

หากไม่มีวิศวกรรมย้อนกลับ jpeg en / decoder จะไม่สามารถพูดได้อย่างแน่นอน จริงๆแล้วมีมาตรฐาน jpeg จำนวนหนึ่งและตรงกันข้ามกับความเชื่อที่ได้รับความนิยมไม่สามารถแก้ไขได้ทั้งหมดโดยไม่ต้องเข้ารหัสใหม่

มันเป็นไปได้ว่าครั้งแรกที่บันทึกคือเขียนสูญเสียลงในรสชาติของมันได้รับการสนับสนุน JPEG และผลัดที่ตามมาเป็นบิดเมตาดาต้าง่ายหรือการดำเนินการโดยตรงบนโต๊ะ DCT (ซึ่งเป็นไปได้สำหรับรูปแบบการเข้ารหัสบางส่วน)

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

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

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

การหมุน JPEG แบบไม่สูญเสียนั้นทำได้โดยไม่ต้องมีการแนะนำสิ่งประดิษฐ์ในขอบเขตหากขนาดภาพเป็นทวีคูณของขนาดบล็อก (โดยทั่วไปคือ [/ always?] 8) ดูหน้า jpegtran man (ขออภัยฉันไม่มีลิงก์แบบบัญญัติที่ดีสำหรับมันโปรดแก้ไขถ้าคุณเจอ) สำหรับรายละเอียดเกี่ยวกับสิ่งที่เกี่ยวข้อง:

การแปลงแบบไขว้ไม่มีข้อ จำกัด เกี่ยวกับ
ขนาดของภาพ การแปลงรูปแบบอื่นนั้นใช้งานได้ค่อนข้างแปลกหากขนาดภาพไม่ได้เป็นหลายขนาดของ iMCU (ใช้ 8 หรือ 16 พิกเซล) เนื่องจากพวกมันสามารถแปลงบล็อกข้อมูลสัมประสิทธิ์ DCT แบบสมบูรณ์ในแบบที่ต้องการเท่านั้น

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

สำหรับการใช้งานจริงคุณอาจต้องการทิ้ง
พิกเซลขอบใด ๆ ที่เปลี่ยนไม่ได้แทนการใช้แถบที่ดูแปลกไปตามขอบ
ด้านขวาและ / หรือด้านล่างของภาพที่ถูกแปลง หากต้องการทำสิ่งนี้เพิ่มสวิตช์ -trim:

ฉันสงสัยว่า Windows Photo Viewer กำลังหลีกเลี่ยงปัญหานี้โดยทำการคลายการบีบอัดและการบีบอัดซ้ำคุณภาพสูงมากเพื่อจำลองพฤติกรรมแบบไม่สูญเสียเมื่อขนาดภาพไม่ได้ทวีคูณเป็น 8 แทนที่จะเป็นการหมุนแบบไม่สูญเสียจริง ยูทิลิตี้ที่ดีจะทำสิ่งที่สูญเสียจริงสิ่งประดิษฐ์และทั้งหมดหรือวางพิกเซลสักสองสามอันแทนที่จะทำลายคุณภาพของภาพทั้งหมด (และเพิ่มขนาดไฟล์)

ฉันไม่มีคำตอบที่ชัดเจน แต่มีบางทฤษฎีที่เป็นไปได้ว่าทำไมถึงเกิดขึ้น ไฟล์บางประเภททำงานด้วยวิธีที่ต่างกันสองรหัสสำหรับรูปภาพประเภทไฟล์นั้นไม่จำเป็นว่าจะต้องสร้างภาพที่แตกต่างกัน ตัวอย่างเช่นประเภทไฟล์ PNG ทำงานในลักษณะนั้นเพราะช่วยให้พื้นหลังโปร่งใส แต่ภาพที่มีพื้นหลังโปร่งใสและเป็นแบบเดียวกันยกเว้นว่าพื้นหลังเดียวกันเป็นสีขาวจะปรากฏในลักษณะเดียวกัน ไฟล์รูปภาพถูกบีบอัดถ้าใช้หน่วยความจำน้อยกว่า 3 ไบต์ต่อพิกเซล ฉันเชื่อว่ายกเว้นไฟล์ที่มีพื้นหลังโปร่งใสไม่มีไฟล์ PNG สองไฟล์ที่สร้างภาพเดียวกัน เมื่อใดก็ตามที่คุณบันทึกรูปภาพเป็น PNG มันจะแปลงเป็นรหัสที่สร้างภาพต้นฉบับและยกเว้นภาพที่ผิดปกติมาก ๆ เช่นภาพที่แต่ละพิกเซลเป็นสีแบบสุ่มของ 2 ^ 24 สีทั้งหมด รหัสจะใช้หน่วยความจำน้อยกว่า 3 ไบต์ต่อพิกเซลดังนั้นการบันทึกในขณะที่ PNG ถูกกล่าวว่าเป็นการบีบอัดแบบไม่สูญเสียข้อมูล ในทางตรงกันข้ามหากต้องการบันทึกหน่วยความจำจะสามารถสร้างได้เฉพาะภาพบางภาพเท่านั้นโดยรหัสของไฟล์ภาพ JPEG อาจมีไฟล์ประเภท JPEG มากกว่าหนึ่งประเภทและฉันไม่ทราบว่ามีหนึ่งในนั้นมีคุณสมบัติที่ภาพสองภาพที่แตกต่างกันของประเภทไฟล์นั้นสามารถสร้างภาพที่แน่นอนได้หรือไม่ ฉันสมมติว่าหลายครั้งที่คุณหมุนภาพแล้วบันทึกเป็น JPEG และจะให้คำอธิบายว่าเกิดอะไรขึ้นภายใต้สมมติฐานว่านั่นคือสิ่งที่คุณทำซึ่งฉันไม่รู้ว่าจริงหรือไม่ การหมุนที่คุณทำนั้นไม่มีความสูญเสียหากมีวิธีการเรียกคืนรหัสไฟล์ภาพที่แน่นอนเหมือนกับที่คุณมีก่อนที่คุณจะหมุนและบันทึกไว้ คุณอาจไม่ถูกต้องว่าคุณได้ทำการหมุนแบบไม่สูญเสีย ถ้ามันเป็นความสูญเสียจริงๆ

เหตุผลที่อยู่เบื้องหลังนี้มีเพียงไม่กี่

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

แต่ทำไมคุณหมุน jpeg 20 ครั้ง?

เนื่องจากการบีบอัดของภาพทำงานอย่างไร รูปแบบใด ๆ เช่น PNG หรือ JPG โดยทั่วไปจะไม่รักษาขนาดไฟล์หลังจากการหมุน

คอมเพรสเซอร์ภาพหมุนเป็นเพียงภาพที่แตกต่างกันเนื่องจากวิธีการแก้ปัญหาการทำงาน compressione มีการรับประกันว่ามันจะบีบอัดภาพหมุนเดียวกันไม่

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

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

การบีบอัดภาพทำงานได้โดยการบีบอัดภาพเป็น 4x4 หรือชิ้นขนาดอื่น ๆ โดยทั่วไปคอมเพรสเซอร์จะเห็นภาพที่หมุนเป็นภาพที่แตกต่างกันอย่างไรก็ตามเนื่องจากก้อนพิกเซลที่บีบอัดเป็นเพียงการสลายตัวเชิงเส้นถ้าชิ้นของภาพเหมือนกันเป็นไปได้ที่จะเพียงแค่ Transpose / Mirror ดังนั้นเมทริกซ์การสลายตัวเชิงเส้นจะคงเดิม คุณภาพ:

โปรดทราบว่าสิ่งนี้จะต้องดำเนินการตามคุณลักษณะต่อและยังอธิบายการเพิ่มขนาดเริ่มต้น => ในการหมุนครั้งแรกมันเพียงแค่พยายามบีบอัดภาพเป็นชิ้น ๆ ที่หมุนได้:

• หากไม่สามารถทำได้คุณภาพของภาพจะลดลง

• หากประสบความสำเร็จจะเพิ่มขนาดเพียงครั้งเดียวทุกครั้งที่หมุนจะคงคุณภาพไว้

• การดำเนินการดังกล่าวจะประสบความสำเร็จเฉพาะในกรณีที่ภาพถูกสร้างขึ้นโดยชิ้นส่วนที่เท่ากัน (ขนาดของรูปภาพมีขนาดหลายเท่า)

คำตอบที่ไม่ถูกต้องและคุณสามารถทำการทดสอบอย่างง่าย:

• เปิดภาพต้นฉบับ: สกรีนช็อต
• หมุนภาพ 4 ครั้งด้วย WPV: จับภาพหน้าจอ
• เปรียบเทียบภาพหน้าจอ 2 ภาพ

คุณจะเห็นภาพที่เปลี่ยนไป (มันถูกบีบอัดใหม่ในการหมุนครั้งแรก) อย่างไรก็ตามการเปลี่ยนแปลงนั้นมีเวลา จำกัด คุณสามารถหมุนได้อีกครั้งโดยไม่มีการสูญเสียคุณภาพ (หากภาพมีขนาดที่เป็นทวีคูณของ 8)

วิธีตอบ OP โดยตรง:

ฉันรู้ว่ามันหมุนแบบไม่สูญเสีย

ไม่ใช่ว่ามันจะไม่หมุน losslessy เสียคุณภาพอย่างน้อยหนึ่งครั้ง (ในการหมุนครั้งแรก: เพราะมันควรบีบอัดมันในแบบที่สามารถหมุนได้) ก่อนจากนั้นมันจะรักษาคุณภาพของมัน