سوالات متداول

WebP چیست؟ چرا باید از آن استفاده کنم؟

WebP روشی برای فشرده سازی بدون اتلاف و اتلاف است که می تواند بر روی انواع زیادی از تصاویر عکاسی، شفاف و گرافیکی موجود در وب استفاده شود. درجه فشرده‌سازی با اتلاف قابل تنظیم است، بنابراین کاربر می‌تواند بین اندازه فایل و کیفیت تصویر تعادل را انتخاب کند. WebP معمولاً به طور متوسط ​​30٪ فشرده سازی بیشتر از JPEG و JPEG 2000 را بدون کاهش کیفیت تصویر انجام می دهد (به مطالعه مقایسه ای مراجعه کنید).

فرمت WebP اساساً با هدف ایجاد تصاویر کوچکتر و زیباتر است که می تواند به سرعت بخشیدن به وب کمک کند.

کدام مرورگرهای وب بطور بومی از WebP پشتیبانی می کنند؟

وب مسترهایی که علاقه مند به بهبود عملکرد سایت هستند می توانند به راحتی جایگزین های WebP بهینه شده را برای تصاویر فعلی خود ایجاد کنند و آنها را به صورت هدفمند به مرورگرهایی که از WebP پشتیبانی می کنند ارائه دهند.

  • پشتیبانی از WebP با ضرر
    • Google Chrome (رومیزی) 17+
    • Google Chrome برای اندروید نسخه 25+
    • مایکروسافت اج 18+
    • فایرفاکس 65+
    • Opera 11.10+
    • مرورگر وب بومی، Android 4.0 و بالاتر (ICS)
    • Safari 14+ (iOS 14+، macOS Big Sur+)
  • پشتیبانی از WebP با اتلاف، بدون ضرر و آلفا
    • Google Chrome (رومیزی) 23+
    • Google Chrome برای اندروید نسخه 25+
    • مایکروسافت اج 18+
    • فایرفاکس 65+
    • Opera 12.10+
    • مرورگر وب بومی، Android 4.2 و بالاتر (JB-MR1)
    • ماه رنگ پریده 26+
    • Safari 14+ (iOS 14+، macOS Big Sur+)
  • پشتیبانی از انیمیشن WebP
    • Google Chrome (رومیزی و اندروید) 32+
    • مایکروسافت اج 18+
    • فایرفاکس 65+
    • Opera 19+
    • Safari 14+ (iOS 14+، macOS Big Sur+)

همچنین ببینید:

چگونه می توانم پشتیبانی مرورگر برای WebP را تشخیص دهم؟

شما می خواهید تصاویر WebP را فقط به مشتریانی ارائه دهید که می توانند آنها را به درستی نمایش دهند و برای مشتریانی که نمی توانند به فرمت های قدیمی برگردید. خوشبختانه چندین تکنیک برای شناسایی پشتیبانی WebP وجود دارد، هم در سمت مشتری و هم در سمت سرور. برخی از ارائه دهندگان CDN شناسایی پشتیبانی WebP را به عنوان بخشی از خدمات خود ارائه می دهند.

مذاکره محتوای سمت سرور از طریق هدرهای Accept

معمولاً مشتریان وب یک سرصفحه درخواست «پذیرفتن» ارسال می‌کنند که نشان می‌دهد در پاسخ به کدام قالب‌های محتوایی می‌خواهند بپذیرند. اگر یک مرورگر از قبل نشان دهد که فرمت تصویر/وب را «می‌پذیرد»، سرور وب می‌داند که می‌تواند با خیال راحت تصاویر WebP را ارسال کند، که مذاکرات محتوا را بسیار ساده‌تر می‌کند. برای اطلاعات بیشتر به لینک های زیر مراجعه کنید.

مدرنیزر

Modernizr یک کتابخانه جاوا اسکریپت برای شناسایی راحت پشتیبانی از ویژگی های HTML5 و CSS3 در مرورگرهای وب است. به دنبال ویژگی های Modernizr.webp ، Modernizr.webp.lossless ، Modernizr.webp.alpha و Modernizr.webp.animation بگردید.

عنصر <picture> HTML5

HTML5 از یک عنصر <picture> پشتیبانی می کند، که به شما امکان می دهد چندین هدف تصویر جایگزین را به ترتیب اولویت فهرست کنید، به طوری که مشتری اولین تصویر نامزدی را که بتواند به درستی نمایش دهد درخواست کند. این بحث را در مورد HTML5 Rocks ببینید. عنصر <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 بستگی دارد ترجیحاً باید در تابع callback قرار داده شود.

چرا گوگل WebP را به عنوان منبع باز منتشر کرد؟

ما عمیقاً به اهمیت مدل منبع باز اعتقاد داریم. با WebP به صورت متن باز، هر کسی می تواند با فرمت کار کند و بهبودهایی را پیشنهاد دهد. با نظرات و پیشنهادات شما، ما معتقدیم که WebP به مرور زمان به عنوان یک فرمت گرافیکی مفیدتر خواهد شد.

چگونه می توانم فایل های تصاویر شخصی خود را به WebP تبدیل کنم؟

می توانید از ابزار خط فرمان WebP برای تبدیل فایل های تصویری شخصی خود به فرمت WebP استفاده کنید. برای جزئیات بیشتر به استفاده از WebP مراجعه کنید.

اگر تصاویر زیادی برای تبدیل دارید، می توانید از پوسته پلت فرم خود برای ساده کردن عملیات استفاده کنید. به عنوان مثال، برای تبدیل همه فایل‌های jpeg در یک پوشه، موارد زیر را امتحان کنید:

ویندوز:

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

لینوکس / macOS: 

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

چگونه می توانم کیفیت تصویر WebP را برای خودم قضاوت کنم؟

در حال حاضر، می‌توانید فایل‌های WebP را با تبدیل آنها به یک فرمت معمولی که از فشرده‌سازی بدون اتلاف استفاده می‌کند، مانند PNG، مشاهده کنید و سپس فایل‌های PNG را در هر مرورگر یا نمایشگر تصویر مشاهده کنید. برای دریافت ایده سریع از کیفیت WebP، برای مقایسه عکس های کنار هم به گالری این سایت مراجعه کنید.

چگونه کد منبع را دریافت کنم؟

کد مبدل در بخش دانلودهای صفحه پروژه منبع باز WebP موجود است. کد رمزگشای سبک وزن و مشخصات VP8 در سایت WebM موجود است. برای مشخصات کانتینر به صفحه RIFF Container مراجعه کنید.

حداکثر اندازه ای که یک تصویر WebP می تواند داشته باشد چقدر است؟

WebP با VP8 با جریان بیت سازگار است و از 14 بیت برای عرض و ارتفاع استفاده می کند. حداکثر ابعاد پیکسل یک تصویر WebP 16383 x 16383 است.

فرمت WebP از چه فضاهای رنگی پشتیبانی می کند؟

مطابق با جریان بیت VP8، WebP با اتلاف منحصراً با فرمت تصویر 8 بیتی Y'CbCr 4:2:0 (که اغلب YUV420 نامیده می شود) کار می کند. لطفاً برای جزئیات بیشتر به بخش 2، " نمای کلی قالب " RFC 6386، فرمت داده VP8 و راهنمای رمزگشایی مراجعه کنید.

Lossless WebP منحصراً با فرمت RGBA کار می کند. مشخصات WebP Lossless Bitstream را ببینید.

آیا یک تصویر WebP می تواند بزرگتر از تصویر منبع خود باشد؟

بله، معمولاً هنگام تبدیل از یک فرمت با اتلاف به WebP بدون ضرر یا برعکس. این عمدتا به دلیل تفاوت فضای رنگی (YUV420 در مقابل ARGB) و تبدیل بین آنها است.

سه حالت معمولی وجود دارد:

  1. اگر تصویر منبع در فرمت ARGB بدون اتلاف باشد، نمونه برداری فضایی به YUV420 رنگ های جدیدی را معرفی می کند که فشرده سازی آنها از رنگ های اصلی سخت تر است. این وضعیت معمولاً زمانی اتفاق می‌افتد که منبع در فرمت PNG با رنگ‌های کمی باشد: تبدیل به WebP با اتلاف (یا به طور مشابه به JPEG با اتلاف) به طور بالقوه منجر به حجم فایل بزرگ‌تر می‌شود.
  2. اگر منبع در فرمت با اتلاف باشد، استفاده از فشرده‌سازی WebP بدون اتلاف برای گرفتن ماهیت پرتلفات منبع، معمولاً منجر به ایجاد یک فایل بزرگ‌تر می‌شود. این مورد مخصوص WebP نیست و برای مثال می‌تواند هنگام تبدیل یک منبع JPEG به فرمت‌های WebP یا PNG بدون اتلاف رخ دهد.
  3. اگر منبع در فرمت با اتلاف است و می‌خواهید آن را به عنوان یک WebP با اتلاف با تنظیمات کیفیت بالاتر فشرده کنید. به عنوان مثال، تلاش برای تبدیل یک فایل JPEG ذخیره شده با کیفیت 80 به یک فایل WebP با کیفیت 95 معمولاً منجر به یک فایل بزرگتر می شود، حتی اگر هر دو فرمت دارای اتلاف باشند. ارزیابی کیفیت منبع اغلب غیرممکن است، بنابراین اگر اندازه فایل به طور مداوم بزرگتر است، توصیه می شود کیفیت WebP هدف را کاهش دهید. امکان دیگر این است که از استفاده از تنظیمات کیفیت اجتناب کنید و در عوض اندازه فایل معین را با استفاده از گزینه -size در ابزار cwebp یا API معادل آن هدف قرار دهید. به عنوان مثال، هدف قرار دادن 80٪ از اندازه فایل اصلی ممکن است قوی تر باشد.

توجه داشته باشید که تبدیل یک منبع JPEG به WebP با اتلاف، یا یک منبع PNG به WebP بدون اتلاف، مستعد چنین شگفتی هایی در اندازه فایل نیست.

آیا WebP از نمایشگر پیشرونده یا interlaced پشتیبانی می کند؟

WebP به‌روزرسانی رمزگشایی پیشرونده یا درون‌آمیزی را به معنای JPEG یا PNG ارائه نمی‌کند. این احتمالاً فشار زیادی بر CPU و حافظه مشتری رمزگشا وارد می کند زیرا هر رویداد تازه سازی شامل عبور کامل از سیستم رفع فشار است.

به طور متوسط، رمزگشایی یک تصویر پیشرونده JPEG معادل رمزگشایی 3 بار خط پایه است.

روش دیگر، WebP رمزگشایی افزایشی را ارائه می‌دهد، که در آن از تمام بایت‌های ورودی موجود بیت‌استریم برای تولید یک ردیف نمونه قابل نمایش در اسرع وقت استفاده می‌شود. این کار باعث صرفه جویی در حافظه، CPU و تلاش مجدد روی کلاینت می شود و در عین حال نشانه های بصری در مورد وضعیت دانلود ارائه می دهد. ویژگی رمزگشایی افزایشی از طریق Advanced Decoding API در دسترس است.

چگونه از اتصالات جاوا libwebp در پروژه اندروید خود استفاده کنم؟

WebP شامل پشتیبانی از اتصالات JNI به رابط های رمزگذار ساده و رمزگشا در دایرکتوری swig/ .

ساخت کتابخانه در Eclipse :

  1. مطمئن شوید که افزونه ADT را در کنار ابزارهای NDK نصب کرده اید و مسیر NDK شما به درستی تنظیم شده است ( Preferences > Android > NDK ).
  2. یک پروژه جدید ایجاد کنید: File > New > Project > Android Application Project .
  3. libwebp را در پوشه ای به نام jni در پروژه جدید کلون یا باز کنید.
  4. swig/libwebp_java_wrap.c را به لیست LOCAL_SRC_FILES اضافه کنید.
  5. روی پروژه جدید کلیک راست کرده و Android Tools > Add Native Support ... را انتخاب کنید تا کتابخانه در بیلد شما گنجانده شود.

  6. ویژگی های پروژه را باز کنید و به C/C++ Build > Behavior بروید. ENABLE_SHARED=1 به بخش Build (Incremental build) اضافه کنید تا libwebp به عنوان یک کتابخانه مشترک ساخته شود.

    توجه داشته باشید تنظیم NDK_TOOLCHAIN_VERSION=4.8 به طور کلی عملکرد ساخت 32 بیتی را بهبود می بخشد.

  7. swig/libwebp.jar را به پوشه libs/ project اضافه کنید.

  8. پروژه خود را بسازید این باعث ایجاد libs/<target-arch>/libwebp.so می شود.

  9. از System.loadLibrary("webp") برای بارگیری کتابخانه در زمان اجرا استفاده کنید.

توجه داشته باشید که کتابخانه را می توان به صورت دستی با ndk-build و Android.mk همراه ساخت. برخی از مراحل توضیح داده شده در بالا را می توان در این مورد مجددا استفاده کرد.

چگونه از libwebp با سی شارپ استفاده کنم؟

WebP می تواند به عنوان یک DLL ساخته شود که API libwebp را صادر می کند. سپس این توابع را می توان در سی شارپ وارد کرد.

  1. libwebp.dll را بسازید. این WEBP_EXTERN را به درستی تنظیم می کند تا توابع API را صادر کند.

    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 متحرک استفاده کنم؟

مزایای WebP متحرک در مقایسه با GIF متحرک

  1. WebP از رنگ 24 بیتی RGB با کانال آلفای 8 بیتی در مقایسه با رنگ 8 بیتی GIF و آلفای 1 بیتی پشتیبانی می کند.

  2. WebP از فشرده سازی با اتلاف و بدون اتلاف پشتیبانی می کند. در واقع، یک انیمیشن واحد می تواند فریم های با اتلاف و بدون اتلاف را ترکیب کند. GIF فقط از فشرده سازی بدون اتلاف پشتیبانی می کند. تکنیک‌های فشرده‌سازی با اتلاف WebP برای تصاویر متحرک ایجاد شده از ویدیوهای دنیای واقعی، که منبعی محبوب از تصاویر متحرک است، مناسب هستند.

  3. WebP به بایت های کمتری نسبت به GIF 1 نیاز دارد. گیف های متحرک تبدیل شده به WebP های با اتلاف 64 درصد کوچکتر هستند، در حالی که WebP های بدون ضرر 19 درصد کوچکتر هستند. این امر به ویژه در شبکه های تلفن همراه بسیار مهم است.

  4. WebP زمان کمتری برای رمزگشایی در حضور جستجو می‌گیرد. در Blink ، پیمایش یا تغییر برگه‌ها می‌تواند تصاویر را پنهان و نشان دهد، در نتیجه انیمیشن‌ها متوقف می‌شوند و سپس به جلو به نقطه دیگری پرش می‌شوند. استفاده بیش از حد از CPU که منجر به افت فریم انیمیشن ها می شود، همچنین می تواند نیاز به جستجوی رمزگشا در انیمیشن داشته باشد. در این سناریوها، WebP متحرک 0.57 برابر کل زمان رمزگشایی 2 را نسبت به GIF می‌گیرد، که در نتیجه در حین پیمایش، jank کمتری ایجاد می‌کند و بازیابی سریع‌تر از جهش‌های استفاده از CPU. این به دلیل دو مزیت WebP نسبت به GIF است:

    • تصاویر WebP ابرداده‌هایی را در مورد اینکه آیا هر فریم حاوی آلفا است ذخیره می‌کند و نیاز به رمزگشایی فریم برای انجام این تعیین را از بین می‌برد. این منجر به استنباط دقیق‌تر می‌شود که یک فریم معین به کدام فریم‌های قبلی بستگی دارد و در نتیجه رمزگشایی غیرضروری فریم‌های قبلی را کاهش می‌دهد.

    • بسیار شبیه یک رمزگذار ویدیوی مدرن، رمزگذار WebP به صورت اکتشافی فریم های کلیدی را در فواصل زمانی منظم اضافه می کند (که اکثر رمزگذارهای GIF انجام نمی دهند). این به طور چشمگیری جستجو را در انیمیشن های طولانی بهبود می بخشد. برای تسهیل درج چنین فریم هایی بدون افزایش قابل توجه اندازه تصویر، WebP علاوه بر روش حذف فریم که GIF از آن استفاده می کند ، پرچم «روش ترکیبی» را برای هر فریم اضافه می کند. این به یک فریم کلیدی اجازه می‌دهد طوری ترسیم کند که انگار کل تصویر به رنگ پس‌زمینه پاک شده است، بدون اینکه قاب قبلی مجبور شود اندازه کامل شود.

معایب WebP متحرک در مقایسه با GIF متحرک

  1. در غیاب جستجو، رمزگشایی مستقیم WebP نسبت به GIF به CPU فشرده تر است. Lossy WebP 2.2 برابر زمان رمزگشایی GIF طول می کشد، در حالی که WebP بدون اتلاف 1.5 برابر بیشتر زمان می برد.

  2. پشتیبانی از WebP تقریباً به اندازه پشتیبانی GIF گسترده نیست، که به طور مؤثر جهانی است.

  3. افزودن پشتیبانی WebP به مرورگرها باعث افزایش ردپای کد و سطح حمله می شود. در Blink این تقریباً 1500 خط کد اضافی است (از جمله کتابخانه demux WebP و رمزگشای تصویر WebP سمت Blink). توجه داشته باشید که اگر WebP و WebM کد رمزگشایی مشترک تری را به اشتراک بگذارند، یا اگر قابلیت‌های WebP در WebM جمع شوند، این مشکل می‌تواند در آینده کاهش یابد.

چرا به سادگی از WebM در <img> پشتیبانی نمی کنید؟

ممکن است پشتیبانی طولانی مدت از فرمت های ویدئویی در تگ <img> منطقی باشد. با این حال، انجام این کار اکنون، با این هدف که WebM در <img> بتواند نقش پیشنهادی WebP متحرک را پر کند، مشکل ساز است:

  1. هنگام رمزگشایی فریمی که به فریم‌های قبلی متکی است، WebM به 50 درصد حافظه بیشتر از WebP متحرک نیاز دارد تا حداقل تعداد فریم‌های قبلی را نگه دارد .

  2. پشتیبانی از کدک ویدیویی و کانتینر در مرورگرها و دستگاه‌ها بسیار متفاوت است. برای تسهیل رمزگذاری خودکار محتوا (مثلاً برای پراکسی های صرفه جویی در پهنای باند)، مرورگرها باید سرصفحه های پذیرش را اضافه کنند که نشان می دهد برچسب های تصویر آنها از چه قالب هایی پشتیبانی می کند. حتی این ممکن است ناکافی باشد، زیرا انواع MIME مانند "video/webm" یا "video/mpeg" هنوز پشتیبانی کدک را نشان نمی دهند (مثلا VP8 در مقابل VP9). از سوی دیگر، قالب WebP به طور موثر ثابت است، و اگر فروشندگانی که آن را ارسال می کنند با ارسال WebP متحرک موافقت کنند، رفتار WebP در تمام UA ها باید سازگار باشد. و از آنجایی که هدر پذیرش "تصویر/webp" قبلاً برای نشان دادن پشتیبانی WebP استفاده شده است، هیچ تغییر جدیدی در هدر پذیرش لازم نیست.

  3. پشته ویدیوی Chromium برای پخش روان بهینه شده است و فرض می‌کند فقط یک یا دو ویدیو در یک زمان پخش می‌شود. در نتیجه، پیاده سازی در مصرف منابع سیستم (رشته ها، حافظه، و غیره) برای به حداکثر رساندن کیفیت پخش تهاجمی است. چنین پیاده‌سازی برای بسیاری از ویدیوهای هم‌زمان به خوبی مقیاس نمی‌شود و باید برای استفاده در صفحات وب با تصویر سنگین طراحی شود.

  4. WebM در حال حاضر تمام تکنیک های فشرده سازی را از WebP ترکیب نمی کند. در نتیجه، این تصویر به طور قابل توجهی با WebP بهتر از موارد جایگزین فشرده می شود:

1 برای همه مقایسه‌ها بین GIF متحرک و WebP متحرک، ما از مجموعه‌ای از حدود 7000 تصویر GIF متحرک که به‌طور تصادفی از وب گرفته شده‌اند استفاده کردیم. این تصاویر با استفاده از ابزار 'gif2webp' با استفاده از تنظیمات پیش فرض (ساخته شده از آخرین درخت منبع libwebp در تاریخ 10/08/2013) به WebP متحرک تبدیل شدند. اعداد مقایسه ای مقادیر متوسط ​​در این تصاویر هستند.

2 زمان رمزگشایی با استفاده از آخرین libwebp + ToT Blink در تاریخ 10/08/2013 با استفاده از ابزار معیار محاسبه شد. "زمان رمزگشایی با جستجو" به صورت "رمزگشایی پنج فریم اول، پاک کردن حافظه نهان بافر فریم، رمزگشایی پنج فریم بعدی و غیره" محاسبه می شود.

3 WebM 4 فریم مرجع YUV را با هر فریم (عرض + 96) * (ارتفاع + 96) پیکسل در حافظه نگه می دارد. برای YUV 4:2:0، به 4 بایت در هر 6 پیکسل (یا 3/2 بایت در هر پیکسل) نیاز داریم. بنابراین، این فریم های مرجع 4*3/2*(width+96)*(height+96) بایت حافظه استفاده می کنند. از طرف دیگر WebP برای در دسترس بودن فقط به فریم قبلی (در RGBA) نیاز دارد که 4*width*height بایت حافظه است.

4 رندر WebP متحرک به Google Chrome نسخه 32 و بالاتر نیاز دارد