আমি এগিয়ে গেলাম এবং পরীক্ষার পুনরাবৃত্তি করেছিলাম যা দেখতে পাচ্ছি যে আমি কী ঘটছে তা বুঝতে পারি।
কার্যপ্রণালী
আমি জিম্পে "সলিড নয়েজ" ফিল্টার ব্যবহার করে এলোমেলো 256 বাই 256 পিক্সেল আরজিবি চিত্র উত্পন্ন করেছি (ফিল্টার> রেন্ডার> মেঘ> সলিড নয়েজ ...) ডিফল্ট সেটিংস ব্যবহার করে (নীচে দেখানো হয়েছে):
এবং ফলাফল:
তারপরে আমি ডিফল্ট সেটিংস ব্যবহার করে ছবিটিকে জেপিইজি হিসাবে সংরক্ষণ করেছি:
তারপরে আমি উইন্ডোজটিতে চিত্রটি স্থানান্তরিত করেছি এবং ফাইল এক্সপ্লোরারের চিত্রটিতে ডান ক্লিক করে এবং মেনু থেকে প্রাকদর্শনটি বেছে নিয়ে উইন্ডোজ ফটো ভিউয়ারের সাথে চিত্রটি খুললাম । তারপরে আমি নীচের অংশে বোতামগুলি ব্যবহার করে চিত্রটি ঘোরালাম এবং তীর কীগুলি ব্যবহার করে পরবর্তী চিত্রটিতে নেভিগেট করে চিত্রটি সংরক্ষণ করেছি।
নীচের প্রতিটি পরীক্ষার জন্য আমি মূল চিত্রের একটি অনুলিপি দিয়ে শুরু করেছিলাম এবং সংরক্ষণের আগে একই সংখ্যায় ঘোরানো (ঘোরানো বোতামে ক্লিক করা) করেছি। এখানে পুনর্বিবেচনা আকারগুলি ( 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
তাত্ক্ষণিক পর্যবেক্ষণ
- উইন্ডোজ ফটো ভিউয়ার (ডাব্লুপিভি) নাটকীয়ভাবে আকার বাড়ায়; এই পরীক্ষায় বাড়ার পরিমাণ চারগুণ!
- সমস্ত নতুন চিত্র একই আকারে প্রায় বেড়েছে, তবে সেগুলি অভিন্ন নয়।
- চিত্রটি যখন একাধিক ৩ 360০ ডিগ্রি দ্বারা ঘোরা হয় তখন ডাব্লুপিভি পুনরায় এনকোড করে না এমনকি চিত্রটি পুনরায় সংরক্ষণও করে না। (টাইমস্ট্যাম্প, ১১:২: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
এই ফাইলগুলি কেবলমাত্র চারটি বাইটে (আসলে একটি টাইমস্ট্যাম্পে) পৃথক, যার অর্থ ডাব্লুপিভি প্রতিবার একই কাজ করছে; এখন আমাদের কেবল এটি কী তা নির্ধারণ করা দরকার।
বিস্তারিত পর্যবেক্ষণ
এর জন্য আমি ছবিগুলিতে ঠিক কী ছিল তা দেখতে JPEGsnoop ব্যবহার করেছি ।
আউটপুটগুলি যেহেতু বেশ দীর্ঘ, আমি তাদের সাথে সংক্ষেপ হিসাবে যুক্ত করেছি । পার্থক্যের সংক্ষিপ্তসার এখানে:
জিআইএমপি মেটাডেটার জন্য কেবল একটি APP0
(জেএফআইএফ) এবং COM
(মন্তব্য) বিভাগ ব্যবহার করে। ডব্লিউপিভি APP0
বিভাগটিকে অচ্ছুত রেখে দেয় তবে কৌতূহলবশত মন্তব্যে একটি নাল বাইট যুক্ত করে (যাতে এটি নাল-টার্মিনেটেড হয়)।
ডাব্লুপিভিতে দুটি APP1
বিভাগ যুক্ত হয়েছে, যা এক্সিফ এবং এক্সএমপি মেটাডেটা। এই বিভাগগুলি যথাক্রমে 4286 এবং 12726 বাইট। তারা একসাথে ফাইলাইজ মধ্যে প্রায় পুরো বৃদ্ধি জন্য অ্যাকাউন্ট।
জিআইএমপি একটি প্রগতিশীল জেপিইজি উত্পাদন করে, অন্যদিকে ডাব্লুপিভি একটি বেসলাইন (অ প্রগতিশীল) জেপিগ উত্পাদন করে। এই কারণে জিআইএমপির চিত্রটিতে একাধিক স্ক্যান বিভাগ রয়েছে, যখন ডাব্লুপিভি চিত্রের একটি মাত্র রয়েছে। আমার অভিজ্ঞতায় প্রগতিশীল চিত্রটি মাঝে মাঝে কিছুটা ছোট হয়।
জিআইএমপিতে 1 × 1 ক্রোমা সাবসাম্পলিং ব্যবহৃত হয়েছিল, অন্যদিকে ডব্লিউপিভি 2 × 2 সাবসাম্পলিং ব্যবহার করেছিল। এটি আমাকে বিশ্বাস করতে পরিচালিত করে যে ডাব্লুপিভি "সত্য" ক্ষতিহীন ঘূর্ণন ব্যবহার করছে না, যদি না এটি কোনওভাবে সনাক্ত করতে সক্ষম হয় তবে এটি একটি কালো-সাদা চিত্র।
এই সমস্যাগুলি সমাধান করার জন্য, আমি একটি দ্বিতীয় পরীক্ষা চালিয়েছি।
কার্যপ্রণালী
আমি প্রথম পরীক্ষার অনুরূপ পদক্ষেপগুলি অনুসরণ করেছি। আমি নিম্নলিখিত সেটিংস সহ আরজিবি নয়েজ ফিল্টার (ফিল্টার> নাক> আরজিবি নাক ...) ব্যবহার করে একটি র্যান্ডম 256 × 256 আরজিবি চিত্র তৈরি করেছি:
ফলাফল এখানে:
আমি নিম্নলিখিত সেটিংস ব্যবহার করে ফাইলটি জেপিজি হিসাবে রফতানি করেছি:
প্রগতিশীল বন্ধ করা হয়েছে, তবে সাবস্যাম্পলিং এখনও 4: 4: 4 এ সেট করা আছে (এটি 1 × 1 সাবসাম্পলিংয়ের অন্য নাম)। মান 98 এ উন্নীত হয়েছে।
আমি ছবিটি অনুলিপি করেছি এবং অনুলিপিটি ঘড়ির কাঁটার দিকে ঘোরালাম; তারপরে ঘোরানো সংস্করণটি অনুলিপি করে সেই অনুলিপিটি ঘড়ির কাঁটার বিপরীতে ঘোরানো হয়েছে, যাতে আমরা সরাসরি মূল এবং ডাব্লুপিভি প্রসেসড কপির মধ্যে মানের তুলনা করতে পারি।
ফলাফল
-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 কেবি। এটি পরামর্শ দেয় যে ডাব্লুএমভি কম দক্ষ এনকোডিং ব্যবহার করছে।
আমি দুটি চিত্রের তুলনায় ইমেজম্যাগিক ব্যবহার করব :
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
আছে শূন্য পিক্সেল বিভিন্ন মূল এবং আবর্তিত কপি মধ্যে। সুতরাং, ডাব্লুপিভি "সত্য" ক্ষতিহীন রোটেশনটি ব্যবহার না করা সত্ত্বেও, এটি যথেষ্ট ভাল কাজ করছে। আমার সন্দেহ হচ্ছে আমি কী জানি এবং ব্যাখ্যা করার জন্য আমি জেপিইজি সংক্ষেপণের পিছনে গণিতে কিছুটা পরিবর্তন করব।
জেপিইজি সংক্ষেপণ অ্যালগরিদম কোনও চিত্রকে 8 × 8-পিক্সেল ব্লকে বিভক্ত করে। এর মধ্যে প্রতিটি ব্লকের একটি পৃথক কোসিন ট্রান্সফর্ম (ডিসিটি) সাপেক্ষে । ফলত ডিসিটি সহগগুলি ব্লকটিকে বিভিন্ন-ফ্রিকোয়েন্সি তরঙ্গের সমষ্টি হিসাবে বর্ণনা করে। এরপরে অ্যালগরিদম উচ্চ-ফ্রিকোয়েন্সি তরঙ্গগুলির কিছু তথ্য "দূরে নিক্ষেপ করে" যা শব্দ এবং খুব ছোট বিশদটির সাথে মিল করে। ডিকোডিং প্রক্রিয়াটি ডিসিটির বিপরীত হয়, সঞ্চিত তরঙ্গগুলিকে একসাথে ব্লকটি ফিরে পেতে যোগ করে।
ট্রান্সফর্মটি পূর্বাবস্থায় ফিরে না আসা এবং পূর্বাবস্থায় ফিরিয়ে না নিয়েই ডিসিটি "তরঙ্গ" ঘোরানো সম্ভব (মূলত আপনি সমস্ত অনুভূমিক তরঙ্গকে উল্লম্ব তরঙ্গ এবং তদ্বিপরীত দিকে পরিণত করেন)। আমার মনে হয় ডাব্লুপিভিতে যা ঘটেছিল তা হ'ল চিত্রটি আসলে ডিকোডড হয়, আবর্তিত হয় এবং তারপরে পুনরায় এনকোড হয়। পুনরায় এনকোডিং প্রক্রিয়া চলাকালীন, যেহেতু আমাদের চিত্রের আকার উভয় মাত্রায় 8 এর একাধিক, তাই নতুন প্রতিটি ব্লক মূল ব্লকের একটির সাথে মিলে যায়। গুরুত্বপূর্ণভাবে, যেহেতু প্রতিটি ব্লকের কোনও উচ্চ-ফ্রিকোয়েন্সি উপাদান নেই, তাই অ্যালগরিদম কোনও তথ্য ফেলে দেয় না, এবং সঠিক "ডিসিটি" উপাদানটি আবিষ্কার করে যা একটি "সত্য" লসলেস রোটেশনে থাকবে।
শেষ পর্যন্ত, আমি আবার JPEG ফাইলগুলির উপাদানগুলি দেখব look ফলাফলগুলি আবার সংক্ষেপে যুক্ত হয়েছে । দুটি তুলনা:
ডাব্লুপিভি চিত্রটিতে এক্সিফ মেটাডেটারের একটি অতিরিক্ত 4286 + 2 বাইট, মন্তব্যে 1 টি অতিরিক্ত বাইট এবং এক্সএমপি মেটাডেটার 12,726 + 2 বাইট রয়েছে। এটি অতিরিক্ত মেটাডেটার মোট 17,017 বাইট। এই সমস্ত ডেটা কীসের জন্য ব্যবহৃত হয়? আমি আমার বিশ্বস্ত হেক্স সম্পাদক এবং প্রাসঙ্গিক মানগুলির একটি অনুলিপি দিয়ে ফাইলটিতে দেখলাম:
এক্সিফ মেটাডেটা টিআইএফএফ চিত্রের মতো কাঠামোযুক্ত, এতে বেশ কয়েকটি ট্যাগ রয়েছে ( আরও জটিলতার উপায় আছে তবে আমি এটি ছেড়ে চলে যাব)। এক্সিফ সেগমেন্টের বেশিরভাগ বাইট ট্যাগ নম্বর EA1C
(59,932 দশমিক) সহ দুটি অভিন্ন ট্যাগগুলিতে থাকে । এই ট্যাগ নম্বরটি আমি যেখানেই খুঁজে পেয়েছি নথিবদ্ধ নয়। উভয় ট্যাগগুলিতে "অপরিজ্ঞাত" টাইপের 2060 বাইট রয়েছে, যা প্রথম ছয়টি ( 1C EA 00 00 00 08
) বাদে সমস্ত নাল বাইট । এই ট্যাগগুলি কী, কেন সেগুলির মধ্যে দুটি রয়েছে এবং কেন তাদের প্রতিটি কেন 2 কেবি হওয়া দরকার তা আমার কোনও ধারণা নেই।
এক্সএমপি মেটাডেটা আসলে একটি সম্পূর্ণ এমবেডড এক্সএমএল ডকুমেন্ট যা নেমস্পেসিং এবং লম্বা ইউআইডি গুলোতে সবেমাত্র ডাব্লুপিভি সংস্করণ স্ট্রিং রয়েছে (এটি ইতিমধ্যে এক্সিফ মেটাডেটাতে ছিল)। তবে, এটি কেবল প্রায় 400 বাইটের জন্য অ্যাকাউন্টস। বিভাগটির বাকী অংশটি একটি নতুন লাইন অনুসারে 100 স্পেসের 122 পুনরাবৃত্তি রয়েছে । এটি সম্পূর্ণ নষ্ট স্থানের 12,000 বাইটেরও বেশি।
পূর্ববর্তী পরীক্ষার মতো, জিম্প এবং ডাব্লুপিভি উভয় একই ডিসিটি কোয়ান্টাইজেশন টেবিল ব্যবহার করে। এর অর্থ হ'ল তাদের অবশ্যই একই ডিসিটি সহগের হিসাব করা উচিত, এ কারণেই চিত্রগুলি হুবহু একই। আমি নিশ্চিত নই যে ডাব্লুপিভি ঠিক একই পরিমাণের টেবিল ব্যবহার করছে বা যদি ইনপুট থেকে টেবিলগুলি অনুলিপি করে।
পূর্ববর্তী পরীক্ষার মতো নয়, এবার ডাব্লুপিভিতে 1 × 1 সাবসাম্পলিং ব্যবহার করা হয়েছে, সুতরাং এটি প্রকৃতপক্ষে সনাক্ত করতে পারে যে এটি একটি রঙের চিত্র (বা কমপক্ষে উচ্চতর নমুনাগুলি চিত্রবিহীনভাবে পুনরায় এনকোড করার জন্য প্রয়োজনীয়)।
জিআইএমপি এবং ডাব্লুপিভিতে বিভিন্ন হাফম্যান টেবিল ব্যবহার করা হয় (এনট্রপি কোডিং স্টেপের অংশ)। ডাব্লুপিভির টেবিলগুলি মোট 279 বাইট দ্বারা বড় হয় এবং এক ক্ষেত্রে অনেকগুলি কোডের চেয়ে 7 গুণ বেশি থাকে।
জেপিগসনুপের পরিসংখ্যান দেখে আমরা দেখতে পাচ্ছি যে এর মধ্যে কয়েকটি কোড খুব কমই ব্যবহৃত হয়। উদাহরণস্বরূপ, ID: 1, Class: AC
টেবিলে, 119 16-বিট কোডগুলি সংজ্ঞায়িত করা হয়েছে, কেবলমাত্র 23 টি প্রকৃতপক্ষে ব্যবহৃত হয়। সামগ্রিকভাবে, ডাব্লুপিভি সংস্করণে প্রকৃত স্ক্যান বিভাগটি 28.5% বড়।
সারাংশ
ডব্লিউপিভি হয়ত "সত্য" ক্ষতিবিহীন ঘূর্ণন করছেন না, তবে ঘূর্ণনগুলি ব্যবহারিকভাবে ক্ষতিহীন বলে মনে হচ্ছে।
অতিরিক্ত আকার আংশিকভাবে নির্দিষ্ট পরিমাণ যোগ হওয়া মেটাডেটার কারণে এবং আংশিকভাবে কম দক্ষ এনট্রপি কোডিংয়ের কারণে।
সংস্করণ সংক্রান্ত তথ্য:
ওএস (লিনাক্স) ( uname -a
):
Linux unity 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux
ওএস (উইন্ডোজ):
জিআইএমপি (লিনাক্স): ২.৮.১৪ (প্যাকেজ gimp
, সংস্করণ থেকে 2.8.14-1+deb8u1
)
উইন্ডো ফটো ভিউয়ার (চিত্র মেটাডেটা অনুযায়ী):
Microsoft Windows Photo Viewer 10.0.10586.0