فایل PNG چیست؟
فایل PNG (Portable Network Graphics) یک فرمت فایل تصویری شطرنجی است که از فشرده سازی بدون تلفات استفاده می کند. این فرمت فایل به عنوان جایگزینی برای فرمت تبادل گرافیکی (GIF) ایجاد شده است و هیچ محدودیتی در حق نسخه برداری ندارد. با این حال، فرمت فایل PNG از انیمیشن ها پشتیبانی نمی کند. فرمت فایل PNG از فشرده سازی تصویر بدون اتلاف پشتیبانی می کند که باعث محبوبیت آن در بین کاربرانش می شود. با گذشت زمان، PNG به عنوان یکی از فرمت های فایل تصویری که به طور گسترده مورد استفاده قرار می گیرد، تکامل یافته است.
تاریخچه مختصر فرمت فایل PNG
The main reason behind the creation of PNG file format was the patented compression algorithm, Lempel-Ziv-Welch, used in the GIF file format. This along with other GIF limitations created a need for replacement of GIF file format. The first proposal and name for PNG file format came in January 1995. رویدادهای کلیدی در رابطه با فرمتهای فایل PNG در زیر فهرست شدهاند:
اکتبر 1996: مشخصات PNG نسخه 1.0 منتشر شد و بعداً به عنوان RFC 2083 ظاهر شد. همین مورد در اکتبر 1996 به یک توصیه W3C تبدیل شد.
دسامبر 1998: نسخه 1.1 با تغییرات کوچک و اضافه شدن سه قطعه جدید منتشر شد.
اوت 1999: نسخه 1.2 با اضافه کردن یک تکه اضافی منتشر شد.
نوامبر 2003: PNG به یک استاندارد بین المللی تبدیل شد (ISO/IEC 15948:2003). این نسخه از PNG فقط کمی با نسخه 1.2 متفاوت است و هیچ قطعه جدیدی اضافه نمی کند.
مارس 2004: ISO/IEC 15948:2004
مقایسه عملکردی GIF و PNG
فرمت فایل PNG به گونه ای طراحی شده است که ساده و قابل حمل، از نظر قانونی بدون محدودیت، قابل تعویض، انعطاف پذیر و قوی باشد. جدول زیر ویژگیهای GIF را که علاوه بر ویژگیهای جدید با فرمت فایل PNG به ارث بردهاند، فهرست میکند.
ویژگی | GIF | PNG |
---|---|---|
تصاویر رنگی شاخص تا 256 رنگ | بله | بله |
پشتیبانی از پخش | بله | بله |
شفافیت | بله | بله |
اطلاعات جانبی | بله | بله |
استقلال سخت افزار و پلتفرم | بله | بله |
موثر | بله | بله |
تصاویر تراکالور تا 48 بیت در هر پیکسل | نه | بله |
تصاویر خاکستری تا 16 بیت در هر پیکسل | نه | بله |
کانال آلفا کامل (ماسک های شفافیت عمومی) | نه | بله |
اطلاعات گامای تصویر | خیر | بله |
قابلیت اعتماد | خیر | بله |
ارائه اولیه سریعتر | نه | بله |
ساختار فایل PNG
تقریبا تمام سیستم عامل ها از باز کردن فایل های PNG پشتیبانی می کنند. برای مثال، Microsoft Windows Viewer این قابلیت را دارد که فایلهای PNG را باز کند، زیرا سیستمعامل بهطور پیشفرض از پشتیبانی در دسترس به عنوان بخشی از نصب برخوردار است. یک فایل PNG از یک «امضا» PNG و به دنبال آن یک سری از //chunks// تشکیل شده است.
هدر فایل PNG
هشت بایت اول یک فایل PNG همیشه حاوی مقادیر (اعشاری) زیر است:
{{{137 80 78 71 13 10 26 10 }}}
این امضا نشان میدهد که باقیمانده فایل حاوی یک تصویر PNG است که شامل یک سری تکهها است که با یک قطعه IHDR شروع میشود و با یک قطعه IEND ختم میشود.
تکه ها
هر قطعه از چهار قسمت تشکیل شده است:
طول: یک عدد صحیح بدون علامت 4 بایتی که تعداد بایت های فیلد داده قطعه را نشان می دهد. طول فقط فیلد داده را محاسبه می کند، نه خود، کد نوع قطعه یا CRC. صفر یک طول معتبر است. اگرچه رمزگذارها و رمزگشاها باید طول را بدون علامت در نظر بگیرند، اما مقدار آن نباید از 231 بایت تجاوز کند.
Chunk Type: A 4-byte chunk type code. For convenience in description and in examining PNG files, type codes are restricted to consist of uppercase and lowercase ASCII letters (A-Z and a-z, or 65-90 and 97-122 decimal). However, encoders and decoders must treat the codes as fixed binary values, not character strings. For example, it would not be correct to represent the type code IDAT by the EBCDIC equivalents of those letters. Additional naming conventions for chunk types are discussed in the next section.
Chunk Data: بایت های داده متناسب با نوع قطعه، در صورت وجود. طول این فیلد می تواند صفر باشد.
CRC: یک CRC 4 بایتی (بررسی چرخهای افزونگی) که بر روی بایتهای قبلی در قطعه محاسبه میشود، از جمله کد نوع قطعه و فیلدهای داده تکه، اما شامل فیلد طول نمیشود. CRC همیشه وجود دارد، حتی برای تکههایی که دادهای ندارند.
طول داده تکه می تواند هر تعداد بایت تا حداکثر باشد. بنابراین، پیادهکنندهها نمیتوانند فرض کنند که تکهها روی مرزهای بزرگتر از بایتها تراز شدهاند.
تکهها میتوانند به هر ترتیبی ظاهر شوند، مشروط به محدودیتهای اعمال شده در هر نوع تکه. (یک محدودیت قابل توجه این است که IHDR باید ابتدا ظاهر شود و IEND باید آخرین ظاهر شود؛ بنابراین قطعه IEND به عنوان نشانگر انتهای فایل عمل می کند.) چندین تکه از یک نوع می توانند ظاهر شوند، اما فقط در صورتی که به طور خاص برای آن نوع مجاز باشد.
انواع تکه
انواع قطعه بر اساس مقدار ASCII حساس به حروف کوچک و بزرگ 4 بایتی که به نوع قطعه اختصاص داده شده است به بخش های ** بحرانی** و ** کمکی** تقسیم می شوند. همه پیاده سازی ها باید تکه های بحرانی استاندارد را درک کرده و با موفقیت ارائه دهند. یک تصویر PNG معتبر باید شامل یک قطعه IHDR، یک یا چند قطعه IDAT و یک قطعه IEND باشد.
فشرده سازی
روش فشرده سازی PNG 0 (تنها روش فشرده سازی که در حال حاضر برای PNG تعریف شده است) فشرده سازی deflate/inflate را با یک پنجره کشویی حداکثر 32768 بایت مشخص می کند. فشرده سازی Deflate یک مشتق LZ77 است که در zip، gzip، pkzip و برنامه های مرتبط استفاده می شود. تحقیقات گسترده ای برای حمایت از وضعیت عاری از اختراع آن انجام شده است. داده های فشرده شده در جریان داده zlib به عنوان یک سری بلوک ذخیره می شوند، که هر کدام می توانند داده های خام (غیر فشرده)، داده های فشرده شده با LZ77 رمزگذاری شده با کدهای هافمن ثابت، یا داده های فشرده LZ77 که با کدهای هافمن سفارشی رمزگذاری شده اند را نشان دهند. یک بیت نشانگر در بلوک نهایی آن را به عنوان آخرین بلوک شناسایی می کند و به رمزگشا اجازه می دهد تا انتهای جریان داده فشرده را تشخیص دهد.
فیلتر پیش فشرده سازی
فیلترهای پیش فشرده سازی برای آماده سازی داده های تصویر برای فشرده سازی بهینه اعمال می شوند. روش فیلتر PNG پنج نوع فیلتر اصلی را به شرح زیر تعریف می کند:
نوع فیلتر | نام | مقدار پیش بینی شده |
---|---|---|
0 | هیچ | اسکن لاین بدون تغییر ارسال میشود |
1 | Sub | تفاوت بین هر بایت و مقدار بایت مربوطه پیکسل قبلی را منتقل می کند. |
2 | Up | فیلتر Up() دقیقاً مانند فیلتر Sub() است با این تفاوت که پیکسل بلافاصله بالای پیکسل فعلی، به جای سمت چپ آن، به عنوان پیش بینی کننده استفاده می شود. |
3 | Average | فیلتر Average() از میانگین دو پیکسل همسایه (چپ و بالا) برای پیشبینی مقدار یک پیکسل استفاده میکند. |
4 | Paeth | فیلتر Paeth یک تابع خطی ساده از سه پیکسل همسایه (چپ، بالا، بالا سمت چپ) را محاسبه میکند، سپس پیکسل مجاور نزدیک به مقدار محاسبه شده را به عنوان پیشبینیکننده انتخاب میکند. |
بدون توجه به عمق بیت یا نوع رنگ تصویر، الگوریتمهای فیلتر بر روی «بایت» اعمال میشوند، نه برای پیکسلها. الگوریتم های فیلتر روی توالی بایتی که توسط یک خط اسکن تشکیل شده است کار می کنند. اگر تصویر شامل یک کانال آلفا باشد، داده های آلفا مانند داده های تصویر فیلتر می شوند.
هنگامی که تصویر در هم آمیخته می شود، هر گذر از الگوی interlace به عنوان یک تصویر مستقل برای اهداف فیلتر در نظر گرفته می شود. فیلترها روی دنبالههای بایتی کار میکنند که توسط پیکسلهایی که در واقع در طول یک عبور ارسال میشوند، تشکیل میشوند، و «اسکنلاین قبلی» همانی است که قبلاً در همان پاس منتقل شده است، نه مجاورت تصویر کامل. توجه داشته باشید که تصویر فرعی ارسال شده در هر گذر همیشه مستطیلی است، اما عرض و/یا ارتفاع کمتری نسبت به تصویر کامل دارد. وقتی این تصویر فرعی خالی است، فیلتر اعمال نمی شود.