שאלות נפוצות

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

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

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

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

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

  • תמיכה עם אובדן WebP
    • 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 איבוד נתונים, ללא אובדן נתונים ובגרסת אלפא
    • 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 ומעלה
    • אופרה 19 ומעלה
    • Safari 14 ואילך (iOS 14 ואילך, macOS Big Sur+ )

לעיונך:

איך בודקים אם הדפדפן תומך ב-WebP?

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

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

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

מודרניזר

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.

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

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

באילו מרחבי צבע תומך הפורמט WebP?

בתאימות ל-bitstream VP8, lossy WebP פועל אך ורק עם פורמט תמונה Y'CbCr 4:2:0 של 8 ביט (שנקרא גם 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 תומך בתצוגה מתקדמת או משולבת?

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

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

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

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

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

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

  1. יש לוודא בפלאגין ADT מותקן יחד עם כלי NDK ושנתיב ה-NDK מוגדר בצורה נכונה (Preferences > Android > NDK).
  2. יוצרים פרויקט חדש: קובץ > חדש > פרויקט > פרויקט אפליקציית Android.
  3. שכפול או חילוץ של libwebp לתיקייה בשם jni בפרויקט החדש.
  4. הוספת swig/libwebp_java_wrap.c לרשימה LOCAL_SRC_FILES.
  5. כדי לכלול את הספרייה ב-build, לוחצים לחיצה ימנית על הפרויקט החדש ובוחרים באפשרות Android Tools (כלים ל-Android) > Add Native Support ... (הוספת תמיכה באפליקציות מקוריות).
  6. פותחים את מאפייני הפרויקט ועוברים אל C/C++ Build > Behaviour. צריך להוסיף את 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 לפרויקט ומייבאים את הפונקציות הרצויות. שימו לב אם אתם משתמשים בממשק 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 ביט ובאלפא של ה-GIF.

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

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

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

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

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

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

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

  2. התמיכה ב-WebP היא פחות נפוצה כמו התמיכה ב-GIF, ולמעשה היא כוללת תמיכה כללית.

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

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

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

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

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

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

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


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

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 ואילך