প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

WebP কী? কেন আমি এটি ব্যবহার করব?

WebP হল ক্ষতিকারক এবং ক্ষতিহীন সংকোচনের একটি পদ্ধতি যা ওয়েবে পাওয়া বিভিন্ন ধরণের ফটোগ্রাফিক, ট্রান্সলুসেন্ট এবং গ্রাফিক্যাল ছবিতে ব্যবহার করা যেতে পারে। ক্ষতিকারক সংকোচনের মাত্রা সামঞ্জস্যযোগ্য, তাই ব্যবহারকারী ফাইলের আকার এবং ছবির মানের মধ্যে বিনিময় বেছে নিতে পারেন। WebP সাধারণত JPEG এবং JPEG 2000 এর তুলনায় গড়ে 30% বেশি সংকোচন অর্জন করে, ছবির মানের ক্ষতি ছাড়াই ( WebP Lossy Study এবং WebP Lossless and Alpha Study দেখুন)।

WebP ফর্ম্যাটের লক্ষ্য মূলত ছোট, আরও সুন্দর দেখতে ছবি তৈরি করা যা ওয়েবকে দ্রুততর করতে সাহায্য করতে পারে।

কোন ওয়েব ব্রাউজারগুলি WebP সমর্থন করে?

সাইটের কর্মক্ষমতা উন্নত করতে আগ্রহী ওয়েবমাস্টাররা সহজেই তাদের বর্তমান চিত্রগুলির জন্য অপ্টিমাইজ করা WebP বিকল্প তৈরি করতে পারেন এবং WebP সমর্থনকারী ব্রাউজারগুলিতে লক্ষ্যবস্তু ভিত্তিতে সেগুলি পরিবেশন করতে পারেন।

  • WebP ক্ষতিকারক সমর্থন
    • গুগল ক্রোম (ডেস্কটপ) ১৭+
    • অ্যান্ড্রয়েড সংস্করণ ২৫+ এর জন্য গুগল ক্রোম
    • মাইক্রোসফট এজ ১৮+
    • ফায়ারফক্স ৬৫+
    • অপেরা ১১.১০+
    • নেটিভ ওয়েব ব্রাউজার, অ্যান্ড্রয়েড ৪.০+ (আইসিএস)
    • সাফারি ১৪+ (iOS ১৪+, macOS বিগ সুর+)
  • WebP ক্ষতিকারক, ক্ষতিহীন এবং আলফা সাপোর্ট
    • গুগল ক্রোম (ডেস্কটপ) ২৩+
    • অ্যান্ড্রয়েড সংস্করণ ২৫+ এর জন্য গুগল ক্রোম
    • মাইক্রোসফট এজ ১৮+
    • ফায়ারফক্স ৬৫+
    • অপেরা ১২.১০+
    • নেটিভ ওয়েব ব্রাউজার, অ্যান্ড্রয়েড ৪.২+ (JB-MR1)
    • ফ্যাকাশে চাঁদ ২৬+
    • সাফারি ১৪+ (iOS ১৪+, macOS বিগ সুর+)
  • WebP অ্যানিমেশন সাপোর্ট
    • গুগল ক্রোম (ডেস্কটপ এবং অ্যান্ড্রয়েড) ৩২+
    • মাইক্রোসফট এজ ১৮+
    • ফায়ারফক্স ৬৫+
    • অপেরা ১৯+
    • সাফারি ১৪+ (iOS ১৪+, macOS বিগ সুর+)

আরও দেখুন:

WebP এর জন্য ব্রাউজার সাপোর্ট কিভাবে সনাক্ত করব?

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

Accept হেডারের মাধ্যমে সার্ভার-সাইড কন্টেন্ট আলোচনা

ওয়েব ক্লায়েন্টদের জন্য "গ্রহণ করুন" অনুরোধের শিরোনাম পাঠানো খুবই সাধারণ, যা নির্দেশ করে যে তারা কোন কন্টেন্ট ফর্ম্যাটের প্রতিক্রিয়া গ্রহণ করতে ইচ্ছুক। যদি কোনও ব্রাউজার আগে থেকে ইঙ্গিত দেয় যে তারা ছবি/ওয়েবপি ফর্ম্যাট "গ্রহণ" করবে, তাহলে ওয়েব সার্ভার জানে যে এটি নিরাপদে WebP ছবি পাঠাতে পারে, যা বিষয়বস্তুর আলোচনাকে ব্যাপকভাবে সহজ করে তোলে। আরও তথ্যের জন্য নিম্নলিখিত লিঙ্কগুলি দেখুন।

মডার্নাইজার

Modernizr হল একটি জাভাস্ক্রিপ্ট লাইব্রেরি যা ওয়েব ব্রাউজারে HTML5 এবং CSS3 বৈশিষ্ট্য সমর্থনকে সুবিধাজনকভাবে সনাক্ত করে। Modernizr.webp , Modernizr.webp.lossless , Modernizr.webp.alpha এবং Modernizr.webp.animation বৈশিষ্ট্যগুলি সন্ধান করুন।

HTML5 <picture> এলিমেন্ট

HTML5 একটি <picture> এলিমেন্ট সমর্থন করে, যা আপনাকে অগ্রাধিকার ক্রমে একাধিক, বিকল্প ইমেজ টার্গেট তালিকাভুক্ত করতে দেয়, যাতে একজন ক্লায়েন্ট প্রথম ক্যান্ডিডেট ইমেজটি অনুরোধ করতে পারে যা এটি সঠিকভাবে প্রদর্শন করতে পারে। HTML5 রকস-এ এই আলোচনাটি দেখুন। <picture> এলিমেন্টটি সর্বদা আরও ব্রাউজার দ্বারা সমর্থিত ।

আপনার নিজস্ব জাভাস্ক্রিপ্টে

আরেকটি সনাক্তকরণ পদ্ধতি হল একটি খুব ছোট WebP চিত্র ডিকোড করার চেষ্টা করা যা একটি নির্দিষ্ট বৈশিষ্ট্য ব্যবহার করে এবং সাফল্য পরীক্ষা করে। উদাহরণ:

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

মনে রাখবেন যে ইমেজ-লোডিং ব্লকিং নয় এবং অ্যাসিঙ্ক্রোনাস। এর অর্থ হল যে কোনও কোড যা WebP সাপোর্টের উপর নির্ভর করে তা কলব্যাক ফাংশনে রাখা উচিত।

গুগল কেন ওপেন সোর্স হিসেবে WebP প্রকাশ করেছে?

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

আমি কিভাবে আমার ব্যক্তিগত ছবির ফাইলগুলিকে WebP-তে রূপান্তর করতে পারি?

আপনার ব্যক্তিগত চিত্র ফাইলগুলিকে WebP ফর্ম্যাটে রূপান্তর করতে আপনি WebP কমান্ড লাইন ইউটিলিটি ব্যবহার করতে পারেন। আরও বিস্তারিত জানার জন্য WebP ব্যবহার দেখুন।

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

উইন্ডোজ:

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

লিনাক্স / ম্যাকোস:

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

আমি কীভাবে নিজের জন্য WebP ছবির মান বিচার করব?

বর্তমানে, আপনি WebP ফাইলগুলিকে PNG এর মতো লসলেস কম্প্রেশন ব্যবহার করে এমন একটি সাধারণ ফর্ম্যাটে রূপান্তর করে দেখতে পারেন এবং তারপরে যেকোনো ব্রাউজার বা ইমেজ ভিউয়ারে PNG ফাইলগুলি দেখতে পারেন। WebP মানের দ্রুত ধারণা পেতে, পাশাপাশি ছবির তুলনার জন্য এই সাইটের গ্যালারিটি দেখুন।

আমি সোর্স কোড কিভাবে পাবো?

কনভার্টার কোডটি WebP ওপেন-সোর্স প্রজেক্ট পৃষ্ঠার ডাউনলোড বিভাগে পাওয়া যাবে। লাইটওয়েট ডিকোডারের কোড এবং VP8 স্পেসিফিকেশন WebM সাইটে রয়েছে। কন্টেইনার স্পেসিফিকেশনের জন্য RIFF কন্টেইনার পৃষ্ঠাটি দেখুন।

একটি WebP ছবির সর্বোচ্চ আকার কত হতে পারে?

WebP VP8 এর সাথে বিটস্ট্রিম-সামঞ্জস্যপূর্ণ এবং প্রস্থ এবং উচ্চতার জন্য 14 বিট ব্যবহার করে। একটি WebP ছবির সর্বোচ্চ পিক্সেল মাত্রা হল 16383 x 16383।

WebP ফর্ম্যাট কোন রঙের স্থান সমর্থন করে?

VP8 বিটস্ট্রিমের সাথে সামঞ্জস্যপূর্ণ, ক্ষতিকারক WebP একচেটিয়াভাবে 8-বিট Y'CbCr 4:2:0 (প্রায়শই YUV420 নামে পরিচিত) চিত্র ফর্ম্যাটের সাথে কাজ করে। আরও বিস্তারিত জানার জন্য অনুগ্রহ করে RFC 6386, VP8 ডেটা ফর্ম্যাট এবং ডিকোডিং গাইডের বিভাগ 2, " ফরম্যাট ওভারভিউ " দেখুন।

লসলেস ওয়েবপি একচেটিয়াভাবে আরজিবিএ ফর্ম্যাটের সাথে কাজ করে। ওয়েবপি লসলেস বিটস্ট্রিম স্পেসিফিকেশন দেখুন।

আমার লসলেস WebP ফাইলটি আসল ফাইল থেকে আলাদা কেন?

সিম্পল এনকোডিং API ফাংশনগুলি ( WebPEncodeLosslessRGB() , WebPEncodeLosslessBGR() , WebPEncodeLosslessRGBA() , WebPEncodeLosslessBGRA() ), লাইব্রেরির ডিফল্ট সেটিংস ব্যবহার করে। লসলেসের জন্য এর অর্থ হল 'exact' অক্ষম করা হয়েছে। সম্পূর্ণ স্বচ্ছ এলাকায় (অর্থাৎ, 0 এর সমান আলফা মান সহ এলাকা) RGB মানগুলি কম্প্রেশন উন্নত করার জন্য পরিবর্তন করা হবে। এটি এড়াতে, WebPEncode() ব্যবহার করুন এবং WebPConfig::exact 1 এ সেট করুন। উন্নত এনকোডিং API ডকুমেন্টেশন দেখুন।

একটি WebP ছবি কি তার উৎস ছবির চেয়ে বড় হতে পারে?

হ্যাঁ, সাধারণত যখন লসলি ফর্ম্যাট থেকে WebP লসলেস বা তদ্বিপরীত রূপান্তর করা হয়। এটি মূলত কালারস্পেসের পার্থক্য (YUV420 বনাম ARGB) এবং এগুলির মধ্যে রূপান্তরের কারণে।

তিনটি সাধারণ পরিস্থিতি রয়েছে:

  1. যদি সোর্স ইমেজটি লসলেস ARGB ফরম্যাটে থাকে, তাহলে YUV420-এ স্থানিক ডাউনস্যাম্পলিং নতুন রঙগুলি প্রবর্তন করবে যা মূল রঙের তুলনায় সংকুচিত করা কঠিন। এই পরিস্থিতি সাধারণত তখন ঘটতে পারে যখন সোর্সটি PNG ফরম্যাটে থাকে যেখানে কয়েকটি রঙ থাকে: ক্ষতিকারক WebP (অথবা, একইভাবে ক্ষতিকারক JPEG) তে রূপান্তর করলে সম্ভাব্যভাবে ফাইলের আকার বড় হবে।
  2. যদি উৎসটি ক্ষতিকারক ফর্ম্যাটে থাকে, তাহলে উৎসের ক্ষতিকারক প্রকৃতি ক্যাপচার করার জন্য লসলেস WebP কম্প্রেশন ব্যবহার করলে সাধারণত একটি বড় ফাইল তৈরি হবে। এটি WebP-এর জন্য বিশেষভাবে প্রযোজ্য নয়, এবং উদাহরণস্বরূপ, JPEG উৎসকে লসলেস WebP বা PNG ফর্ম্যাটে রূপান্তর করার সময় ঘটতে পারে।
  3. যদি সোর্সটি লজি ফরম্যাটে থাকে এবং আপনি এটিকে উচ্চ মানের সেটিং সহ একটি লজি WebP হিসেবে সংকুচিত করার চেষ্টা করছেন। উদাহরণস্বরূপ, কোয়ালিটি 80 এ সংরক্ষিত একটি JPEG ফাইলকে 95 মানের WebP ফাইলে রূপান্তর করার চেষ্টা করলে সাধারণত একটি বড় ফাইল তৈরি হবে, এমনকি উভয় ফর্ম্যাটই লজি হলেও। সোর্সের মান মূল্যায়ন করা প্রায়শই অসম্ভব, তাই ফাইলের আকার ধারাবাহিকভাবে বড় হলে লক্ষ্য WebP গুণমান কমানোর পরামর্শ দেওয়া হয়। আরেকটি সম্ভাবনা হল কোয়ালিটি সেটিং ব্যবহার করা এড়িয়ে যাওয়া এবং পরিবর্তে cwebp টুলে -size বিকল্প ব্যবহার করে একটি নির্দিষ্ট ফাইল আকার লক্ষ্য করা, অথবা সমতুল্য API। উদাহরণস্বরূপ, মূল ফাইল আকারের 80% লক্ষ্য করা আরও শক্তিশালী প্রমাণিত হতে পারে।

মনে রাখবেন যে JPEG সোর্সকে লজি WebP তে অথবা PNG সোর্সকে লসলেস WebP তে রূপান্তর করলে ফাইলের আকারের এই ধরনের চমকের সম্ভাবনা থাকে না।

WebP কি প্রগতিশীল বা ইন্টারলেসড ডিসপ্লে সমর্থন করে?

WebP JPEG বা PNG অর্থে কোনও প্রগতিশীল বা ইন্টারলেসড ডিকোডিং রিফ্রেশ অফার করে না। এটি ডিকোডিং ক্লায়েন্টের CPU এবং মেমোরির উপর অত্যধিক চাপ সৃষ্টি করতে পারে কারণ প্রতিটি রিফ্রেশ ইভেন্টে ডিকম্প্রেশন সিস্টেমের মাধ্যমে সম্পূর্ণ পাস জড়িত থাকে।

গড়ে, একটি প্রগতিশীল JPEG চিত্র ডিকোড করা বেসলাইনটিকে 3 বার ডিকোড করার সমতুল্য।

বিকল্পভাবে, WebP ইনক্রিমেন্টাল ডিকোডিং অফার করে, যেখানে বিটস্ট্রিমের সমস্ত উপলব্ধ ইনকামিং বাইট ব্যবহার করে যত তাড়াতাড়ি সম্ভব একটি প্রদর্শনযোগ্য নমুনা সারি তৈরি করার চেষ্টা করা হয়। এটি মেমরি, CPU এবং ক্লায়েন্টে পুনরায় রঙ করার প্রচেষ্টা উভয়ই সাশ্রয় করে এবং ডাউনলোডের অবস্থা সম্পর্কে ভিজ্যুয়াল ইঙ্গিত প্রদান করে। ইনক্রিমেন্টাল ডিকোডিং বৈশিষ্ট্যটি অ্যাডভান্সড ডিকোডিং API এর মাধ্যমে উপলব্ধ।

আমার অ্যান্ড্রয়েড প্রজেক্টে libwebp জাভা বাইন্ডিং কিভাবে ব্যবহার করব?

WebP-তে swig/ ডিরেক্টরিতে থাকা সরল এনকোডার এবং ডিকোডার ইন্টারফেসে JNI বাইন্ডিংয়ের জন্য সমর্থন অন্তর্ভুক্ত রয়েছে।

Eclipse- এ লাইব্রেরি তৈরি করা:

  1. নিশ্চিত করুন যে আপনার NDK টুলের সাথে ADT প্লাগইন ইনস্টল করা আছে এবং আপনার NDK পাথ সঠিকভাবে সেট করা আছে ( Preferences > Android > NDK )।
  2. একটি নতুন প্রকল্প তৈরি করুন: ফাইল > নতুন > প্রকল্প > অ্যান্ড্রয়েড অ্যাপ্লিকেশন প্রকল্প ।
  3. নতুন প্রজেক্টে jni নামের একটি ফোল্ডারে libwebp ক্লোন বা আনপ্যাক করুন।
  4. LOCAL_SRC_FILES তালিকায় swig/libwebp_java_wrap.c যোগ করুন।
  5. নতুন প্রজেক্টে ডান-ক্লিক করুন এবং আপনার বিল্ডে লাইব্রেরি অন্তর্ভুক্ত করতে Android Tools > Add Native Support ... নির্বাচন করুন।

  6. প্রোজেক্ট প্রোপার্টিজ খুলুন এবং C/C++ Build > Behaviour এ যান। libwebp কে একটি শেয়ার্ড লাইব্রেরি হিসেবে তৈরি করতে Build (Incremental build) বিভাগে ENABLE_SHARED=1 যোগ করুন।

    দ্রষ্টব্য NDK_TOOLCHAIN_VERSION=4.8 সেটিং করলে সাধারণত 32-বিট বিল্ড কর্মক্ষমতা উন্নত হবে।

  7. libs/ প্রজেক্ট ফোল্ডারে swig/libwebp.jar যোগ করুন।

  8. আপনার প্রকল্প তৈরি করুন। এটি libs/<target-arch>/libwebp.so তৈরি করবে।

  9. রানটাইমে লাইব্রেরি লোড করতে System.loadLibrary("webp") ব্যবহার করুন।

মনে রাখবেন যে লাইব্রেরিটি ndk-build এবং এর সাথে অন্তর্ভুক্ত Android.mk দিয়ে ম্যানুয়ালি তৈরি করা যেতে পারে। উপরে বর্ণিত কিছু ধাপ সেই ক্ষেত্রে পুনরায় ব্যবহার করা যেতে পারে।

আমি কিভাবে C# এর সাথে libwebp ব্যবহার করব?

WebP একটি DLL হিসেবে তৈরি করা যেতে পারে যা libwebp API রপ্তানি করে। এই ফাংশনগুলি তারপর C# তে আমদানি করা যেতে পারে।

  1. libwebp.dll তৈরি করুন। এটি API ফাংশনগুলি রপ্তানি করার জন্য WEBP_EXTERN সঠিকভাবে সেট করবে।

    libwebp> nmake /f Makefile.vc CFG=release-dynamic

  2. আপনার প্রোজেক্টে libwebp.dll যোগ করুন এবং পছন্দসই ফাংশনগুলি আমদানি করুন। মনে রাখবেন, যদি আপনি সহজ API ব্যবহার করেন তবে আপনার ফিরে আসা যেকোনো বাফার মুক্ত করার জন্য WebPFree() কল করা উচিত।

    [DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                 float quality_factor, out IntPtr output);
[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPFree(IntPtr p);

void Encode() {
  Bitmap source = new Bitmap("input.png");
  BitmapData data = source.LockBits(
      new Rectangle(0, 0, source.Width, source.Height),
      ImageLockMode.ReadOnly,
      PixelFormat.Format32bppArgb);
  IntPtr webp_data;
  const int size = WebPEncodeBGRA(data.Scan0,
                                  source.Width, source.Height, data.Stride,
                                  80, out webp_data);
  // ...
  WebPFree(webp_data);
}

আমি কেন অ্যানিমেটেড WebP ব্যবহার করব?

অ্যানিমেটেড GIF এর তুলনায় অ্যানিমেটেড WebP এর সুবিধা

  1. GIF-এর ৮-বিট রঙ এবং ১-বিট আলফার তুলনায়, WebP ৮-বিট আলফা চ্যানেল সহ ২৪-বিট RGB রঙ সমর্থন করে।

  2. WebP ক্ষতিকারক এবং ক্ষতিহীন উভয় ধরণের কম্প্রেশন সমর্থন করে; প্রকৃতপক্ষে, একটি একক অ্যানিমেশন ক্ষতিকারক এবং ক্ষতিহীন ফ্রেমগুলিকে একত্রিত করতে পারে। GIF শুধুমাত্র ক্ষতিকারক কম্প্রেশন সমর্থন করে। WebP-এর ক্ষতিকারক কম্প্রেশন কৌশলগুলি বাস্তব-বিশ্বের ভিডিও থেকে তৈরি অ্যানিমেটেড চিত্রগুলির জন্য উপযুক্ত, যা অ্যানিমেটেড চিত্রগুলির ক্রমবর্ধমান জনপ্রিয় উৎস।

  3. WebP-এর জন্য GIF 1-এর তুলনায় কম বাইট প্রয়োজন। ক্ষতিকারক WebP-তে রূপান্তরিত অ্যানিমেটেড GIF গুলি 64% ছোট, যেখানে ক্ষতিহীন WebP গুলি 19% ছোট। এটি বিশেষ করে মোবাইল নেটওয়ার্কের ক্ষেত্রে গুরুত্বপূর্ণ।

  4. WebP-এর ডিকোডিং এর সময় কম লাগে, কারণ Seeking এর উপস্থিতিতে WebP ডিকোডিং করতে কম সময় নেয়। Blink- এ, স্ক্রলিং বা ট্যাব পরিবর্তন করলে ছবি লুকানো এবং দেখানো যায়, যার ফলে অ্যানিমেশনগুলি বিরতি দেওয়া হয় এবং তারপর অন্য বিন্দুতে এগিয়ে যায়। অতিরিক্ত CPU ব্যবহারের ফলে অ্যানিমেশনগুলি ফ্রেম ড্রপ করে, যার ফলে অ্যানিমেশনে ডিকোডারকে এগিয়ে যেতেও হতে পারে। এই পরিস্থিতিতে, অ্যানিমেটেড WebP GIF-এর মোট ডিকোডিং সময় 0.57 গুণ বেশি সময় নেয়, যার ফলে স্ক্রোলিংয়ের সময় কম জ্যাঙ্ক হয় এবং CPU ব্যবহারের স্পাইক থেকে দ্রুত পুনরুদ্ধার হয়। GIF-এর তুলনায় WebP-এর দুটি সুবিধার কারণে এটি সম্ভব:

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

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

অ্যানিমেটেড GIF এর তুলনায় অ্যানিমেটেড WebP এর অসুবিধাগুলি

  1. সিকিং এর অভাবে, WebP এর সরলরেখা ডিকোডিং GIF এর তুলনায় CPU-নিবিড়। Lossy WebP GIF এর তুলনায় 2.2 গুণ বেশি ডিকোডিং সময় নেয়, যেখানে লসলেস WebP এর 1.5 গুণ বেশি সময় নেয়।

  2. WebP সাপোর্ট GIF সাপোর্টের মতো এত ব্যাপক নয়, যা কার্যকরভাবে সর্বজনীন।

  3. ব্রাউজারগুলিতে WebP সাপোর্ট যোগ করলে কোড ফুটপ্রিন্ট এবং আক্রমণ পৃষ্ঠ বৃদ্ধি পায়। Blink-এ এটি প্রায় 1500 অতিরিক্ত কোড লাইন (WebP demux লাইব্রেরি এবং Blink-side WebP ইমেজ ডিকোডার সহ)। মনে রাখবেন যে WebP এবং WebM যদি আরও সাধারণ ডিকোডিং কোড ভাগ করে নেয়, অথবা WebP-এর ক্ষমতা WebM-এর মধ্যে অন্তর্ভুক্ত করা হয় তবে ভবিষ্যতে এই সমস্যাটি হ্রাস পেতে পারে।

<img> তে কেন কেবল WebM সাপোর্ট করবেন না?

<img> ট্যাগের ভেতরে ভিডিও ফরম্যাট সাপোর্ট করা দীর্ঘমেয়াদে যুক্তিসঙ্গত হতে পারে। তবে, এখন এটি করা, এই উদ্দেশ্যে যে <img> এ WebM অ্যানিমেটেড WebP-এর প্রস্তাবিত ভূমিকা পূরণ করতে পারে, সমস্যাযুক্ত:

  1. পূর্ববর্তী ফ্রেমের উপর নির্ভরশীল একটি ফ্রেম ডিকোড করার সময়, পূর্ববর্তী ফ্রেমের ন্যূনতম সংখ্যা ধরে রাখতে WebM-এর অ্যানিমেটেড WebP-এর তুলনায় 50% বেশি মেমরির প্রয়োজন হয় 3 ।

  2. ভিডিও কোডেক এবং কন্টেইনার সাপোর্ট ব্রাউজার এবং ডিভাইস জুড়ে ব্যাপকভাবে পরিবর্তিত হয়। স্বয়ংক্রিয় কন্টেন্ট ট্রান্সকোডিং (যেমন ব্যান্ডউইথ-সেভিং প্রক্সির জন্য) সহজতর করার জন্য, ব্রাউজারগুলিকে তাদের ইমেজ ট্যাগ কোন ফর্ম্যাট সমর্থন করে তা নির্দেশ করে এমন accept হেডার যুক্ত করতে হবে। এমনকি এটিও অপর্যাপ্ত হতে পারে, কারণ "video/webm" বা "video/mpeg" এর মতো MIME প্রকারগুলি এখনও কোডেক সাপোর্ট নির্দেশ করে না (যেমন VP8 বনাম VP9)। অন্যদিকে, WebP ফর্ম্যাট কার্যকরভাবে হিমায়িত, এবং যদি এটি সরবরাহকারী বিক্রেতারা অ্যানিমেটেড WebP পাঠাতে সম্মত হন, তাহলে সমস্ত UA জুড়ে WebP এর আচরণ সামঞ্জস্যপূর্ণ হওয়া উচিত; এবং যেহেতু "image/webp" accept হেডার ইতিমধ্যেই WebP সাপোর্ট নির্দেশ করতে ব্যবহৃত হয়েছে, তাই কোনও নতুন accept হেডার পরিবর্তনের প্রয়োজন নেই।

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

  4. WebM বর্তমানে WebP থেকে সমস্ত কম্প্রেশন কৌশল অন্তর্ভুক্ত করে না। ফলস্বরূপ, এই ছবিটি বিকল্পগুলির তুলনায় WebP এর সাথে উল্লেখযোগ্যভাবে ভালভাবে কম্প্রেশন করে:

১. অ্যানিমেটেড GIF এবং অ্যানিমেটেড WebP এর মধ্যে তুলনা করার জন্য, আমরা ওয়েব থেকে এলোমেলোভাবে তোলা প্রায় ৭০০০ অ্যানিমেটেড GIF ছবির একটি সংগ্রহ ব্যবহার করেছি। এই ছবিগুলিকে ডিফল্ট সেটিংস ব্যবহার করে 'gif2webp' টুল ব্যবহার করে অ্যানিমেটেড WebP তে রূপান্তর করা হয়েছে (১০/০৮/২০১৩ তারিখের সর্বশেষ libwebp সোর্স ট্রি থেকে তৈরি)। তুলনামূলক সংখ্যাগুলি হল এই ছবিগুলির গড় মান।

২ ১০/০৮/২০১৩ তারিখে সর্বশেষ libwebp + ToT Blink ব্যবহার করে একটি বেঞ্চমার্ক টুল ব্যবহার করে ডিকোড সময় গণনা করা হয়েছিল। "সন্ধানের সময় ডিকোড করুন" কে "প্রথম পাঁচটি ফ্রেম ডিকোড করুন, ফ্রেম বাফার ক্যাশে সাফ করুন, পরবর্তী পাঁচটি ফ্রেম ডিকোড করুন, ইত্যাদি" হিসাবে গণনা করা হয়।

3 WebM মেমোরিতে 4টি YUV রেফারেন্স ফ্রেম রাখে, প্রতিটি ফ্রেম (width+96)*(height+96) পিক্সেল সংরক্ষণ করে। YUV 4:2:0 এর জন্য, আমাদের প্রতি 6 পিক্সেলের জন্য 4 বাইট (অথবা প্রতি পিক্সেলের জন্য 3/2 বাইট) প্রয়োজন। সুতরাং, এই রেফারেন্স ফ্রেমগুলি 4*3/2*(width+96)*(height+96) বাইট মেমোরি ব্যবহার করে। অন্যদিকে, WebP-এর জন্য কেবল পূর্ববর্তী ফ্রেম (RGBA-তে) প্রয়োজন হবে, যা 4*width*height বাইট মেমোরি।

৪টি অ্যানিমেটেড WebP রেন্ডারিংয়ের জন্য Google Chrome সংস্করণ 32+ প্রয়োজন।