שאלות נפוצות

מה זה WebP? למה כדאי להשתמש בהן?

WebP היא שיטה לדחיסת נתונים מסוג Lossless ו- Lossless שניתן להשתמש בה מגוון של תמונות מצולמות, שקופות וגרפיות שנמצאו באינטרנט. ניתן לכוונן את דרגת הדחיסה של איבוד נתונים, כך שהמשתמש יכול לבחור יחסי גומלין בין גודל הקובץ ואיכות התמונה. WebP בדרך כלל משיג בממוצע 30% יותר דחיסה בהשוואה ל-JPEG ו-JPEG 2000, בלי לאבד את התמונה איכות (ראו מחקר השוואתי).

המטרה העיקרית של פורמט WebP היא ליצור תמונות קטנות שנראות טוב יותר שיכולים לעזור בהאצת האינטרנט.

אילו דפדפני אינטרנט תומכים ב-WebP במקור?

מנהלי אתרים שרוצים לשפר את ביצועי האתרים יכולים ליצור בקלות חלופות WebP שעברו אופטימיזציה לתמונות הנוכחיות שלהם, ולהציג אותן מטורגטים לדפדפנים שתומכים ב-WebP.

  • תמיכה ב-WebP Lossy
    • Google Chrome (מחשב) מגרסה 17 ואילך
    • Google Chrome ל-Android בגרסה 25 ואילך
    • Microsoft Edge בגרסה 18 ואילך
    • Firefox בגרסה 65 ומעלה
    • Opera בגרסה 11.10 ומעלה
    • דפדפן אינטרנט מקורי, Android +4.0 (ICS)
    • Safari 14+ (iOS 14 ואילך, macOS Big Sur+ )
  • WebP Lossless, Lossless & תמיכה בגרסת אלפא
    • Google Chrome (מחשב) בגרסה 23 ואילך
    • Google Chrome ל-Android בגרסה 25 ואילך
    • Microsoft Edge בגרסה 18 ואילך
    • Firefox בגרסה 65 ומעלה
    • Opera בגרסה 12.10 ומעלה
    • דפדפן אינטרנט מקורי, Android 4.2+ (JB-MR1)
    • ירח בהיר בגיל 26 ומעלה
    • Safari 14+ (iOS 14 ואילך, macOS Big Sur+ )
  • תמיכה באנימציה של WebP
    • Google Chrome (מחשב ו-Android) בגרסה 32 ואילך
    • Microsoft Edge בגרסה 18 ואילך
    • Firefox בגרסה 65 ומעלה
    • Opera מגיל 19 ומעלה
    • Safari 14+ (iOS 14 ואילך, macOS Big Sur+ )

ראה גם:

איך אפשר לזהות תמיכה בדפדפן ל-WebP?

כדאי להציג תמונות WebP רק ללקוחות שיכולים להציג אותן כראוי ולחזור לפורמטים מדור קודם ללקוחות שלא יכולים. למזלנו יש כמה שיטות לזיהוי תמיכה ב-WebP, גם בצד הלקוח ובצד השרת. חלק מספקי ה-CDN מציעים זיהוי תמיכה ב-WebP כחלק מהשירות.

משא ומתן לגבי תוכן בצד השרת באמצעות כותרות אישור

לעיתים קרובות לקוחות אינטרנט שולחים אישור כותרת הבקשה, שמציינת אילו פורמטים של תוכן הם מוכנים לקבל בתגובה. אם הדפדפן יציין מראש שהוא "יאשר". בפורמט image/webp, שרת האינטרנט יודע שהוא יכול לשלוח תמונות WebP בבטחה, מה שמפשט מאוד את התהליך משא ומתן על תוכן. מידע נוסף זמין בקישורים הבאים.

Modernizr

Modernizr היא ספריית JavaScript לזיהוי נוח של נכסי HTML5 תמיכה בתכונות CSS3 בדפדפני אינטרנט. חיפוש הנכסים Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha Modernizr.webp.animation.

רכיב <picture> של HTML5

HTML5 תומך ברכיב <picture>, שמאפשר ליצור רשימה של כמה יעדי תמונות חלופיים לפי סדר עדיפות, כך שהלקוח יבקש את התמונה הפוטנציאלית הראשונה שהיא יכולה להציג בצורה נכונה. צפייה הדיון הזה על HTML5 Rocks. הרכיב <picture> הוא נתמך על ידי דפדפנים נוספים כל הזמן.

ב-JavaScript משלכם

שיטת זיהוי נוספת היא לנסות לפענח תמונת 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 מותאמת אישית.

למה Google פרסמה את WebP בקוד פתוח?

אנחנו מאמינים מאוד בחשיבות של מודל הקוד הפתוח. עם WebP ב- בקוד פתוח, כל אחד יכול לעבוד עם הפורמט ולהציע שיפורים. ב- המשוב וההצעות שלכם, אנחנו מאמינים ש-WebP יהיה עוד יותר מועיל בפורמט גרפי לאורך זמן.

איך ממירים קובצי תמונות אישיות ל-WebP?

אפשר להשתמש בכלי שורת הפקודה WebP כדי להמיר קובצי תמונות אישיים לפורמט WebP. פרטים נוספים זמינים במאמר שימוש ב-WebP.

אם יש לכם הרבה תמונות להמרה, תוכלו להשתמש במעטפת של הפלטפורמה. מפשטים את הפעולה. לדוגמה, כדי להמיר את כל קובצי ה-jpeg בתיקייה, אפשר לנסות הבאים:

Windows:

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

Linux / macOS:

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

איך אפשר להעריך את איכות התמונות ב-WebP בעצמי?

נכון לעכשיו, אפשר להציג קובצי WebP על ידי המרתם לפורמט נפוץ שמשתמש בדחיסה ללא אובדן מידע, כמו PNG, ואז מציג את קובצי ה-PNG כל דפדפן או מציג תמונות. כדי לקבל מושג מהיר על איכות ה-WebP, אפשר לבקר גלריה באתר זה להצגת תמונה זו לצד זו והשוואות.

כיצד אוכל לקבל את קוד המקור?

קוד הממיר זמין הקטע 'הורדות' בפרויקט הקוד הפתוח של WebP הדף הזה. הקוד של המפענח הקל והמפרט של VP8 מופעלים אתר WebM. לצפייה הדף RIFF Container (מאגר תגים של RIFF) של מאגר התגים למפרט.

מה הגודל המקסימלי של תמונת WebP?

WebP תואם ל-bitstream עם VP8 ומשתמש ב-14 ביט לרוחב ולגובה. מידות הפיקסלים המקסימליות של תמונת WebP הן 16383 x 16383.

אילו מרחבי צבעים נתמכים בפורמט WebP?

בהתאם ל-bitstream של VP8, ה-lossy WebP פועל רק עם פורמט התמונה 8-bit Y'CbCr 4:2:0 (נקרא בדרך כלל YUV420). צריך לעיין בסעיף 2, "סקירה כללית של הפורמט" של RFC 6386, מדריך לפורמט נתונים ופענוח קוד של VP8 לקבלת פרטים נוספים.

Lossless WebP פועל רק עם פורמט RGBA. לצפייה מפרט WebP Lossless Bitstream

האם תמונת WebP יכולה להיות גדולה יותר מתמונת המקור שלה?

כן, בדרך כלל כאשר ממירים מפורמט איבוד נתונים ל-WebP Lossless או להיפך. הסיבה העיקרית לכך היא ההבדל במרחב הצבעים (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 ל-IWP עם איבוד נתונים, או מקור של PNG לפורמט ללא אובדן מידע ל-WebP אין הרבה הפתעות כאלה לגבי גודל הקבצים.

האם WebP תומך בתצוגה משולבת או משולבת?

ב-WebP אין אפשרות רענון של פענוח Progressive או Interlaced בפורמט JPEG או המשמעות של PNG. סביר להניח שהדבר יגרום ללחץ רב מדי על המעבד (CPU) ועל הזיכרון של לקוח פענוח, מכיוון שכל אירוע רענון כולל מעבר מלא לפריסת הדחיסה.

בממוצע, פענוח של תמונה בפורמט JPEG מקביל לפענוח קוד של baseline פעם אחת 3.

לחלופין, WebP מציע פענוח מצטבר, שבו כל בייטים של ה-bitstream משמשים כדי לנסות ליצור שורה לדוגמה שניתן להציג, בהקדם האפשרי. שתי האפשרויות האלה חוסכות בזיכרון, במעבד (CPU) ובמאמץ מחדש הלקוח ולספק סימנים ויזואליים לגבי סטטוס ההורדה. ההמרות המצטברות שאפשר לפענח Advanced Decoding API.

איך משתמשים בקישורי libwebp Java בפרויקט Android?

WebP כולל תמיכה בקישורי JNI למקודד ולמפענח הפשוטים והממשקים בספרייה swig/.

בניית הספרייה ב-Eclipse:

  1. עליך לוודא שהתקנה הפלאגין של ADT מותקן יחד עם כלי NDK ונתיב ה-NDK שלך מוגדר כראוי (העדפות > Android > NDK).
  2. יוצרים פרויקט חדש: File > חדש > פרויקט > ב-Android פרויקט אפליקציה.
  3. שכפול או לפתוח את הקובץ של libwebp בתיקייה בשם jni בפרויקט החדש.
  4. הוספה של swig/libwebp_java_wrap.c לרשימה LOCAL_SRC_FILES.
  5. לוחצים לחיצה ימנית על הפרויקט החדש ובוחרים באפשרות Android Tools (כלים ל-Android) > הוספה תמיכה מובנית ... כדי לכלול את הספרייה ב-build.

  6. פותחים את מאפייני הפרויקט ועוברים אל C/C++ Build > התנהגות. הוסף ENABLE_SHARED=1 לקטע Build (Incremental build) כדי ליצור libwebp כספרייה משותפת.

    הערה: ההגדרה NDK_TOOLCHAIN_VERSION=4.8 תשתפר באופן כללי ביצועי build של 32 ביט.

  7. מוסיפים את swig/libwebp.jar לתיקיית הפרויקט libs/.

  8. יוצרים את הפרויקט. הפעולה הזו תיצור libs/<target-arch>/libwebp.so.

  9. צריך להשתמש ב-System.loadLibrary("webp") כדי לטעון את הספרייה בזמן הריצה.

שימו לב שאפשר ליצור את הספרייה באופן ידני באמצעות ndk-build Android.mk. במקרה כזה, אפשר לעשות שימוש חוזר בחלק מהשלבים שתוארו למעלה.

איך משתמשים ב-libwebp עם C#?

ניתן לפתח את WebP בתור DLL שמייצא את ממשק ה-API של libwebp. הפונקציות האלה ייובאו ב-C#.

  1. בניית libwebp.dll. הפעולה הזו תגדיר את WEBP_EXTERN באופן תקין כדי לייצא את ה-API למשימות ספציפיות.

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

  2. מוסיפים את הקובץ libwebp.dll לפרויקט ומייבאים את הפונקציות הרצויות. הערה: אם משתמשים simple 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 תומך בצבעי RGB של 24 ביט עם ערוץ אלפא של 8 ביט, בהשוואה צבעי 8 ביט ואלפא של 1 ביט בקובץ GIF.

  2. WebP תומך בדחיסת נתונים מסוג Lossless וגם בדחיסת נתונים ללא אובדן נתונים; למעשה, מודל אחד אנימציה יכולה לשלב פריימים עם אובדן מידע, פריימים ללא אובדן מידע ופריימים ללא אובדן נתונים. תמיכה ב-GIF בלבד דחיסת נתונים ללא אובדן מידע. טכניקות הדחיסה מסוג Lossy של WebP מתאימות מאוד ועד לתמונות מונפשות שנוצרו מסרטונים בעולם האמיתי, המקור של התמונות המונפשות.

  3. WebP דורש פחות בייטים מ-GIF1. קובצי GIF מונפשים שהומרו לקובצי WebP עם אובדן נתונים יקטנו ב-64% יותר, אבל לא יאבדו הגודל של רכיבי ה-WebP קטן ב-19%. העניין הזה חשוב במיוחד ברשתות סלולריות.

  4. ל-WebP נדרש פחות זמן כדי לפענח את התוכן בנוכחות דילוג. לחשבון הבהוב, גלילה או מעבר בין כרטיסיות להסתיר או להציג תמונות, וכתוצאה מכך האנימציות מושהות ואז דילגת קדימה לנקודה אחרת. שימוש מוגזם במעבד (CPU) שמוביל אנימציות הפותחות פריימים יכולות גם לדרוש מהמפענח להריץ קדימה את האנימציה. בתרחישים האלה, ה-WebP מונפש לוקח פי 0.57 פי 0.57 פיענוח הזמן2 כקובץ GIF, והתוצאה היא פחות בעיות בממשק במהלך גלילה והתאוששות מהירה יותר מבעלייות חדות בניצול המעבד. הדבר בגלל שני היתרונות של WebP על פני GIF:

    • תמונות WebP שומרות מטא-נתונים שקובעים אם כל פריים מכיל אלפא, ביטול הצורך לפענח את המסגרת כדי לקבוע זאת. כך אנחנו יכולים להסיק בצורה מדויקת יותר אילו פריימים קודמים תלויה, ובכך מצמצמת את כמות הפענוח המיותרת של פריימים.

    • בדומה למקודד וידאו מודרני, מקודד WebP מוסיף היוריסטיקה תמונות מפתח במרווחי זמן קבועים (רוב מקודדי ה-GIF לא עושים זאת). התכונה הזו משפרת משמעותית את החיפוש באנימציות ארוכות. כדי לסייע הוספת פריימים בלי להגדיל משמעותית את גודל התמונה, WebP מוסיף 'שיטת מיזוג' דגל לכל פריים בנוסף לשיטת ריקון הפריימים שבה משתמש ה-GIF. כך תמונת המפתח משורטטת כאילו כל התמונה נוקתה לצבע הרקע בלי לאלץ את הפריים הקודם בגודל מלא.

החסרונות של WebP עם אנימציה בהשוואה ל-GIF עם אנימציה

  1. בהיעדר דילוג, השימוש ב-WebP בפענוח קו ישר קובץ GIF חשוב יותר מהמעבד (CPU) זמן הפענוח של אובדן תוכן באינטרנט (CSF) צורך פי 2.2 מזמן הפענוח של GIF, ו-WebP ללא אובדן מגיע פי 1.5.

  2. התמיכה ב-WebP לא רחבה כמעט כמו התמיכה ב-GIF, אוניברסליות יעילה.

  3. הוספת תמיכה ב-WebP לדפדפנים מגדילה את טביעת הרגל הפחמנית שטח מתקפה. ב-Blink נדרשות כ-1,500 שורות נוספות של הקוד (כולל ספריית ה-Demux של WebP ותמונת WebP בצד Blink וממפענח). לתשומת ליבך, הבעיה הזו עשויה להצטמצם בעתיד אם WebP ו-WebM חולקים קוד פענוח נפוץ יותר, או אם היכולות נכללות ב-WebM.

למה לא פשוט לתמוך ב-WebM ב-<img>?

לטווח ארוך, אולי כדאי לתמוך בפורמטים של סרטונים ב<img> התיוג. עם זאת, לעשות זאת עכשיו, מתוך כוונה ש-WebM ב-<img> יכול למלא התפקיד המוצע של WebP מונפש, הוא בעייתי:

  1. בעת פענוח פריים שמסתמך על פריימים קודמים, WebM מחייב 50% יותר זיכרון מאשר WebP מונפש, כדי לשמור את המספר המינימלי של הפריימים הקודמים3.

  2. התמיכה בקודק וידאו ובקונטיינרים משתנה במידה רבה בדפדפנים שונים, מכשירים. כדי להקל על המרת קידוד של תוכן (למשל, שרתי proxy לחיסכון ברוחב פס), הדפדפנים יצטרכו להוסיף כותרות שקיבלו שמציין באילו פורמטים תגי התמונה שלהם תומכים. אפילו יכול להיות לא מספיק, כי סוגי MIME כמו "video/webm" או 'video/mpeg' סטילס לא לציין את התמיכה בקודק (למשל VP8 לעומת VP9). בצד השני באופן כללי, פורמט WebP קפוא למעשה, ואם ספקים שמבצעים משלוחים הוא מסכים לשלוח את ה-WebP מונפש, ההתנהגות של WebP בכל נכסי UA צריכים להיות עקביים, ומכיוון שה-"image/webp" כותרת האישור היא כבר נעשה שימוש כדי לציין תמיכה ב-WebP. אין אישור שינויים חדשים בכותרות נדרשים.

  3. מקבץ הסרטונים של Chromium מותאם במיוחד בשביל הפעלה חלקה, בהנחה שיש רק סרטון אחד או שניים שמופעלים בזמן האימון. כתוצאה מכך, ההטמעה מתבצעת בצורה אגרסיבית בזמן צריכת המערכת (שרשורים, זיכרון וכו') כדי למקסם את איכות ההפעלה. כזו לא מתרחב בצורה טובה להרבה סרטונים בו-זמנית, צריכים לעצב מחדש כך שיתאים לשימוש עם דפי אינטרנט עם הרבה תמונות.

  4. WebM לא משלב כרגע את כל טכניקות הדחיסה מ-WebP. כתוצאה מכך, התמונה הזו דחיסת נתונים טובה יותר עם WebP בהשוואה לחלופות הבאות:

1 בכל ההשוואות בין GIF מונפש לבין WebP מונפש, אנחנו: אוסף של כ-7,000 תמונות GIF מונפשות שצולמו בצורה אקראית מהאינטרנט. התמונות האלה הומרו לאנימציה WebP באמצעות קובץ 'gif2webp' שבכלי את הגדרות ברירת המחדל (שנוצרו עץ המקור של libwebp נכון ל-8/10/2013). המספרים ההשוואה הם הערכים הממוצעים של תמונות.

2 החישובים של זמני הפענוח חושבו באמצעות הקובץ ToT + ה-libwebp האחרונים. מצמוץ נכון ל-08/10/2013 באמצעות כלי השוואה לשוק. "זמן פענוח עם דילוג" מחושב כ"פענוח של חמשת הפריימים הראשונים, ניקוי המסגרת מאגר אחסון זמני, פענוח של חמש הפריימים הבאים וכו'".

3 WebM שומר בזיכרון 4 פריימים של הפניות YUV, בכל פריים. אחסון (width+96)*(height+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 ואילך