কোনও চিত্র যদি ক্ষতিহীনভাবে আবর্তিত হয় তবে ফাইলের আকার পরিবর্তন হবে কেন?


37

আমি ক্ষতিকারক চিত্র ঘোরানোর পদ্ধতিগুলি অনুসন্ধান করছিলাম এবং এই প্রশ্নের উপরে ঘটেছে যা এটি সুন্দরভাবে ব্যাখ্যা করে:

"উইন্ডোজ ফটো ভিউয়ার" রোটেশনগুলি কি ক্ষতিহীন?

তাই আমি এলোমেলো পিক্সেল (ফটোশপ ক্লাউড ফিল্টার) সহ একটি 256 × 256 জেপিইজি তৈরি করেছি এবং তারপরে উইন্ডোজ পিকচার ভিউয়ার ব্যবহার করে এটি ঘোরালাম। ঘোরার পরে, ফাইলের আকারটি আসলে বৃদ্ধি পেয়েছিল, তবে কেবল প্রথম রোটেশনে। তারপরে প্রতিটি পরবর্তী ঘূর্ণায়মান, ফাইলের আকার স্থির থাকে। আমি জানি এটি দোষহীনভাবে আবর্তিত হচ্ছে কারণ আমি এটিকে কোনও লক্ষণীয় মানের ক্ষতি ছাড়াই একাধিকবার ঘোরালাম যেখানে একটি 257 × 257 চিত্রটি 20 বার আবর্তিত হওয়ার সময় খুব ক্ষতিকর হয়ে পড়ে।


8
আপনার পরীক্ষাগুলিতে ফাইলের আকার কত বাড়ল?
জেমস স্টেল

3
@ জেমস্নেল আমি জানতাম আমার এটি অন্তর্ভুক্ত করা উচিত ছিল। আমি সবেমাত্র জিম্পের ডিফারেন্স ক্লাউন্ডস ফিল্টারটি ব্যবহার করেছিলাম সেটি মূলত 14,583 বাইট, তবে রোশন পরে 23,638 বাইটে পরিবর্তিত হয়েছিল। এটি 9000 বাইটেরও বেশি পার্থক্য যা যদি আমরা একা মেটাডেটা সম্পর্কে কথা বলি তবে অনেক অতিরিক্ত ডেটা মনে হয়।
oscilatingcretin

4
এটি অনেকগুলি অতিরিক্ত মেটাডেটার মতো মনে হচ্ছে। আমি অতিরিক্ত অতিরিক্ত ডেটা মেটাডেটা হিসাবে ধরে নেওয়া খুব দ্রুত করব না। আমার কাছে মনে হয় যে মেটাডাটার কারণে আকারের পার্থক্যটি প্রায় ধ্রুবক হওয়া উচিত (কিছু সংখ্যার স্ট্রিং উপস্থাপনার জন্য কয়েকটি বাইটের মধ্যে)।
স্কটবিবি

4
প্রশ্নের অতিরিক্ত জার্মানিযুক্ত অতিরিক্ত তথ্য সরবরাহ করার সময়, মন্তব্যে না করে প্রশ্নটিতে সম্পাদনা করুন। মন্তব্যগুলি ক্ষণস্থায়ী এবং সময়ে সময়ে পরিষ্কার হতে পারে।
স্কটবিবি

2
আপনার পরীক্ষার চিত্রটির মূল সংস্করণ আপলোড করা সহায়ক হবে।
কোডসইনচাউস

উত্তর:


36

এটি সম্ভবত এনট্রপি কোডিংয়ের কারণে ঘটেছিল , যা জেপিইজি সংক্ষেপণের চূড়ান্ত ক্ষতিহীন পর্যায়, চিত্রের আকারটি হ্রাস করতে কোয়ান্টাইজ করার পরে।

যখন কোনও জেপিইজি চিত্রটি ক্ষতিহীনভাবে আবর্তিত হয়, এই চূড়ান্ত লসলেস এনকোডিং স্তরটি অবশ্যই পূর্বাবস্থায় ফেরাতে হবে, আনপ্যাক করা ডিসিটি সহগের চারপাশে বদলানো হবে এবং তারপরে বদলানো সহগগুলি আবার এনট্রপি কোডিং করা দরকার। যেহেতু এনট্রপি কোডিং স্তরটির দক্ষতা প্রতিটি ব্লকের মধ্যে থাকা ডিসিটি সহগের ক্রমের উপর নির্ভর করে, যা চিত্রটি ঘোরানো হবে তা পরিবর্তিত হবে, তাই আশ্চর্য হওয়া উচিত নয় যে আবর্তিত চিত্রের ফাইলটি মূলের তুলনায় কয়েক শতাংশ ছোট বা বড় হতে পারে।

এনট্রপি কোডিং পদক্ষেপটি বেশ কয়েকটি বিভিন্ন উপায়ে করা যেতে পারে, সুতরাং এনকোডিং করে এমন সফ্টওয়্যারটির উপর নির্ভর করে সঠিক একই জেপিইজি চিত্রের ফাইলের আকার পৃথক হতে পারে এটি বেশ সম্ভব। এনকোডারগুলির মধ্যে কিছু সম্ভাব্য পার্থক্যগুলির মধ্যে রয়েছে:

  • পাটিগণিত এনকোডিংয়ের পছন্দ (বিরল তবে সম্ভাব্য আরও দক্ষ, পেটেন্ট ব্যবহার করা) বনাম হাফম্যান এনকোডিং (সরল, মানক);
  • ক্রমক্রমিক পছন্দ (প্রতিটি 8x8 পিক্সেল ব্লক একবারে একটি করে এনকোড করা হয়) বনাম প্রগতিশীল (সমস্ত ব্লকের কম ফ্রিকোয়েন্সি উপাদানগুলি উচ্চতর ফ্রিকোয়েন্সি উপাদানগুলির আগে সাধারণত সামান্য আরও কমপ্যাক্ট থাকে) এনকোডিং ক্রম;
  • স্ট্যান্ডার্ড হাফম্যান প্রতীক টেবিলগুলি ব্যবহার করার পছন্দ (দ্রুত, সহজ, খুব ছোট চিত্রগুলির জন্য আরও কার্যকর হতে পারে) বনাম প্রতিটি কাস্টমের জন্য অনুকূলিত কাস্টম টেবিলগুলি (সাধারণত বড় চিত্রগুলির জন্য আরও দক্ষ, ধীর এবং এনকোডে আরও জটিল);
  • যদি কাস্টম হাফম্যান টেবিলগুলি ব্যবহার করা হয়, বিভিন্ন এনকোডারগুলি একই চিত্রের ডেটার জন্য সম্ভাব্যভাবে বিভিন্ন টেবিল তৈরি করতে পারে;
  • এনকোডিং প্রক্রিয়া নিজেই বিভিন্ন নিম্ন-স্তরের বিশদ বিবরণ যেমন ডেটা প্রবাহে পুনরায় আরম্ভকারী চিহ্নিতকারীদের অন্তর্ভুক্ত করা উচিত কিনা এবং এনকোডারগুলির মধ্যেও পৃথক হতে পারে।

এছাড়াও, "জেপিইজি ফাইলগুলি" লোকেরা সাধারণত জেপিএফ-সংক্ষিপ্ত চিত্রযুক্ত ডেটা জেএফআইএফ বা একটি এক্সিফ ধারক দ্বারা আবৃত থাকে , যা এক বা একাধিক মেটাডেটা ব্লকের সাথে চিত্রের ডেটা একত্রিত করে এবং নিজস্ব জটিলতার সেট সেট করে। এমনকি চিত্রটি ঘোরানো সফ্টওয়্যারটি যদি জেএফআইএফ / এক্সিফ মেটাডেটাতে আসলে কোনও তাত্পর্যপূর্ণ পরিবর্তন না করে, কেবলমাত্র ডেটাটিকে পুনরায় সাজানো কিছুটা বাইটের সাহায্যে ফাইলের আকারকে প্রভাবিত করতে পারে।

বিশেষত, জেএফআইএফ / এক্সিফ মেটাডেটাতে পূর্ণ আকারের চিত্রের এক বা একাধিক থাম্বনেইল থাকতে পারে এবং সফ্টওয়্যার যা চিত্রগুলি ঘোরান সত্যই থাম্বনেইলগুলি পুনরায় জেনারেট করা উচিত (বা এলোমেলোভাবে ঘোরানোও হবে !) যাতে তারা সম্পূর্ণ- আকার চিত্র। এটি একা সহজেই পর্যবেক্ষণ করা আকারের পার্থক্যের জন্য অ্যাকাউন্ট করতে পারে।


4
9 কেবি (60%) পার্থক্যের জন্য, আমার অনুমান থাম্বনেইল হবে।
ব্লুরাজা - ড্যানি পিফ্লুঘুফ্ট

জেপিজি এটির জন্য এনকোডারগুলি মূল্যবান হওয়া খুব সহজ হতে পারে তবে এক্স 2642 এর মতো ভিডিও এনকোডাররা রেট বনাম বিকৃতি ট্রেড অফের সিদ্ধান্ত নেওয়ার সময় তারা কী ফলাফল করতে পারে তা এনকোড করার জন্য এন্ট্রি কোডারটির কার্যকারিতাটি বিবেচনা করতে পারে। (অর্থাত্ প্রতিটি বিকল্পের জন্য কত বিট খরচ হতে পারে তা স্থির করে এবং ক্ষতিকারক ত্রুটির বিপরীতে এটি ওজন নিতে হবে)। একে ট্রেলিস কোয়ান্টাইজেশন বলা হয়। X264 এর লেখক (লরেন মেরিট) এর কাছ থেকে H.264 এ ট্রেলিস কোয়ান্টাইজেশন প্রয়োগের নোটগুলি দেখুন ; তিনি উদ্দেশ্যটির একটি সুন্দর প্রাথমিক ব্যাখ্যা দিয়ে শুরু করেন।
পিটার কর্ডেস

যাইহোক, পয়েন্ট সত্ত্বেও, জেপিজি এনকোডারটি ডিটিটি সহগগুলি বেছে নিতে পারে যেমন তারা এনট্রপি কোডার দিয়ে ভালভাবে সংকুচিত হয়েছিল, তাই কোনও সর্বোত্তম সংকোচকারীও ঘোরানো সংস্করণটিকে ছোট হিসাবে তৈরি করতে পারেনি। (কারণ এগুলি আলাদা অর্ডারে রাখলে তারা সম্ভবত কম সংকোচনের কারণ হয়ে উঠবে)) এটি অবশ্যই জেপিজির পক্ষে খুব কম প্রভাব ফেলবে, যেহেতু প্রতিটি 8x8 ব্লক পৃথকভাবে কোডেড থাকে (এনট্রপী কোডারের স্থিতি পুনরায় সেট করা, এএফআইএকি)। (এইচ .264-এর আই-ফ্রেমগুলি একই ফ্রেমের অন্যান্য ব্লক থেকে ভবিষ্যদ্বাণী করে, আন্ত-পূর্বাভাস ব্যবহার করে, একই ভিজ্যুয়াল মানের এগুলিকে জেপিইগের চেয়ে ছোট করে তোলে))
পিটার কর্ডেস

24

আমি এগিয়ে গেলাম এবং পরীক্ষার পুনরাবৃত্তি করেছিলাম যা দেখতে পাচ্ছি যে আমি কী ঘটছে তা বুঝতে পারি।

কার্যপ্রণালী

আমি জিম্পে "সলিড নয়েজ" ফিল্টার ব্যবহার করে এলোমেলো 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
    

20

সম্পাদনা : এই উত্তরটি পোস্ট করার আগেই আমি জানতাম যে ফাইলগুলি আকারে প্রায় 9 কিবি বৃদ্ধি পেয়েছে (256 × 256 চিত্রের জন্য 9055 বাইট, 512 × 512 চিত্রের জন্য 9612 কিবি)।

সমস্ত সম্ভাবনায়, আপনি যখন চিত্রটি প্রথম ঘোরালেন, উইন্ডোজ পিকচার ভিউয়ার নিম্নলিখিতগুলির মধ্যে একটি (বা উভয়) করেছিলেন:

  1. আসল জেপিইজি চিত্রে নেই এমন একটি এক্সআইএফ ট্যাগ যুক্ত করা হয়েছে (সম্ভবত ওরিয়েন্টেশন ট্যাগ);
  2. ইতিমধ্যে বিদ্যমান একটি ট্যাগে সম্ভবত পরিবর্তিত / যুক্ত তথ্য (সম্ভবত প্রসেসিং সফ্টওয়্যার বা চিত্র সফ্টওয়্যার ট্যাগগুলি)।

অতিরিক্ত এক্সআইএফ ট্যাগ (এবং / অথবা বিদ্যমান ট্যাগগুলিতে অতিরিক্ত ডেটা) থাকায় এটি ফাইলের আকার বাড়িয়েছে।

পরবর্তী ঘূর্ণনগুলি ফাইলের আকার বাড়েনি কারণ ডাব্লুপিভি যে সমস্ত ট্যাগ এবং / অথবা ট্যাগ ডেটা যুক্ত করেছিল / সংশোধিত করেছে সেগুলি ইতিমধ্যে ছিল। কেবল ওরিয়েন্টেশন ট্যাগ মান পরিবর্তিত হয়েছে (এবং সম্ভবত তারিখ / সময় ট্যাগ মানও)।


সম্পাদনা : এটি প্রায় নিশ্চিত যে এই ব্যাখ্যাটি ফাইলটিতে প্রায় 9 কিবি অতিরিক্ত ডেটা সরবরাহ করতে পারে না। তদুপরি, আকার বৃদ্ধির জন্য অন্য কোনও কারণে অনুপস্থিত, এই ব্যাখ্যাটি আশা করবে যে আকারের বৃদ্ধি কম-বেশি ধ্রুবক হবে (সংখ্যার ডেটার স্ট্রিং উপস্থাপনার মধ্যে কিছু দৈর্ঘ্যের পার্থক্য, সম্ভবত কয়েকটি বাইট) mod এটি এখানে যা ঘটছে তা স্পষ্টতই নয়, অন্তত সম্পূর্ণ ব্যাখ্যা নয়।


1
এবং একটি এক্সআইএফ ট্যাগটি 9 কেবি নিতে চলেছে? ভাল, এটি অন্তত পরীক্ষা করা সহজ - ওপিতে ঘোরানো চিত্র থেকে EXIF ​​বা অন্যান্য ট্যাগ মুছুন এবং দেখুন ফাইলের আকার কীভাবে পরিবর্তন হয়।
কার্ল উইটহফট

2
@ কার্লউইথথফট 9 কেবি নতুন তথ্য। উল্লেখ করার জন্য সম্পাদনা করছি।
স্কটবিবি

3

বিপরীত প্রকৌশল ছাড়া জেপিগ এন / ডিকোডারটি নিশ্চিতভাবে বলা অসম্ভব। প্রকৃতপক্ষে বেশ কয়েকটি জেপিগ মানক রয়েছে এবং জনপ্রিয় বিশ্বাসের বিপরীতে, এগুলি সমস্তই পুনরায় এনকোডিং ছাড়া সংশোধন করা যায় না।

এটি সম্ভবত সম্ভব যে প্রথম সঞ্চয়টি হ'ল তার পছন্দসই জেপিগ স্বাদে পুনর্লিখন এবং পরবর্তী ঘূর্ণনগুলি একটি সাধারণ মেটাডেটা টুইঙ্ক বা সরাসরি ডিসিটি টেবিলে একটি ক্রিয়াকলাপ (যা কিছু এনকোডিং স্কিমের জন্য সম্ভব)।

ফাইলাইজ বৃদ্ধিতে কিছু অতিরিক্ত মেটাডেটাও অন্তর্ভুক্ত থাকতে পারে, যদিও 9 কে অনেকটা মনে হলেও এটি সম্ভব। এই বৃদ্ধির জন্য একটি থাম্বনেইল যোগ করা যেতে পারে যা জিম্প থেকে আউটপুটে উপস্থিত নাও হতে পারে। আমরা সরাসরি ফাইলগুলি থেকে ডাব্লুপিভি এর আগে এবং পরে আরও তথ্য পেতে সক্ষম হতে পারি।

যাইহোক, জেপিগের সাথে নিরবচ্ছিন্নভাবে কাজ করার চেষ্টা করা আসলেই একটি বোকামির কাজ, কারণ এটি কেবল নির্দিষ্ট চিত্রের মাপের সাথেই কার্যকর, সমস্ত ডিকোডার এবং এনকোডার একই নয় এবং এজন্য সেই সম্পাদকদের জেপিগ সামগ্রী সাথে সরাসরি কাজ করা দরকার যা আপনি নির্ভর করতে পারবেন না কেস ... কেবল এখন এটি করার অর্থ এই নয় যে এটি ভবিষ্যতে অব্যাহত থাকবে।

আপনার আরও ভাল বাজি হতাশ বিন্যাসের সাথে কাজ করা এবং ব্যথা সম্পূর্ণরূপে এড়ানো।


2
আমি মোটেও নিশ্চিত নই যে জেপিগ ডেটা ঘোরানোর কারণে প্রথম স্থানে পুনরায় এনকোডিং হওয়া উচিত।
কার্ল উইটহফট

আপনি প্রোগ্রামার কিনা বা না তা নির্ভর করে ... আমার অনুমান যে আপনি নন। সেই ন্যূনতম পরিবর্তনটি করতে আপনাকে বিশেষভাবে সেই অপ্টিমাইজেশনটির সন্ধান করতে হবে অন্যথায় সঙ্কুচিত বিটম্যাপ থেকে একটি সেভ অপারেশন শুরু হবে।
জেমস স্নেল

3
লিঙ্কযুক্ত প্রশ্ন থেকে, এটি পরিষ্কার যে উইন্ডোজ ফটো ভিউয়ার জেপিজিগুলি নিরবিচ্ছিন্নভাবে ঘোরান।
ভিসিএলও

2
@ জেমস আমি নিম্ন স্তরের প্রোগ্রামার নই, আমি টিভিতে খেলি :-)। ওপিতে কখন পুনরায় এনকোডিং হবে এবং কখন থাকবে না তার সঠিক বিবরণের একটি লিঙ্ক সরবরাহ করেছিল। আমি সেই আলোচনা থেকে অনুমান করেছি যে তিনি কেবল $ rac frac {\ pi} {2} by দ্বারা ঘুরছিলেন $ আমি সম্মত হই যে স্বেচ্ছাচারী কোণ ঘোরার ফলে পুনরায় এনকোডিং হয় এবং এ ক্ষেত্রে এক্স-বাই-ওয়াই চিত্র কমপক্ষে হাইপোপেনজ হিসাবে বৃহত্তর অঞ্চলে এম্বেড করা না হলে তথ্য ক্ষতির কারণ হতে পারে।
কার্ল উইথহফট

1
আমরা নিশ্চিত যে আমরা জানি যে ডাব্লুপিভি 8/16 এর মাত্রার গুণক সহ চিত্রগুলির জন্য বিপরীতে ঘুরছে rot ওপিতে লিঙ্কিত প্রশ্নের ম্যাট গ্রামের উত্তর সম্পর্কে @ ট্রিস্টানের মন্তব্য দেখুন। ত্রিস্তান মাইক্রোসফ্টে ডব্লিউপিভি দলে কাজ করেছিল এবং মূলত তা নিশ্চিত করে।
স্কটবিবি

1

লসলেস জেপিইগির আবর্তন কেবলমাত্র সীমানা শিল্পকলাগুলির পরিচয় না দিয়েই সম্ভব যদি চিত্রের মাত্রা ব্লকের আকারের গুণক (সাধারণত [/ সর্বদা?] 8) হয়। কী জড়িত রয়েছে তার বিশদ জানতে jpegtran ম্যান পেজটি দেখুন (দুঃখিত, এর জন্য আমার কাছে ভাল কোনও লিঙ্কযুক্ত লিঙ্ক নেই; আপনি যদি এটির সন্ধান করেন তবে নির্দ্বিধায় যোগাযোগ করুন):

স্থানান্তর রূপান্তরের চিত্রের
মাত্রা সম্পর্কিত কোনও বিধিনিষেধ নেই । অন্যান্য রূপান্তরগুলি অদ্ভুতভাবে পরিচালনা করে যদি চিত্রের মাত্রাগুলি আইএমসিইউ আকারের একাধিক না হয় (ব্যবহারযোগ্য 8 বা 16 পিক্সেল), কারণ তারা কেবলমাত্র কাঙ্ক্ষিত উপায়ে ডিসিটি সহগের ডেটাগুলির সম্পূর্ণ ব্লককে রূপান্তর করতে পারে।

বিজোড়-আকারের চিত্রের রূপান্তর করার সময় জেপিগ্রাটনের ডিফল্ট আচরণটি রূপান্তরকরণের সেটটির সঠিক বিপরীতত্ব
এবং গাণিতিক
ধারাবাহিকতা রক্ষার জন্য ডিজাইন করা হয়েছে । যেমনটি বলা হয়েছে, ট্রান্সপোজ
পুরো চিত্রের অঞ্চলটি ফ্লিপ করতে সক্ষম। অনুভূমিক মিররিংয়ের ফলে ডান প্রান্তে আংশিক আইএমসিইউ কলামটি ছোঁয়াচে পড়েছে, তবে চিত্রের সমস্ত সারি উল্টাতে সক্ষম। একইভাবে, উল্লম্ব মিররিং নীচের প্রান্তে যে কোনও আংশিক আইএমসিইউ সারিটি ছোঁয়া ছেড়েছে, তবে সমস্ত কলামগুলি ফ্লিপ করতে সক্ষম। অন্যান্য রূপান্তরগুলি ট্রান্সপোজ এবং ফ্লিপ ক্রমের ক্রম হিসাবে নির্মিত যেতে পারে; ধারাবাহিকতার জন্য, প্রান্ত পিক্সেলগুলিতে তাদের ক্রিয়াকলাপগুলি সম্পর্কিত ট্রান্সপোজ-এবং-ফ্লিপ ক্রমের শেষ ফলাফল হিসাবে একই হিসাবে সংজ্ঞায়িত করা হয়।

ব্যবহারিক ব্যবহারের জন্য, আপনি কোনও রূপান্তরিত চিত্রের ডান এবং / বা নীচের প্রান্ত
বরাবর একটি অদ্ভুত- দর্শনীয় স্ট্রিপ না রেখে যে কোনও অপ্রত্যাশিত প্রান্ত পিক্সেলকে অগ্রাহ্য করতে পছন্দ করতে পারেন
। এটি করতে, -ট্রিম সুইচ যুক্ত করুন:

আমি সন্দেহ করি যে উইন্ডোজ ফটো ভিউয়ারটি ক্ষতির বিহীন আচরণের অনুকরণের জন্য ডিকম্প্রেশন এবং চূড়ান্ত-উচ্চমানের পুনঃসংযোগ সম্পাদন করে এই সমস্যাটি এড়িয়ে চলেছে যখন চিত্রের মাত্রা 8 টির চেয়ে বেশি হয় না, আসলে লসলেস রোটেশন সম্পাদন করার চেয়ে। একটি ভাল ইউটিলিটি পুরো চিত্রের গুণমান নষ্ট না করে (এবং ফাইলের আকার বাড়িয়ে তুলতে) কেবল প্রকৃত ক্ষতিহীন, শৈলী এবং সমস্তগুলি করতে পারে বা কয়েকটি পিক্সেল ফেলে দেয়।


1
256x256 চিত্রের জন্য অপ্রাসঙ্গিক।
ths

আমি ভুলভাবে পড়েছি এবং ভেবেছিলাম সমস্যাটি 257x257 সংস্করণের জন্য।
আর ..

0

আমার কাছে এর কোনও নির্দিষ্ট উত্তর নেই তবে কেন এমনটি হয়েছিল তার কয়েকটি সম্ভাব্য তত্ত্ব রয়েছে। কিছু ফাইল টাইপ এমনভাবে কাজ করে যে ফাইল টাইপের একটি চিত্রের জন্য দুটি পৃথক কোড অগত্যা পৃথক চিত্র তৈরি করে না। উদাহরণস্বরূপ, পিএনজি ফাইল টাইপটি সেভাবে কাজ করে কারণ এটি স্বচ্ছ পটভূমির জন্য অনুমতি দেয় তবে একটি স্বচ্ছ পটভূমি সহ একটি চিত্র এবং একই ব্যাকগ্রাউন্ডটি সাদা বাদে ঠিক একইভাবে প্রদর্শিত হয়। কোনও চিত্র ফাইলটি যদি পিক্সেলটিতে মেমরির 3 বাইটের চেয়ে কম নেয় তবে সংক্ষেপিত বলে জানানো হয়। আমি বিশ্বাস করি যে স্বচ্ছ ব্যাকগ্রাউন্ডযুক্ত ফাইলগুলি বাদ দিয়ে কোনও দুটি পিএনজি ফাইল হুবহু একই চিত্র তৈরি করে না। যখনই আপনি কোনও চিত্রকে পিএনজি হিসাবে সংরক্ষণ করেন, এটি এটিকে এমন একটি কোডে রূপান্তর করে যা মূল চিত্রটি উত্পন্ন করে এবং খুব অসাধারণ চিত্র বাদে যেখানে প্রতিটি পিক্সেল সমস্ত 2 ^ 24 রঙের এলোমেলো রঙ, কোডটি পিক্সেল প্রতি 3 বাইটের চেয়ে কম মেমরি গ্রহণ করবে তাই বলা হয় যে পিএনজি হ্রাসহীন সংকোচনের বলে সংরক্ষণ করা হচ্ছে। অন্যদিকে, মেমরিটি সংরক্ষণ করতে, কেবলমাত্র জেপিইজি চিত্র ফাইলের কোড দ্বারা নির্দিষ্ট কিছু চিত্র তৈরি করা যেতে পারে। এখানে একাধিক জেপিইজি ফাইল টাইপ রয়েছে এবং আমি জানি না যে তাদের মধ্যে এমন কোনও সম্পত্তি আছে যা সেই ফাইল টাইপের দুটি পৃথক চিত্র ঠিক একই চিত্র তৈরি করতে পারে। আমি ধরে নিচ্ছি যে আপনি বেশ কয়েকবার একটি চিত্র ঘোরালেন তারপরে এটিকে জেপিজি হিসাবে সংরক্ষণ করেছেন এবং এই ধারণাটি অনুসারে কী ঘটেছিল তার ব্যাখ্যা দেবেন যে আপনি যা করেছেন তা আমি সত্য জানি কিনা তাও জানি না। আপনি যে ঘূর্ণনটি করেছিলেন তা দোষহীন যদি আপনার নিজের মতো করে একই চিত্র ফাইল কোডটি ফিরে আসার উপায় থাকে যা আপনি এটি ঘোরানোর আগে এবং সংরক্ষণ করার আগে করেছিলেন। আপনি সম্ভবত এটি সঠিক না হতে পারেন যে আপনি সত্যই একটি দোষহীন রোটেশন করেছিলেন। যদি এটি সত্যিই ক্ষতিহীন হত,


-3

এর পিছনে কারণগুলি কয়েকটি

চিত্রগুলি কোডড এবং সংকুচিত করার পদ্ধতিটি কেবল সংকোচিত অ্যালগরিদমের কারণে আকার পরিবর্তন করবে। আপনি এটিকে বিটম্যাপ হিসাবে সংরক্ষণ করে এবং পরে এটিকে ঘোরানোর মাধ্যমে এটি পরীক্ষা করতে পারেন। এই ফর্ম্যাট বা কোনও কাঁচা বিন্যাসে আকার একই থাকবে। যদি তা না হয় তবে চিত্রটি সংরক্ষণ করার প্রোগ্রামটি সম্ভবত কিছু মেটাডেটা বা অন্য কিছু যুক্ত করছে।

তবে আপনি কেন 20 বার একটি জেপিগি ঘোরান?


2
আপনি আসল প্রশ্নে লিঙ্ক, পড়ুন উইন্ডোজ চিত্র ভিউয়ার জন্য অন্তত , যদি কোন JPEG এর মাত্রা, JPEGs ঘুর্ণন 8 এর গুণিতক হয় তারপর WPV মধ্যে অবচয়হীন রূপান্তরের হয়। পরীক্ষার একটি সহজ উপায় হ'ল 4 বার আবর্তন করা (মূলরূপের সাথে একই দিকনির্দেশের ফলে) এবং একটি সাধারণ পিক্সেল বাই পিক্সেল চিত্র বিয়োগফল সম্পাদন করা।
স্কটবিবি

@ স্কটবিবি এটি উইন্ডোজ চিত্র দর্শকের ক্ষেত্রে কেবল সমস্যা নয়। ক্ষতিকারক বিন্যাসকে ঘোরানো যেকোন কিছুতেই সংকোচনের পুনরায় গণনা করতে হবে। 8 টির বহুগুণে একটি চিত্র ঘোরানো মানে সবকিছু 8 বিট শব্দের সাথে খাপ খায় এবং নিদর্শনগুলিকে যুক্ত করে এমনভাবে সংকুচিত নাও হতে পারে। এটি কীভাবে অ্যালগরিদম কাজ করে এবং ব্যবহৃত প্রোগ্রামে প্রয়োগ করা হয় তার উপর ভিত্তি করে।
সিসি Dd

-3

কারণ ইমেজ কাজ কিভাবে কম্প্রেশন । সাধারণভাবে পিএনজি বা জেপিজির মতো কোনও ফর্ম্যাট রোটেশনের পরে ফাইলের আকার সংরক্ষণ করে না।

সংক্ষিপ্তকারীর কাছে ঘোরানো চিত্রটি কেবল একটি আলাদা চিত্র, কীভাবে কমপ্রেসিরি হিউরিস্টিক কাজ করে তার কোনও ঘোরানো চিত্র একই সংকোচনের কোনও গ্যারান্টি নেই বলে

অবশ্যই যদি সংক্ষেপণটি ক্ষয়ক্ষতিহীন হয়, আপনি যদি চতুর্থবারের মতো চিত্রটি 4 বার আবর্তিত করেন তবে চিত্রটি আবার একইরকম হয় (এটি মূল হিসাবে কাত হওয়া পর্যন্ত ঘোরানো হয়): সেক্ষেত্রে এটি আবার একই সংকুচিত আকারের হওয়া উচিত, যদি না হয় তবে এটি নিম্নলিখিত কারণগুলির মধ্যে একটি কারণ :

  • যোগ করা মেটাডেটা : প্রোগ্রামটি কোনও কারণে কিছু অংশ পাঠ্য যোগ করেছে
  • সংক্ষেপক পরিবর্তিত হয়েছে: কোনও পরিবর্তন না হলে প্রোগ্রামটি চিত্রটিকে মূল হিসাবে পুনরায় সংরক্ষণ করতে বেছে নিতে পারে, তবে আপনি যদি কোনও পরিবর্তন প্রয়োগ করেন (90 ডিগ্রির 4 টি ঘূর্ণন) তবে এটি নিজের ব্যবহার করে আবার চিত্রটি সঙ্কুচিত করার সিদ্ধান্ত নিতে পারে সংক্ষেপক (প্রোগ্রামটি আর জানে না এটি এখনও একই চিত্র)।
  • সাধারণভাবে একই সংক্ষেপক (libPNG বা libJPG) বিভিন্ন বাস্তবায়ন, একই লাইব্রেরির বিভিন্ন সংস্করণে এবং বিভিন্ন সংকোচনের প্যারামিটারগুলির সাথেও (অপারেটিভ সিস্টেম এবং সংকলক এখানে মাঝে মাঝে একটি পার্থক্য করে) খুব আলাদা ফলাফল দেয়।

চিত্র সংক্ষেপণ 4x4 বা অন্যান্য আকারের অংশগুলিতে চিত্রগুলি সংকুচিত করে কাজ করে। সাধারণভাবে একটি সংক্ষেপক একটি ঘোরানো চিত্রটিকে অন্য চিত্র হিসাবে দেখেন, তবে যেহেতু একটি সংকীর্ণ পিক্সেল খণ্ডটি কেবল একটি রৈখিক পচা হয়, যদি চিত্রটির খণ্ডগুলি একই থাকে তবে কেবল একইভাবে কার্যকর রেখে একই রৈখিক ক্ষয় ম্যাট্রিকগুলি স্থানান্তর / মিরর করা সম্ভব গুণমান:

নোট করুন এটি প্রতি বৈশিষ্ট্যের ভিত্তিতে প্রয়োগ করা উচিত এবং এটি আকারের প্রাথমিক বৃদ্ধিটিও ব্যাখ্যা করে>> প্রথম ঘোরার সময় এটি কেবল চিত্রটিকে ঘূর্ণনযোগ্য এমন খণ্ডে সংকোচিত করার চেষ্টা করে:

  • যদি এটি করতে ব্যর্থ হয়: চিত্রের মান হ্রাস পায়
  • যদি এটি সফল হয় তবে এটি একবারে আকার বাড়ায় তবে প্রতিটি ঘূর্ণন একই মানের হয় keeps

  • চিত্রটি সমান অংশ দ্বারা তৈরি করা হয় তবেই এই অপারেশনটি সাফল্যময়। (চিত্রের আকার হ'ল আকারের একাধিক)

স্কটবিবি উত্তরগুলি ভুল করে এবং আপনি একটি সহজ পরীক্ষা করতে পারেন:

  • মূল চিত্রটি খুলুন: এটির স্ক্রিনশট
  • চিত্রটি ডাব্লুপিভি দিয়ে 4 বার ঘোরান: স্ক্রিনশট এটি
  • 2 স্ক্রিনশট তুলনা করুন

আপনি চিত্রটি পরিবর্তিত দেখতে পাবেন (এটি প্রথম রোটেশনে সংক্ষেপিত হয়)। তবে যে পরিবর্তনটি সময়ের মধ্যে সীমাবদ্ধ, আপনি এখন মান ক্ষতি ছাড়াই এটি আবার ঘোরতে পারেন (যদি চিত্রটির আকার এমন হয় যা 8 এর একাধিক)

ওপিকে সরাসরি উত্তর দিতে:

আমি জানি এটি নিখরচায় আবর্তিত হচ্ছে

এটি দোষহীন ঘোরানো নয়, এটি কমপক্ষে একবারে গুণমান হারাবে (প্রথম রোটেশনে: কারণ এটি প্রথমে এটি এমনভাবে সংকুচিত করা উচিত যা ঘোরানো যায়), তারপরে এটি তার গুণমান বজায় রাখে।


1
প্রশ্নটি হ্রাসহীন ঘূর্ণায়মান সম্পর্কে, সুতরাং পুনরায় সংযোজন এড়ানো যায়।
এজেন্ট_এল

5
ওপি সাধারণ কেস সম্পর্কে নয়, ঠিক সেই নির্দিষ্ট সফ্টওয়্যারটির এক অংশ এবং এটি করে এমন একটি নির্দিষ্ট ক্ষেত্রে সম্পর্কে জিজ্ঞাসা করেছিল। আপনার উত্তরটি ভুল নয়, এটি ওপি যা চেয়েছিল তার চেয়ে আলাদা একটি প্রশ্নের উত্তর দেয়।
এজেন্ট_এল

1
প্রথম 3 টি বাক্য এখনও একটি পৃথক প্রশ্নের কাছে রয়েছে: "চিত্রগুলির সংক্ষেপণ কীভাবে কাজ করে" - লসলেস রোটেশনে কোনও সংক্ষেপণ নেই। "ঘূর্ণিত চিত্রটি সংকোচকারীকে" - আবারও, সংক্ষেপককে অনুরোধ করা হয়নি। "যদি সংকোচনের ক্ষতিহীন হয়" - সংক্ষেপণ ক্ষয়ক্ষতিযুক্ত। ঘূর্ণন হ্রাসহীন। এখন, আমি এই যুক্তিটি গ্রহণ করতে কতদূর রাজি আছি। আমি আপনার বক্তব্যটি দেখতে পাচ্ছি, আমি এটির সাথে একমত, তবে এটি এখানে পুরোপুরি বাইরে। বিটিডাব্লু, আমিও একজন প্রোগ্রামার এবং আমি কাঁচা ফাইল পড়া এবং লেখার অংশটি করেছি।
এজেন্ট_এল

1
আমি পেইন্টে একটি চিত্র তৈরি করেছি, এটি 4 বার আবর্তিত করেছি এবং এটি অভিন্ন, তবে তারপরেও আকারটি 1.6 থেকে 8.1 কেবিতে লাফিয়ে গেছে। বাইনারি ডিফ দেখায় যে চিত্রের ডেটাটি অচ্ছুত ছিল, এটি <?xpacketট্যাগগুলিতে মেটাডেটার বিশাল পরিমাণ ।
এজেন্ট_এল

1
যদি কোনও জেপিজিটির মাত্রা 8 (বা 16 টি সাবপামলিং সহ) দ্বারা সমানভাবে বিভাজ্য হয়, তবে এটি 90 ডিগ্রি হারে ক্ষতিহীনভাবে আবর্তিত হতে পারে । কী হয় না এটা আরজিবি সব পথ ডিকোড কিন্তু DCT কোফিসিয়েন্টস সঙ্গে সরাসরি কাজ। এটি একটি বিশেষিত ফাংশন যা প্রায়শই কোনও সাধারণ চিত্র সম্পাদকের অন্তর্ভুক্ত থাকে না। উদাহরণস্বরূপ দেখুন en.wikedia.org/wiki/Libjpeg#jpegtran । যদি আপনি প্রশ্নটিতে উল্লিখিত উইন্ডোজ ফটো ভিউয়ারের সাথে আপনার পরীক্ষাটি সম্পাদন করেন তবে আপনি দেখতে পাবেন যে এটি সত্যই ক্ষতিহীন।
মার্ক
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.