مقدمه
WebP یک فرمت تصویری است که از (i) از رمزگذاری قاب کلید VP8 برای فشردهسازی دادههای تصویر به روشی با اتلاف استفاده میکند یا (ii) از رمزگذاری بدون اتلاف WebP استفاده میکند. این طرحهای رمزگذاری باید آن را نسبت به فرمتهای قدیمیتر مانند JPEG، GIF و PNG کارآمدتر کنند. برای انتقال سریع تصویر از طریق شبکه (به عنوان مثال برای وب سایت ها) بهینه شده است. فرمت WebP دارای برابری ویژگی (نمایه رنگ، ابرداده، انیمیشن و غیره) با فرمت های دیگر نیز می باشد. این سند ساختار یک فایل WebP را شرح می دهد.
ظرف WebP (یعنی محفظه RIFF برای WebP) امکان پشتیبانی از ویژگی را بیش از موارد استفاده اصلی WebP (یعنی یک فایل حاوی یک تصویر واحد که به عنوان یک قاب کلید VP8 رمزگذاری شده است) را فراهم می کند. کانتینر WebP پشتیبانی اضافی برای موارد زیر فراهم می کند:
فشرده سازی بدون اتلاف: یک تصویر را می توان با استفاده از قالب WebP Lossless فشرده سازی کرد.
فراداده: یک تصویر ممکن است دارای ابرداده در قالب فایل تصویری تبادلی (Exif) یا بستر فراداده قابل توسعه (XMP) باشد.
شفافیت: یک تصویر ممکن است شفافیت داشته باشد، یعنی یک کانال آلفا.
نمایه رنگی: یک تصویر ممکن است دارای نمایه ICC جاسازی شده باشد که توسط کنسرسیوم رنگ بین المللی توضیح داده شده است.
انیمیشن: یک تصویر ممکن است چندین فریم با مکث بین آنها داشته باشد که آن را تبدیل به یک انیمیشن کند.
نامگذاری
استفاده از انواع زیر هنگام مراجعه به کانتینر WebP توصیه می شود:
نام قالب کانتینر | وب پی |
پسوند نام فایل | .webp |
نوع MIME | تصویر/وب |
شناسه نوع یکنواخت | org.webmproject.webp |
اصطلاحات و مبانی
کلمات کلیدی "باید"، "نباید"، "الزامی"، "باید"، "نباید"، "باید"، "نباید"، "توصیه شده"، "توصیه نمی شود"، "ممکن است"، و "اختیاری" "در این سند باید همانطور که در BCP 14 RFC 2119 RFC 8174 توضیح داده شده است، زمانی که و تنها زمانی که با تمام حروف بزرگ ظاهر می شوند، همانطور که در اینجا نشان داده شده است، تفسیر شود.
یک فایل WebP یا یک تصویر ثابت (یعنی یک ماتریس کدگذاری شده از پیکسل ها) یا یک انیمیشن است. به صورت اختیاری، همچنین می تواند حاوی اطلاعات شفافیت، نمایه رنگ و ابرداده باشد. ما به ماتریس پیکسل ها به عنوان بوم تصویر اشاره می کنیم.
همانطور که در RFC 1166 توضیح داده شده است، شماره گذاری بیت در نمودارهای تکه ای برای مهم ترین بیت ('MSB 0') از 0
شروع می شود.
در زیر اصطلاحات اضافی مورد استفاده در این سند آمده است:
- خواننده/نویسنده
- کدی که فایل های WebP را می خواند خواننده خوانده می شود در حالی که کدی که آنها را می نویسد رایتر می گ��یند.
- uint16
- یک عدد صحیح بدون علامت 16 بیتی اندین کوچک.
- uint24
- یک عدد صحیح 24 بیتی کم اندین و بدون علامت.
- uint32
- یک عدد صحیح بدون علامت 32 بیتی، کمی اندین.
- FourCC
- یک کد چهار کاراکتری (FourCC) یک uint32 است که با به هم پیوستن چهار کاراکتر ASCII به ترتیب اندکی ساخته شده است. این به این معنی است که "aaaa" (0x61616161) و "AAAA" (0x41414141) به عنوان FourCC های مختلف در نظر گرفته می شوند.
- 1 مبتنی بر
- یک فیلد صحیح بدون علامت که مقادیر را با
-1
ذخیره می کند، برای مثال، چنین فیلدی مقدار 25 را به صورت 24 ذخیره می کند. - ChunkHeader ("ABCD")
- برای توصیف هدر FourCC و اندازه قطعه تک تک تکهها استفاده میشود، که در آن 'ABCD' FourCC برای تکه است. اندازه این عنصر 8 بایت است.
فرمت فایل RIFF
فرمت فایل WebP بر اساس فرمت سند RIFF (فرمت فایل تبادل منابع) است.
عنصر اصلی یک فایل RIFF یک قطعه است. متشکل از:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk FourCC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Chunk Payload :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Chunk FourCC: 32 بیت
- کد چهار کاراکتری اسکی برای شناسایی تکه ها استفاده می شود.
- اندازه قطعه: 32 بیت ( uint32 )
- اندازه تکه بر حسب بایت، بدون احتساب این فیلد، شناسه قطعه، یا بالشتک.
- چانک پیلود: اندازه تکه بایت
- محموله داده اگر اندازه قطعه فرد باشد، یک بایت padding - که برای مطابقت با RIFF باید
0
باشد - اضافه می شود.
توجه : RIFF دارای قراردادی است که FourCC های تمام حروف بزرگ، تکه های استانداردی هستند که برای هر فرمت فایل RIFF اعمال می شوند، در حالی که FourCC های خاص یک فرمت فایل، همه با حروف کوچک هستند. WebP از این قرارداد پیروی نمی کند.
سربرگ فایل WebP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'R' | 'I' | 'F' | 'F' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'W' | 'E' | 'B' | 'P' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- 'RIFF': 32 بیت
- کاراکترهای ASCII 'R'، 'I'، 'F'، 'F'.
- حجم فایل: 32 بیت ( uint32 )
- حجم فایل بر حسب بایت، از افست 8 شروع می شود. حداکثر مقدار این فیلد 2^32 منهای 10 بایت است و بنابراین حجم کل فایل حداکثر 4 گیگابایت منهای 2 بایت است.
- 'WEBP': 32 بیت
- کاراکترهای ASCII 'W'، 'E'، 'B'، 'P'.
یک فایل WebP باید با هدر RIFF با "WEBP" FourCC شروع شود. اندازه فایل در هدر اندازه کل تکه هایی است که به اضافه 4
بایت برای FourCC 'WEBP' دنبال می شود. فایل نباید بعد از داده های مشخص شده توسط اندازه فایل حاوی داده ای باشد. خوانندگان ممکن است چنین فایلهایی را تجزیه کنند و دادههای آخر را نادیده بگیرند. از آنجایی که اندازه هر قطعه یکنواخت است، اندازه ارائه شده توسط هدر RIFF نیز یکنواخت است. محتویات تک تک تکه ها در بخش های زیر توضیح داده شده است.
فرمت فایل ساده (از دست رفته)
اگر تصویر نیاز به رمزگذاری با اتلاف دارد و نیازی به شفافیت یا سایر ویژگی های پیشرفته ارائه شده توسط فرمت توسعه یافته ندارد، این طرح بندی باید استفاده شود. فایل هایی با این طرح بندی کوچکتر هستند و توسط نرم افزارهای قدیمی پشتیبانی می شوند.
فرمت فایل WebP ساده (از دست دادن):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| WebP file header (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 'VP8 ' Chunk :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
قطعه 'VP8':
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('VP8 ') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: VP8 data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- داده VP8: بایت اندازه قطعه
- داده های جریان بیت VP8.
توجه داشته باشید که کاراکتر چهارم در "VP8" FourCC یک فضای ASCII (0x20) است.
مشخصات فرمت جریان بیت VP8 در راهنمای فرمت و رمزگشایی داده VP8 توضیح داده شده است. توجه داشته باشید که هدر فریم VP8 شامل عرض و ارتفاع فریم VP8 است. این عرض و ارتفاع بوم در نظر گرفته شده است.
مشخصات VP8 نحوه رمزگشایی تصویر به فرمت Y'CbCr را شرح می دهد. برای تبدیل به RGB، توصیه BT.601 باید استفاده شود. ممکن است برنامه ها از روش تبدیل دیگری استفاده کنند، اما نتایج بصری ممکن است در بین رمزگشاها متفاوت باشد.
فرمت فایل ساده (بدون از دست دادن)
توجه : خوانندگان قدیمی ممکن است فایل هایی را با استفاده از قالب بدون اتلاف پشتیبانی نکنند.
اگر تصویر نیاز به رمزگذاری بدون اتلاف (با یک کانال شفافیت اختیاری) داشته باشد و نیازی به ویژگی های پیشرفته ارائه شده توسط فرمت توسعه یافته نباشد، این طرح بندی باید استفاده شود.
فرمت فایل WebP ساده (بدون ضرر):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| WebP file header (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 'VP8L' Chunk :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
قطعه 'VP8L':
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('VP8L') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: VP8L data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- داده VP8L: بایت اندازه قطعه
- داده های جریان بیت VP8L.
مشخصات فعلی بیت استریم VP8L را می توان در قالب WebP Lossless Bitstream پیدا کرد. توجه داشته باشید که هدر VP8L شامل عرض و ارتفاع تصویر VP8L است. این عرض و ارتفاع بوم در نظر گرفته شده است.
فرمت فایل توسعه یافته
توجه : خوانندگان قدیمیتر ممکن است فایلها را با فرمت توسعهیافته پشتیبانی نکنند.
یک فایل با فرمت توسعه یافته شامل موارد زیر است:
یک قطعه 'VP8X' با اطلاعاتی درباره ویژگی های استفاده شده در فایل.
یک قطعه اختیاری 'ICCP' با نمایه رنگی.
یک قطعه اختیاری 'ANIM' با داده های کنترل انیمیشن.
داده های تصویری
یک قطعه اختیاری 'EXIF' با فراداده Exif.
یک قطعه اختیاری 'XMP' با فراداده XMP.
یک لیست اختیاری از تکه های ناشناخته .
برای یک تصویر ثابت ، داده های تصویر از یک فریم تشکیل شده است که از موارد زیر تشکیل شده است:
یک زیربخش آلفا اختیاری.
یک بخش فرعی بیت استریم .
برای یک تصویر متحرک ، داده های تصویر از چندین فریم تشکیل شده است. جزئیات بیشتر در مورد فریم ها را می توانید در بخش انیمیشن بیابید.
تمام قطعات لازم برای بازسازی و تصحیح رنگ، یعنی 'VP8X'، 'ICCP'، 'ANIM'، 'ANMF'، 'ALPH'، 'VP8' و 'VP8L'، باید به ترتیبی که قبلا توضیح داده شد ظاهر شوند. خوانندگان باید زمانی که قطعات لازم برای بازسازی و تصحیح رنگ از کار افتاده باشند، از کار بیفتند.
ممکن است متادیتا و تکههای ناشناخته خارج از نظم ظاهر شوند.
دلیل: تکههای لازم برای بازسازی باید ابتدا در فایل ظاهر شوند تا به خواننده اجازه دهند تا رمزگشایی یک تصویر را قبل از دریافت همه دادهها آغاز کند. یک برنامه کاربردی ممکن است از تغییر ترتیب ابرداده ها و تکه های سفارشی متناسب با پیاده سازی بهره مند شود.
هدر فایل WebP توسعه یافته:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| WebP file header (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('VP8X') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rsv|I|L|E|X|A|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Canvas Width Minus One | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Canvas Height Minus One |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- رزرو شده (Rsv): 2 بیت
- باید
0
باشد. خوانندگان باید این زمینه را نادیده بگیرند. - نمایه ICC (I): 1 بیت
- تنظیم کنید که فایل حاوی یک قطعه 'ICCP' باشد.
- آلفا (L): 1 بیت
- اگر هر یک از فریم های تصویر حاوی اطلاعات شفافیت ("آلفا") باشد، تنظیم کنید.
- فراداده Exif (E): 1 بیت
- تنظیم کنید که فایل حاوی فراداده Exif باشد.
- فراداده XMP (X): 1 بیت
- تنظیم کنید که فایل حاوی فراداده XMP باشد.
- انیمیشن (A): 1 بیت
- اگر این یک تصویر متحرک است، تنظیم کنید. داده های موجود در تکه های "ANIM" و "ANMF" باید برای کنترل انیمیشن استفاده شوند.
- رزرو شده (R): 1 بیت
- باید
0
باشد. خوانندگان باید این زمینه را نادیده بگیرند. - رزرو شده: 24 بیت
- باید
0
باشد. خوانندگان باید این زمینه را نادیده بگیرند. - عرض بوم منهای یک: 24 بیت
- عرض بوم بر اساس 1 بر حسب پیکسل. عرض بوم واقعی
1 + Canvas Width Minus One
است. - ارتفاع بوم منهای یک: 24 بیت
- ارتفاع بوم بر اساس 1 بر حسب پیکسل. ارتفاع واقعی بوم
1 + Canvas Height Minus One
است.
حاصل ضرب عرض بوم و ارتفاع بوم باید حداکثر 2^32 - 1
باشد.
مشخصات آینده ممکن است فیلدهای بیشتری اضافه کند. فیلدهای ناشناخته باید نادیده گرفته شوند.
انیمیشن
یک انیمیشن توسط قطعات "ANIM" و "ANMF" کنترل می شود.
قطعه "ANIM":
برای یک تصویر متحرک، این قطعه شامل پارامترهای کلی انیمیشن است.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('ANIM') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Background Color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- رنگ پس زمینه: 32 بیت ( uint32 )
- رنگ پسزمینه پیشفرض بوم به ترتیب بایت [آبی، سبز، قرمز، آلفا]. ممکن است از این رنگ برای پر کردن فضای استفاده نشده روی بوم اطراف قاب ها و همچنین پیکسل های شفاف فریم اول استفاده شود. رنگ پس زمینه نیز زمانی استفاده می شود که روش Disposal
1
باشد.
یادداشت ها :
رنگ پسزمینه ممکن است حاوی یک مقدار آلفای غیر شفاف باشد، حتی اگر پرچم آلفا در قطعه «VP8X» تنظیم نشده باشد.
برنامه های نمایشگر باید مقدار رنگ پس زمینه را به عنوان یک اشاره در نظر بگیرند و نیازی به استفاده از آن ندارند.
بوم در شروع هر حلقه پاک می شود. ممکن است از رنگ پس زمینه برای رسیدن به این هدف استفاده شود.
- تعداد حلقه: 16 بیت ( uint16 )
- تعداد دفعات حلقه زدن انیمیشن. اگر
0
باشد، این به معنای بی نهایت است.
اگر پرچم انیمیشن در قسمت 'VP8X' تنظیم شده باشد، این قطعه باید ظاهر شود. اگر پرچم انیمیشن تنظیم نشده باشد و این قطعه وجود داشته باشد، باید نادیده گرفته شود.
قطعه 'ANMF':
برای تصاویر متحرک، این قطعه حاوی اطلاعاتی در مورد یک فریم است. اگر پرچم انیمیشن تنظیم نشده باشد، این قطعه نباید وجود داشته باشد.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('ANMF') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame X | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Frame Y | Frame Width Minus One ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Frame Height Minus One |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Duration | Reserved |B|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Frame Data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- فریم X: 24 بی�� ( uint24 )
- مختصات X گوشه سمت چپ بالای قاب
Frame X * 2
است. - فریم Y: 24 بیت ( uint24 )
- مختصات Y گوشه سمت چپ بالای کادر
Frame Y * 2
است. - عرض فریم منهای یک: 24 بیت ( uint24 )
- عرض قاب بر اساس 1 . عرض فریم
1 + Frame Width Minus One
است. - ارتفاع فریم منهای یک: 24 بیت ( uint24 )
- ارتفاع قاب بر اساس 1 . ارتفاع فریم
1 + Frame Height Minus One
است. - مدت زمان فریم: 24 بیت ( uint24 )
- زمان انتظار قبل از نمایش فریم بعدی، در واحدهای 1 میلی ثانیه ای. توجه داشته باشید که تفسیر مدت زمان فریم 0 (و اغلب <= 10) توسط پیاده سازی تعریف می شود. بسیاری از ابزارها و مرورگرها حداقل مدت زمان مشابه GIF را اختصاص می دهند.
- رزرو شده: 6 بیت
- باید
0
باشد. خوانندگان باید این زمینه را نادیده بگیرند. - روش ترکیب (B): 1 بیت
نشان می دهد که چگونه پیکسل های شفاف قاب فعلی باید با پیکسل های متناظر بوم قبلی ترکیب شوند:
0
: از ترکیب آلفا استفاده کنید. پس از دور انداختن فریم قبلی، فریم فعلی را با استفاده از ترکیب آلفا روی بوم رندر کنید (به زیر مراجعه کنید). اگر فریم فعلی کانال آلفا ندارد، مقدار آلفا را 255 فرض کنید که عملاً جایگزین مستطیل می شود.1
: مخلوط نکنید. پس از دور انداختن فریم قبلی، با بازنویسی مستطیل تحت پوشش قاب فعلی، قاب فعلی را روی بوم رندر کنید.
- روش دفع (D): 1 بیت
نشان می دهد که پس از نمایش قاب فعلی (قبل از رندر کردن فریم بعدی) روی بوم چگونه باید با آن برخورد کرد:
0
: دور نریزید. بوم را همانطور که هست بگذارید.1
: به رنگ پس زمینه بیاندازید. مستطیل روی بوم پوشیده شده توسط قاب فعلی را با رنگ پس زمینه مشخص شده در قطعه «ANIM» پر کنید.
یادداشت ها :
حذف فریم فقط برای مستطیل قاب اعمال میشود، یعنی مستطیلی که توسط فریم X ، فریم Y ، عرض قاب و ارتفاع قاب تعریف شده است. ممکن است کل بوم را بپوشاند یا نه.
ترکیب آلفا:
با توجه به اینکه هر یک از کانالهای R، G، B و A 8 بیتی هستند و کانالهای RGB در آلفا ��رب نشدهاند ، فرمول ترکیب «dst» با «src» به این صورت است:
blend.A = src.A + dst.A * (1 - src.A / 255) if blend.A = 0 then blend.RGB = 0 else blend.RGB = (src.RGB * src.A + dst.RGB * dst.A * (1 - src.A / 255)) / blend.A
ترکیب آلفا باید در فضای رنگی خطی و با در نظر گرفتن نمایه رنگ تصویر انجام شود. اگر نمایه رنگ وجود نداشته باشد، RGB استاندارد (sRGB) باید در نظر گرفته شود. (توجه داشته باشید که sRGB نیز به دلیل گامای ~2.2 باید خطی شود.)
- داده فریم: بایت اندازه تکه -
16
متشکل از:
یک زیربخش آلفا اختیاری برای قاب.
یک خرده جریان بیت برای قاب.
یک لیست اختیاری از تکه های ناشناخته .
توجه : محموله «ANMF»، Frame Data ، از تکههای خالی تشکیل شده است، همانطور که با فرمت فایل RIFF توضیح داده شده است.
آلفا
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('ALPH') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rsv| P | F | C | Alpha Bitstream... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- رزرو شده (Rsv): 2 بیت
- باید
0
باشد. خوانندگان باید این زمینه را نادیده بگیرند. - پیش پردازش (P): 2 بیت
این بیت های اطلاعاتی برای سیگنال دادن به پیش پردازشی که در طول فشرده سازی انجام شده است استفاده می شود. رمزگشا می تواند از این اطلاعات برای مثال برای تغییر دادن مقادیر یا صاف کردن گرادیان ها قبل از نمایش استفاده کند.
-
0
: بدون پیش پردازش. -
1
: کاهش سطح
-
رسیورها نیازی به استفاده از این اطلاعات به هیچ روش مشخصی ندارند.
- روش فیلتر (F): 2 بیت
روش های فیلتر مورد استفاده به شرح زیر است:
-
0
: هیچکدام. -
1
: فیلتر افقی -
2
: فیلتر عمودی -
3
: فیلتر گرادیان.
-
برای هر پیکسل، فیلتر کردن با استفاده از محاسبات زیر انجام می شود. فرض کنید مقادیر آلفای اطراف موقعیت X
فعلی به صورت زیر برچسب گذاری شده اند:
C | B |
---+---+
A | X |
ما به دنبال محاسبه مقدار آلفا در موقعیت X
هستیم. ابتدا بسته به روش فیلتر کردن، پیش بینی انجام می شود:
- روش
0
: پیش بینی کننده = 0 - روش
1
: پیش بینی = A - روش
2
: پیش بینی کننده = B - روش
3
: پیش بینی کننده = کلیپ (A + B - C)
که در آن clip(v)
برابر است با:
- 0 اگر v < 0،
- 255 اگر v> 255، یا
- v در غیر این صورت
مقدار نهایی با افزودن مقدار غیرفشرده X
به پیش بینی کننده و با استفاده از محاسبات مدولو-256 برای قرار دادن محدوده [256..511] در [0..255] به دست می آید:
alpha = (predictor + X) % 256
موارد خاصی برای سمت چپ ترین و بالاترین موقعیت پیکسل وجود دارد. به عنوان مثال، مقدار بالا سمت چپ در مکان (0، 0) از 0 به عنوان مقدار پیش بینی کننده استفاده می کند. در غیر این صورت:
- برای روش های فیلتر افقی یا گرادیان، سمت چپ ترین پیکسل ها در مکان (0، y) با استفاده از مکان (0، y-1) درست در بالا پیش بینی می شوند.
- برای روشهای فیلتر عمودی یا گرادیان، بالاترین پیکسلها در مکان (x، 0) با استفاده از مکان (x-1، 0) در سمت چپ پیشبینی میشوند.
- روش فشرده سازی (C): 2 بیت
روش فشرده سازی مورد استفاده:
-
0
: بدون فشرده سازی. -
1
: با استفاده از فرمت WebP فشرده شده است.
-
- جریان بیت آلفا: بایت اندازه تکه -
1
جریان بیت آلفا رمزگذاری شده
این قطعه اختیاری حاوی داده های آلفای کدگذاری شده برای این فریم است. قاب حاوی یک قطعه 'VP8L' نباید حاوی این قطعه باشد.
دلیل : اطلاعات شفافیت در حال حاضر بخشی از قطعه "VP8L" است.
دادههای کانال آلفا بهعنوان دادههای خام فشردهنشده ذخیره میشوند (زمانی که روش فشردهسازی '0' است) یا با استفاده از قالب بدون تلفات فشرده میشود (زمانی که روش فشردهسازی '1' است).
داده خام: این شامل یک توالی بایت طول = عرض * ارتفاع است که شامل تمام مقادیر شفافیت 8 بیتی به ترتیب اسکن است.
فشرده سازی قالب بدون اتلاف: دنباله بایت یک جریان تصویر فشرده شده است (همانطور که در "WebP Lossless Bitstream Format" توضیح داده شده است) با ابعاد ضمنی عرض x ارتفاع. یعنی این جریان تصویر حاوی هیچ عنوانی نیست که ابعاد تصویر را توصیف کند.
دلیل : ابعاد قبلاً از منابع دیگر شناخته شده است، بنابراین ذخیره مجدد آنها اضافی و مستعد خطا است.
هنگامی که جریان تصویر به مقادیر رنگ آلفا، قرمز، سبز، آبی (ARGB) رمزگشایی شد، به دنبال فرآیندی که در مشخصات فرمت بدون اتلاف توضیح داده شده است، اطلاعات شفافیت باید از کانال سبز چهارگانه ARGB استخراج شود.
دلیل : کانال سبز دارای مراحل تبدیل اضافی در مشخصات است - بر خلاف کانال های دیگر - که می تواند فشرده سازی را بهبود بخشد.
بیت استریم (VP8/VP8L)
این قطعه حاوی داده های جریان بیت فشرده برای یک فریم است.
یک قطعه بیت استریم ممکن است (i) یک قطعه «VP8» باشد که از «VP8» (به فضای مهم نویسه چهارم توجه کنید) به عنوان FourCC خود، یا (ii) یک قطعه «VP8L» با استفاده از «VP8L» به عنوان FourCC آن باشد.
قالبهای «VP8» و «VP8L» به ترتیب در بخشهای Simple File Format (Lossy) و Simple File Format (Lossless) توضیح داده شده است.
نمایه رنگی
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('ICCP') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Color Profile :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- نمایه رنگ: اندازه تکه بایت
- نمایه ICC
این قطعه باید قبل از داده های تصویر ظاهر شود.
حداکثر باید یک چنین تکه ای وجود داشته باشد. اگر چنین تکههای بیشتری وجود داشته باشد، خوانندگان ممکن است همه را به جز مورد اول نادیده بگیرند. برای جزئیات به مشخصات ICC مراجعه کنید.
اگر این قطعه وجود نداشته باشد، sRGB باید فرض شود.
فراداده
متادیتا را می توان در قطعات "EXIF" یا "XMP" ذخیره کرد.
باید حداکثر یک تکه از هر نوع ("EXIF" و "XMP") وجود داشته باشد. اگر چنین تکههای بیشتری وجود داشته باشد، خوانندگان ممکن است همه را به جز مورد اول نادیده بگیرند.
تکه ها به صورت زیر تعریف می شوند:
قطعه 'EXIF':
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('EXIF') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Exif Metadata :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Exif Metadata: بایت اندازه قطعه
- فراداده تصویر در فرمت Exif.
قطعه 'XMP':
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('XMP ') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: XMP Metadata :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- فراداده XMP: بایت اندازه قطعه
- فراداده تصویر در فرمت XMP.
توجه داشته باشید که کاراکتر چهارم در "XMP" FourCC یک فضای ASCII (0x20) است.
راهنماییهای اضافی درباره مدیریت فراداده را میتوان در «راهنمای مدیریت فراداده» گروه کاری فراداده یافت.
تکه های ناشناخته
یک قطعه RIFF (شرح شده در بخش RIFF File Format ) که FourCC آن با هر یک از تکههای توضیح داده شده در این سند متفاوت است، یک قطعه ناشناخته در نظر گرفته میشود.
منطق : اجازه دادن به قطعات ناشناخته، تمهیداتی را برای گسترش قالب در آینده فراهم می کند و همچنین امکان ذخیره هر گونه داده خاص برنامه را فراهم می کند.
یک فایل ممکن است حاوی تکه های ناشناخته باشد:
- در انتهای فایل، همانطور که در بخش هدر فایل Extended WebP توضیح داده شده است، یا
- در انتهای قطعات 'ANMF' همانطور که در بخش انیمیشن توضیح داده شده است.
خوانندگان باید این تکه ها را نادیده بگیرند. نویسندگان باید آنها را به ترتیب اصلی خود حفظ کنند (مگر اینکه به طور خاص قصد اصلاح این تکه ها را داشته باشند).
مونتاژ بوم از فریم
در اینجا ما یک نمای کلی از اینکه چگونه یک خواننده باید یک بوم را در مورد یک تصویر متحرک جمع کند، ارائه می دهیم.
این فرآیند با ایجاد یک بوم با استفاده از ابعاد داده شده در قطعه 'VP8X'، Canvas Width Minus One + 1
پیکسل توسط Canvas Height Minus One + 1
پیکسل آغاز می شود. فیلد Loop Count
از قسمت 'ANIM' تعداد دفعات تکرار فرآیند انیمیشن را کنترل می کند. این Loop Count - 1
برای مقادیر Loop Count
غیر صفر یا بی نهایت است اگر Loop Count
صفر باشد.
در ابتدای هر تکرار حلقه، بوم با استفاده از رنگ پسزمینه از قطعه «ANIM» یا یک رنگ تعریفشده توسط برنامه پر میشود.
تکه های 'ANMF' حاوی فریم های جداگانه ای هستند که به ترتیب نمایش داده می شوند. قبل از رندر کردن هر فریم، Disposal method
قاب قبلی اعمال می شود.
رندر قاب رمزگشایی شده از مختصات دکارتی ( 2 * Frame X
، 2 * Frame Y
) شروع می شود، با استفاده از گوشه سمت چپ بالای بوم به عنوان مبدا. Frame Width Minus One + 1
پیکسل عرض با Frame Height Minus One + 1
پیکسل با استفاده از Blending method
بر روی بوم نمایش داده می شود.
بوم برای Frame Duration
میلی ثانیه نمایش داده می شود. این کار تا زمانی ادامه می یابد که تمام فریم های داده شده توسط قطعات 'ANMF' نمایش داده شوند. سپس یک تکرار حلقه جدید شروع می شود، یا اگر تمام تکرارها کامل شده باشند، بوم در حالت نهایی خود باقی می ماند.
شبه کد زیر روند رندر را نشان می دهد. علامت VP8X.field به معنای فیلدی در قسمت 'VP8X' با همان توضیحات است.
VP8X.flags.hasAnimation MUST be TRUE
canvas ← new image of size VP8X.canvasWidth x VP8X.canvasHeight with
background color ANIM.background_color or
application-defined color.
loop_count ← ANIM.loopCount
dispose_method ← Dispose to background color
if loop_count == 0:
loop_count = ∞
frame_params ← nil
next chunk in image_data is ANMF MUST be TRUE
for loop = 0..loop_count - 1
clear canvas to ANIM.background_color or application-defined color
until eof or non-ANMF chunk
frame_params.frameX = Frame X
frame_params.frameY = Frame Y
frame_params.frameWidth = Frame Width Minus One + 1
frame_params.frameHeight = Frame Height Minus One + 1
frame_params.frameDuration = Frame Duration
frame_right = frame_params.frameX + frame_params.frameWidth
frame_bottom = frame_params.frameY + frame_params.frameHeight
VP8X.canvasWidth >= frame_right MUST be TRUE
VP8X.canvasHeight >= frame_bottom MUST be TRUE
for subchunk in 'Frame Data':
if subchunk.tag == "ALPH":
alpha subchunks not found in 'Frame Data' earlier MUST be
TRUE
frame_params.alpha = alpha_data
else if subchunk.tag == "VP8 " OR subchunk.tag == "VP8L":
bitstream subchunks not found in 'Frame Data' earlier MUST
be TRUE
frame_params.bitstream = bitstream_data
apply dispose_method.
render frame with frame_params.alpha and frame_params.bitstream
on canvas with top-left corner at (frame_params.frameX,
frame_params.frameY), using Blending method
frame_params.blendingMethod.
canvas contains the decoded image.
Show the contents of the canvas for
frame_params.frameDuration * 1 ms.
dispose_method = frame_params.disposeMethod
نمونهای از طرحبندی فایل
یک تصویر رمزگذاری شده با اتلاف با آلفا ممکن است به شکل زیر باشد:
RIFF/WEBP
+- VP8X (descriptions of features used)
+- ALPH (alpha bitstream)
+- VP8 (bitstream)
یک تصویر رمزگذاری شده بدون تلفات ممکن است به صورت زیر باشد:
RIFF/WEBP
+- VP8X (descriptions of features used)
+- VP8L (lossless bitstream)
+- XYZW (unknown chunk)
یک تصویر بدون اتلاف با نمایه ICC و فراداده XMP ممکن است به شکل زیر باشد:
RIFF/WEBP
+- VP8X (descriptions of features used)
+- ICCP (color profile)
+- VP8L (lossless bitstream)
+- XMP (metadata)
یک تصویر متحرک با فراداده Exif ممکن است به شکل زیر باشد:
RIFF/WEBP
+- VP8X (descriptions of features used)
+- ANIM (global animation parameters)
+- ANMF (frame1 parameters + data)
+- ANMF (frame2 parameters + data)
+- ANMF (frame3 parameters + data)
+- ANMF (frame4 parameters + data)
+- EXIF (metadata)
،مقدمه
WebP یک فرمت تصویری است که از (i) از رمزگذاری قاب کلید VP8 برای فشردهسازی دادههای تصویر به روشی با اتلاف استفاده میکند یا (ii) از رمزگذاری بدون اتلاف WebP استفاده میکند. این طرحهای رمزگذاری باید آن را نسبت به فرمتهای قدیمیتر مانند JPEG، GIF و PNG کارآمدتر کنند. برای انتقال سریع تصویر از طریق شبکه (به عنوان مثال برای وب سایت ها) بهینه شده است. فرمت WebP دارای برابری ویژگی (نمایه رنگ، ابرداده، انیمیشن و غیره) با فرمت های دیگر نیز می باشد. این سند ساختار یک فایل WebP را شرح می دهد.
ظرف WebP (یعنی محفظه RIFF برای WebP) امکان پشتیبانی از ویژگی را بیش از موارد استفاده اصلی WebP (یعنی یک فایل حاوی یک تصویر واحد که به عنوان یک قاب کلید VP8 رمزگذاری شده است) را فراهم می کند. کانتینر WebP پشتیبانی اضافی برای موارد زیر فراهم می کند:
فشرده سازی بدون اتلاف: یک تصویر را می توان با استفاده از قالب WebP Lossless فشرده سازی کرد.
فراداده: یک تصویر ممکن است دارای ابرداده در قالب فایل تصویری تبادلی (Exif) یا بستر فراداده قابل توسعه (XMP) باشد.
شفافیت: یک تصویر ممکن است شفافیت داشته باشد، یعنی یک کانال آلفا.
نمایه رنگی: یک تصویر ممکن است دارای نمایه ICC جاسازی شده باشد که توسط کنسرسیوم رنگ بین المللی توضیح داده شده است.
انیمیشن: یک تصویر ممکن است چندین فریم با مکث بین آنها داشته باشد که آن را تبدیل به یک انیمیشن کند.
نامگذاری
استفاده از انواع زیر هنگام مراجعه به کانتینر WebP توصیه می شود:
نام قالب کانتینر | وب پی |
پسوند نام فایل | .webp |
نوع MIME | تصویر/وب |
شناسه نوع یکنواخت | org.webmproject.webp |
اصطلاحات و مبانی
کلمات کلیدی "باید"، "نباید"، "الزامی"، "باید"، "نباید"، "باید"، "نباید"، "توصیه شده"، "توصیه نمی شود"، "ممکن است"، و "اختیاری" "در این سند باید همانطور که در BCP 14 RFC 2119 RFC 8174 توضیح داده شده است، زمانی که و تنها زمانی که با تمام حروف بزرگ ظاهر می شوند، همانطور که در اینجا نشان داده شده است، تفسیر شود.
یک فایل WebP یا یک تصویر ثابت (یعنی یک ماتریس کدگذاری شده از پیکسل ها) یا یک انیمیشن است. به صورت اختیاری، همچنین می تواند حاوی اطلاعات شفافیت، نمایه رنگ و ابرداده باشد. ما به ماتریس پیکسل ها به عنوان بوم تصویر اشاره می کنیم.
همانطور که در RFC 1166 توضیح داده شده است، شماره گذاری بیت در نمودارهای تکه ای برای مهم ترین بیت ('MSB 0') از 0
شروع می شود.
در زیر اصطلاحات اضافی مورد استفاده در این سند آمده است:
- خواننده/نویسنده
- کدی که فایل های WebP را می خواند خواننده خوانده می شود در حالی که کدی که آنها را می نویسد رایتر می گویند.
- uint16
- یک عدد صحیح بدون علامت 16 بیتی اندین کوچک.
- uint24
- یک عدد صحیح 24 بیتی کم اندین و بدون علامت.
- uint32
- یک عدد صحیح بدون علامت 32 بیتی، کمی اندین.
- FourCC
- یک کد چهار کاراکتری (FourCC) یک uint32 است که با به هم پیوستن چهار کاراکتر ASCII به ترتیب اندکی ساخته شده است. این به این معنی است که "aaaa" (0x61616161) و "AAAA" (0x41414141) به عنوان FourCC های مختلف در نظر گرفته می شوند.
- 1 مبتنی بر
- یک فیلد صحیح بدون علامت که مقادیر را با
-1
ذخیره می کند، برای مثال، چنین فیلدی مقدار 25 را به صورت 24 ذخیره می کند. - ChunkHeader ("ABCD")
- برای توصیف هدر FourCC و اندازه قطعه تک تک تکهها استفاده میشود، که در آن 'ABCD' FourCC برای تکه است. اندازه این عنصر 8 بایت است.
فرمت فایل RIFF
فرمت فایل WebP بر اساس فرمت سند RIFF (فرمت فایل تبادل منابع) است.
عنصر اصلی یک فایل RIFF یک قطعه است. متشکل از:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk FourCC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Chunk Payload :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Chunk FourCC: 32 بیت
- کد چهار کاراکتری اسکی برای شناسایی تکه ها استفاده می شود.
- اندازه قطعه: 32 بیت ( uint32 )
- اندازه تکه بر حسب بایت، بدون احتساب این فیلد، شناسه قطعه، یا بالشتک.
- چانک پیلود: اندازه تکه بایت
- محموله داده اگر اندازه قطعه فرد باشد، یک بایت padding - که برای مطابقت با RIFF باید
0
باشد - اضافه می شود.
توجه : RIFF دارای قراردادی است که FourCC های تمام حروف بزرگ، تکه های استانداردی هستند که برای هر فرمت فایل RIFF اعمال می شوند، در حالی که FourCC های خاص یک فرمت فایل، همه با حروف کوچک هستند. WebP از این قرارداد پیروی نمی کند.
سربرگ فایل WebP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'R' | 'I' | 'F' | 'F' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'W' | 'E' | 'B' | 'P' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- 'RIFF': 32 بیت
- کاراکترهای ASCII 'R'، 'I'، 'F'، 'F'.
- حجم فایل: 32 بیت ( uint32 )
- حجم فایل بر حسب بایت، از افست 8 شروع می شود. حداکثر مقدار این فیلد 2^32 منهای 10 بایت است و بنابراین حجم کل فایل حداکثر 4 گیگابایت منهای 2 بایت است.
- 'WEBP': 32 بیت
- کاراکترهای ASCII 'W'، 'E'، 'B'، 'P'.
یک فایل WebP باید با هدر RIFF با "WEBP" FourCC شروع شود. اندازه فایل در هدر اندازه کل تکه هایی است که به اضافه 4
بایت برای FourCC 'WEBP' دنبال می شود. فایل نباید بعد از داده های مشخص شده توسط اندازه فایل حاوی داده ای باشد. خوانندگان ممکن است چنین فایلهایی را تجزیه کنند و دادههای آخر را نادیده بگیرند. از آنجایی که اندازه هر قطعه یکنواخت است، اندازه ارائه شده توسط هدر RIFF نیز یکنواخت است. محتویات تک تک تکه ها در بخش های زیر توضیح داده شده است.
فرمت فایل ساده (از دست رفته)
اگر تصویر نیاز به رمزگذاری با اتلاف دارد و نیازی به شفافیت یا سایر ویژگی های پیشرفته ارائه شده توسط فرمت توسعه یافته ندارد، این طرح بندی باید استفاده شود. فایل هایی با این طرح بندی کوچکتر هستند و توسط نرم افزارهای قدیمی پشتیبانی می شوند.
فرمت فایل WebP ساده (از دست دادن):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| WebP file header (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 'VP8 ' Chunk :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
قطعه 'VP8':
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('VP8 ') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: VP8 data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- داده VP8: بایت اندازه قطعه
- داده های جریان بیت VP8.
توجه داشته باشید که کاراکتر چهارم در "VP8" FourCC یک فضای ASCII (0x20) است.
مشخصات فرمت جریان بیت VP8 در راهنمای فرمت و رمزگشایی داده VP8 توضیح داده شده است. توجه داشته باشید که هدر فریم VP8 شامل عرض و ارتفاع فریم VP8 است. این عرض و ارتفاع بوم در نظر گرفته شده است.
مشخصات VP8 نحوه رمزگشایی تصویر به فرمت Y'CbCr را شرح می دهد. برای تبدیل به RGB، توصیه BT.601 باید استفاده شود. ممکن است برنامه ها از روش تبدیل دیگری استفاده کنند، اما نتایج بصری ممکن است در بین رمزگشاها متفاوت باشد.
فرمت فایل ساده (بدون از دست دادن)
توجه : خوانندگان قدیمی ممکن است فایل هایی را با استفاده از قالب بدون اتلاف پشتیبانی نکنند.
اگر تصویر نیاز به رمزگذاری بدون اتلاف (با یک کانال شفافیت اختیاری) داشته باشد و نیازی به ویژگی های پیشرفته ارائه شده توسط فرمت توسعه یافته نباشد، این طرح بندی باید استفاده شود.
فرمت فایل WebP ساده (بدون ضرر):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| WebP file header (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 'VP8L' Chunk :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
قطعه 'VP8L':
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('VP8L') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: VP8L data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- داده VP8L: بایت اندازه قطعه
- داده های جریان بیت VP8L.
مشخصات فعلی بیت استریم VP8L را می توان در قالب WebP Lossless Bitstream پیدا کرد. توجه داشته باشید که هدر VP8L شامل عرض و ارتفاع تصویر VP8L است. این عرض و ارتفاع بوم در نظر گرفته شده است.
فرمت فایل توسعه یافته
توجه : خوانندگان قدیمیتر ممکن است فایلها را با فرمت توسعهیافته پشتیبانی نکنند.
یک فایل با فرمت توسعه یافته شامل موارد زیر است:
یک قطعه 'VP8X' با اطلاعاتی درباره ویژگی های استفاده شده در فایل.
یک قطعه اختیاری 'ICCP' با نمایه رنگی.
یک قطعه اختیاری 'ANIM' با داده های کنترل انیمیشن.
داده های تصویری
یک قطعه اختیاری 'EXIF' با فراداده Exif.
یک قطعه اختیاری 'XMP' با فراداده XMP.
یک لیست اختیاری از تکه های ناشناخته .
برای یک تصویر ثابت ، داده های تصویر از یک فریم تشکیل شده است که از موارد زیر تشکیل شده است:
یک زیربخش آلفا اختیاری.
یک بخش فرعی بیت استریم .
برای یک تصویر متحرک ، داده های تصویر از چندین فریم تشکیل شده است. جزئیات بیشتر در مورد فریم ها را می توانید در بخش انیمیشن بیابید.
تمام قطعات لازم برای بازسازی و تصحیح رنگ، یعنی 'VP8X'، 'ICCP'، 'ANIM'، 'ANMF'، 'ALPH'، 'VP8' و 'VP8L'، باید به ترتیبی که قبلا توضیح داده شد ظاهر شوند. خوانندگان باید زمانی که قطعات لازم برای بازسازی و تصحیح رنگ از کار افتاده باشند، از کار بیفتند.
ممکن است متادیتا و تکههای ناشناخته خارج از نظم ظاهر شوند.
دلیل: تکههای لازم برای بازسازی باید ابتدا در فایل ظاهر شوند تا به خواننده اجازه دهند تا رمزگشایی یک تصویر را قبل از دریافت همه دادهها آغاز کند. یک برنامه کاربردی ممکن است از تغییر ترتیب ابرداده ها و تکه های سفارشی متناسب با پیاده سازی بهره مند شود.
هدر فایل WebP توسعه یافته:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| WebP file header (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('VP8X') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rsv|I|L|E|X|A|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Canvas Width Minus One | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Canvas Height Minus One |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- رزرو شده (Rsv): 2 بیت
- باید
0
باشد. خوانندگان باید این زمینه را نادیده بگیرند. - نمایه ICC (I): 1 بیت
- تنظیم کنید که فایل حاوی یک قطعه 'ICCP' باشد.
- آلفا (L): 1 بیت
- اگر هر یک از فریم های تصویر حاوی اطلاعات شفافیت ("آلفا") باشد، تنظیم کنید.
- فراداده Exif (E): 1 بیت
- تنظیم کنید که فایل حاوی فراداده Exif باشد.
- فراداده XMP (X): 1 بیت
- تنظیم کنید که فایل حاوی فراداده XMP باشد.
- انیمیشن (A): 1 بیت
- اگر این یک تصویر متحرک است، تنظیم کنید. داده های موجود در تکه های "ANIM" و "ANMF" باید برای کنترل انیمیشن استفاده شوند.
- رزرو شده (R): 1 بیت
- باید
0
باشد. خوانندگان باید این زمینه را نادیده بگیرند. - رزرو شده: 24 بیت
- باید
0
باشد. خوانندگان باید این زمینه را نادیده بگیرند. - عرض بوم منهای یک: 24 بیت
- عرض بوم بر اساس 1 بر حسب پیکسل. عرض بوم واقعی
1 + Canvas Width Minus One
است. - ارتفاع بوم منهای یک: 24 بیت
- ارتفاع بوم بر اساس 1 بر حسب پیکسل. ارتفاع واقعی بوم
1 + Canvas Height Minus One
است.
حاصل ضرب عرض بوم و ارتفاع بوم باید حداکثر 2^32 - 1
باشد.
مشخصات آینده ممکن است فیلدهای بیشتری اضافه کند. فیلدهای ناشناخته باید نادیده گرفته شوند.
انیمیشن
یک انیمیشن توسط قطعات "ANIM" و "ANMF" کنترل می شود.
قطعه "ANIM":
برای یک تصویر متحرک، این قطعه شامل پارامترهای کلی انیمیشن است.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('ANIM') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Background Color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- رنگ پس زمینه: 32 بیت ( uint32 )
- رنگ پسزمینه پیشفرض بوم به ترتیب بایت [آبی، سبز، قرمز، آلفا]. ممکن است از این رنگ برای پر کردن فضای استفاده نشده روی بوم اطراف قاب ها و همچنین پیکسل های شفاف فریم اول استفاده شود. رنگ پس زمینه نیز زمانی استفاده می شود که روش Disposal
1
باشد.
یادداشت ها :
رنگ پسزمینه ممکن است حاوی یک مقدار آلفای غیر شفاف باشد، حتی اگر پرچم آلفا در قطعه «VP8X» تنظیم نشده باشد.
برنامه های نمایشگر باید مقدار رنگ پس زمینه را به عنوان یک اشاره در نظر بگیرند و نیازی به استفاده از آن ندارند.
بوم در شروع هر حلقه پاک می شود. ممکن است از رنگ پس زمینه برای رسیدن به این هدف استفاده شود.
- تعداد حلقه: 16 بیت ( uint16 )
- تعداد دفعات حلقه زدن انیمیشن. اگر
0
باشد، این به معنای بی نهایت است.
اگر پرچم انیمیشن در قسمت 'VP8X' تنظیم شده باشد، این قطعه باید ظاهر شود. اگر پرچم انیمیشن تنظیم نشده باشد و این قطعه وجود داشته باشد، باید نادیده گرفته شود.
قطعه 'ANMF':
برای تصاویر متحرک، این قطعه حاوی اطلاعاتی در مورد یک فریم است. اگر پرچم انیمیشن تنظیم نشده باشد، این قطعه نباید وجود داشته باشد.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('ANMF') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame X | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Frame Y | Frame Width Minus One ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Frame Height Minus One |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Duration | Reserved |B|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Frame Data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- فریم X: 24 بیت ( uint24 )
- مختصات X گوشه سمت چپ بالای قاب
Frame X * 2
است. - فریم Y: 24 بیت ( uint24 )
- مختصات Y گوشه سمت چپ بالای کادر
Frame Y * 2
است. - عرض فریم منهای یک: 24 بیت ( uint24 )
- عرض قاب بر اساس 1 . عرض فریم
1 + Frame Width Minus One
است. - ارتفاع فریم منهای یک: 24 بیت ( uint24 )
- ارتفاع قاب بر اساس 1 . ارتفاع فریم
1 + Frame Height Minus One
است. - مدت زمان فریم: 24 بیت ( uint24 )
- زمان انتظار قبل از نمایش فریم بعدی، در واحدهای 1 میلی ثانیه ای. توجه داشته باشید که تفسیر مدت زمان فریم 0 (و اغلب <= 10) توسط پیاده سازی تعریف می شود. بسیاری از ابزارها و مرورگرها حداقل مدت زمان مشابه GIF را اختصاص می دهند.
- رزرو شده: 6 بیت
- باید
0
باشد. خوانندگان باید این زمینه را نادیده بگیرند. - روش ترکیب (B): 1 بیت
نشان می دهد که چگونه پیکسل های شفاف قاب فعلی باید با پیکسل های متناظر بوم قبلی ترکیب شوند:
0
: از ترکیب آلفا استفاده کنید. پس از دور انداختن فریم قبلی، فریم فعلی را با استفاده از ترکیب آلفا روی بوم رندر کنید (به زیر مراجعه کنید). اگر فریم فعلی کانال آلفا ندارد، مقدار آلفا را 255 فرض کنید که عملاً جایگزین مستطیل می شود.1
: مخلوط نکنید. پس از دور انداختن فریم قبلی، با بازنویسی مستطیل تحت پوشش قاب فعلی، قاب فعلی را روی بوم رندر کنید.
- روش دفع (D): 1 بیت
نشان می دهد که پس از نمایش قاب فعلی (قبل از رندر کردن فریم بعدی) روی بوم چگونه باید با آن برخورد کرد:
0
: دور نریزید. بوم را همانطور که هست بگذارید.1
: به رنگ پس زمینه بیاندازید. مستطیل روی بوم پوشیده شده توسط قاب فعلی را با رنگ پس زمینه مشخص شده در قطعه «ANIM» پر کنید.
یادداشت ها :
حذف فریم فقط برای مستطیل قاب اعمال میشود، یعنی مستطیلی که توسط فریم X ، فریم Y ، عرض قاب و ارتفاع قاب تعریف شده است. ممکن است کل بوم را بپوشاند یا نه.
ترکیب آلفا:
با توجه به اینکه هر یک از کانالهای R، G، B و A 8 بیتی هستند و کانالهای RGB در آلفا ضرب نشدهاند ، فرمول ترکیب «dst» با «src» به این صورت است:
blend.A = src.A + dst.A * (1 - src.A / 255) if blend.A = 0 then blend.RGB = 0 else blend.RGB = (src.RGB * src.A + dst.RGB * dst.A * (1 - src.A / 255)) / blend.A
ترکیب آلفا باید در فضای رنگی خطی و با در نظر ��رفتن نمایه رنگ تصویر انجام شود. اگر نمایه رنگ وجود نداشته باشد، RGB استاندارد (sRGB) باید در نظر گرفته شود. (توجه داشته باشید که sRGB نیز به دلیل گامای ~2.2 باید خطی شود.)
- داده فریم: بایت اندازه تکه -
16
متشکل از:
یک زیربخش آلفا اختیاری برای قاب.
یک خرده جریان بیت برای قاب.
یک لیست اختیاری از تکه های ناشناخته .
توجه : محموله «ANMF»، Frame Data ، از تکههای خالی تشکیل شده است، همانطور که با فرمت فایل RIFF توضیح داده شده است.
آلفا
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('ALPH') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rsv| P | F | C | Alpha Bitstream... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- رزرو شده (Rsv): 2 بیت
- باید
0
باشد. خوانندگان باید این زمینه را نادیده بگیرند. - پیش پردازش (P): 2 بیت
این بیت های اطلاعاتی برای سیگنال دادن به پیش پردازشی که در طول فشرده سازی انجام شده است استفاده می شود. رمزگشا می تواند از این اطلاعات برای مثال برای تغییر دادن مقادیر یا صاف کردن گرادیان ها قبل از نمایش استفاده کند.
-
0
: بدون پیش پردازش. -
1
: کاهش سطح
-
رسیورها نیازی به استفاده از این اطلاعات به هیچ روش مشخصی ندارند.
- روش فیلتر (F): 2 بیت
روش های فیلتر مورد استفاده به شرح زیر است:
-
0
: هیچکدام. -
1
: فیلتر افقی -
2
: فیلتر عمودی -
3
: فیلتر گرادیان.
-
برای هر پیکسل، فیلتر کردن با استفاده از محاسبات زیر انجام می شود. فرض کنید مقادیر آلفای اطراف موقعیت X
فعلی به صورت زیر برچسب گذاری شده اند:
C | B |
---+---+
A | X |
ما به دنبال محاسبه مقدار آلفا در موقعیت X
هستیم. ابتدا بسته به روش فیلتر کردن، پیش بینی انجام می شود:
- روش
0
: پیش بینی کننده = 0 - روش
1
: پیش بینی = A - روش
2
: پیش بینی کننده = B - روش
3
: پیش بینی کننده = کلیپ (A + B - C)
که در آن clip(v)
برابر است با:
- 0 اگر v < 0،
- 255 اگر v> 255، یا
- v در غیر این صورت
مقدار نهایی با افزودن مقدار غیرفشرده X
به پیش بینی کننده و با استفاده از محاسبات مدولو-256 برای قرار دادن محدوده [256..511] در [0..255] به دست می آید:
alpha = (predictor + X) % 256
موارد خاصی برای سمت چپ ترین و بالاترین موقعیت پیکسل وجود دارد. به عنوان مثال، مقدار بالا سمت چپ در مکان (0، 0) از 0 به عنوان مقدار پیش بینی کننده استفاده می کند. در غیر این صورت:
- برای روش های فیلتر افقی یا گرادیان، سمت چپ ترین پیکسل ها در مکان (0، y) با استفاده از مکان (0، y-1) درست در بالا پیش بینی می شوند.
- برای روشهای فیلتر عمودی یا گرادیان، بالاترین پیکسلها در مکان (x، 0) با استفاده از مکان (x-1، 0) در سمت چپ پیشبینی میشوند.
- روش فشرده سازی (C): 2 بیت
روش فشرده سازی مورد استفاده:
-
0
: بدون فشرده سازی. -
1
: با استفاده از فرمت WebP فشرده شده است.
-
- جریان بیت آلفا: بایت اندازه تکه -
1
جریان بیت آلفا رمزگذاری شده
این قطعه اختیاری حاوی داده های آلفای کدگذاری شده برای این فریم است. قاب حاوی یک قطعه 'VP8L' نباید حاوی این قطعه باشد.
دلیل : اطلاعات شفافیت در حال حاضر بخشی از قطعه "VP8L" است.
دادههای کانال آلفا بهعنوان دادههای خام فشردهنشده ذخیره میشوند (زمانی که روش فشردهسازی '0' است) یا با استفاده از قالب بدون تلفات فشرده میشود (زمانی که روش فشردهسازی '1' است).
داده خام: این شامل یک توالی بایت طول = عرض * ارتفاع است که شامل تمام مقادیر شفافیت 8 بیتی به ترتیب اسکن است.
فشرده سازی قالب بدون اتلاف: دنباله بایت یک جریان تصویر فشرده شده است (همانطور که در "WebP Lossless Bitstream Format" توضیح داده شده است) با ابعاد ضمنی عرض x ارتفاع. یعنی این جریان تصویر حاوی هیچ عنوانی نیست که ابعاد تصویر را توصیف کند.
دلیل : ابعاد قبلاً از منابع دیگر شناخته شده است، بنابراین ذخیره مجدد آنها اضافی و مستعد خطا است.
هنگامی که جریان تصویر به مقادیر رنگ آلفا، قرمز، سبز، آبی (ARGB) رمزگشایی شد، به دنبال فرآیندی که در مشخصات فرمت بدون اتلاف توضیح داده شده است، اطلاعات شفافیت باید از کانال سبز چهارگانه ARGB استخراج شود.
دلیل : کانال سبز دارای مراحل تبدیل اضافی در مشخصات است - بر خلاف کانال های دیگر - که می تواند فشرده سازی را بهبود بخشد.
بیت استریم (VP8/VP8L)
این قطعه حاوی داده های جریان بیت فشرده برای یک فریم است.
یک قطعه بیت استریم ممکن است (i) یک قطعه «VP8» باشد که از «VP8» (به فضای مهم نویسه چهارم توجه کنید) به عنوان FourCC خود، یا (ii) یک قطعه «VP8L» با استفاده از «VP8L» به عنوان FourCC آن باشد.
قالبهای «VP8» و «VP8L» به ترتیب در بخشهای Simple File Format (Lossy) و Simple File Format (Lossless) توضیح داده شده است.
نمایه رنگی
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('ICCP') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Color Profile :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- نمایه رنگ: اندازه تکه بایت
- نمایه ICC
این قطعه باید قبل از داده های تصویر ظاهر شود.
حداکثر باید یک چنین تکه ای وجود داشته باشد. اگر چنین تکههای بیشتری وجود داشته باشد، خوانندگان ممکن است همه را به جز مورد اول نادیده بگیرند. برای جزئیات به مشخصات ICC مراجعه کنید.
اگر این قطعه وجود نداشته باشد، sRGB باید فرض شود.
فراداده
متادیتا را می توان در قطعات "EXIF" یا "XMP" ذخیره کرد.
باید حداکثر یک تکه از هر نوع ("EXIF" و "XMP") وجود داشته باشد. اگر چنین تکههای بیشتری وجود داشته باشد، خوانندگان ممکن است همه را به جز مورد اول نادیده بگیرند.
تکه ها به صورت زیر تعریف می شوند:
قطعه 'EXIF':
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('EXIF') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Exif Metadata :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Exif Metadata: بایت اندازه قطعه
- فراداده تصویر در فرمت Exif.
قطعه 'XMP':
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('XMP ') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: XMP Metadata :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- فراداده XMP: بایت اندازه قطعه
- فراداده تصویر در فرمت XMP.
توجه داشته باشید که کاراکتر چهارم در "XMP" FourCC یک فضای ASCII (0x20) است.
راهنماییهای اضافی درباره مدیریت فراداده را میتوان در «راهنمای مدیریت فراداده» گروه کاری فراداده یافت.
تکه های ناشناخته
یک قطعه RIFF (شرح شده در بخش RIFF File Format ) که FourCC آن با هر یک از تکههای توضیح داده شده در این سند متفاوت است، یک قطعه ناشناخته در نظر گرفته میشود.
منطق : اجازه دادن به قطعات ناشناخته، تمهیداتی را برای گسترش قالب در آینده فراهم می کند و همچنین امکان ذخیره هر گونه داده خاص برنامه را فراهم می کند.
یک فایل ممکن است حاوی تکه های ناشناخته باشد:
- در انتهای فایل، همانطور که در بخش هدر فایل Extended WebP توضیح داده شده است، یا
- در انتهای قطعات 'ANMF' همانطور که در بخش انیمیشن توضیح داده شده است.
خوانندگان باید این تکه ها را نادیده بگیرند. نویسندگان باید آنها را به ترتیب اصلی خود حفظ کنند (مگر اینکه به طور خاص قصد اصلاح این تکه ها را داشته باشند).
مونتاژ بوم از فریم
در اینجا ما یک نمای کلی از اینکه چگونه یک خواننده باید یک بوم را در مورد یک تصویر متحرک جمع کند، ارائه می دهیم.
این فرآیند با ایجاد یک بوم با استفاده از ابعاد داده شده در قطعه 'VP8X'، Canvas Width Minus One + 1
پیکسل توسط Canvas Height Minus One + 1
پیکسل آغاز می شود. فیلد Loop Count
از قسمت 'ANIM' تعداد دفعات تکرار فرآیند انیمیشن را کنترل می کند. این Loop Count - 1
برای مقادیر Loop Count
غیر صفر یا بی نهایت است اگر Loop Count
صفر باشد.
در ابتدای هر تکرار حلقه، بوم با استفاده از رنگ پسزمینه از قطعه «ANIM» یا یک رنگ تعریفشده توسط برنامه پر میشود.
تکه های 'ANMF' حاوی فریم های جداگانه ای هستند که به ترتیب نمایش داده می شوند. قبل از رندر کردن هر فریم، Disposal method
قاب قبلی اعمال می شود.
رندر قاب رمزگشایی شده از مختصات دکارتی ( 2 * Frame X
، 2 * Frame Y
) شروع می شود، با استفاده از گوشه سمت چپ بالای بوم به عنوان مبدا. Frame Width Minus One + 1
پیکسل عرض با Frame Height Minus One + 1
پیکسل با استفاده از Blending method
بر روی بوم نمایش داده می شود.
بوم برای Frame Duration
میلی ثانیه نمایش داده می شود. این کار تا زمانی ادامه می یابد که تمام فریم های داده شده توسط قطعات 'ANMF' نمایش داده شوند. سپس یک تکرار حلقه جدید شروع می شود، یا اگر تمام تکرارها کامل شده باشند، بوم در حالت نهایی خود باقی می ماند.
شبه کد زیر روند رندر را نشان می دهد. علامت VP8X.field به معنای فیلدی در قسمت 'VP8X' با همان توضیحات است.
VP8X.flags.hasAnimation MUST be TRUE
canvas ← new image of size VP8X.canvasWidth x VP8X.canvasHeight with
background color ANIM.background_color or
application-defined color.
loop_count ← ANIM.loopCount
dispose_method ← Dispose to background color
if loop_count == 0:
loop_count = ∞
frame_params ← nil
next chunk in image_data is ANMF MUST be TRUE
for loop = 0..loop_count - 1
clear canvas to ANIM.background_color or application-defined color
until eof or non-ANMF chunk
frame_params.frameX = Frame X
frame_params.frameY = Frame Y
frame_params.frameWidth = Frame Width Minus One + 1
frame_params.frameHeight = Frame Height Minus One + 1
frame_params.frameDuration = Frame Duration
frame_right = frame_params.frameX + frame_params.frameWidth
frame_bottom = frame_params.frameY + frame_params.frameHeight
VP8X.canvasWidth >= frame_right MUST be TRUE
VP8X.canvasHeight >= frame_bottom MUST be TRUE
for subchunk in 'Frame Data':
if subchunk.tag == "ALPH":
alpha subchunks not found in 'Frame Data' earlier MUST be
TRUE
frame_params.alpha = alpha_data
else if subchunk.tag == "VP8 " OR subchunk.tag == "VP8L":
bitstream subchunks not found in 'Frame Data' earlier MUST
be TRUE
frame_params.bitstream = bitstream_data
apply dispose_method.
render frame with frame_params.alpha and frame_params.bitstream
on canvas with top-left corner at (frame_params.frameX,
frame_params.frameY), using Blending method
frame_params.blendingMethod.
canvas contains the decoded image.
Show the contents of the canvas for
frame_params.frameDuration * 1 ms.
dispose_method = frame_params.disposeMethod
نمونهای از طرحبندی فایل
یک تصویر رمزگذاری شده با اتلاف با آلفا ممکن است به شکل زیر باشد:
RIFF/WEBP
+- VP8X (descriptions of features used)
+- ALPH (alpha bitstream)
+- VP8 (bitstream)
یک تصویر رمزگذاری شده بدون تلفات ممکن است به صورت زیر باشد:
RIFF/WEBP
+- VP8X (descriptions of features used)
+- VP8L (lossless bitstream)
+- XYZW (unknown chunk)
یک تصویر بدون اتلاف با نمایه ICC و فراداده XMP ممکن است به شکل زیر باشد:
RIFF/WEBP
+- VP8X (descriptions of features used)
+- ICCP (color profile)
+- VP8L (lossless bitstream)
+- XMP (metadata)
یک تصویر متحرک با فراداده Exif ممکن است به شکل زیر باشد:
RIFF/WEBP
+- VP8X (descriptions of features used)
+- ANIM (global animation parameters)
+- ANMF (frame1 parameters + data)
+- ANMF (frame2 parameters + data)
+- ANMF (frame3 parameters + data)
+- ANMF (frame4 parameters + data)
+- EXIF (metadata)