What is a png file
Portable Network Graphics (PNG) is a sort of lossless compression raster image
file format. The Graphics Interchange Format (GIF) was replaced by this file
format, which has no copyright restrictions. However, animations are not
supported by the PNG file format. PNG is a popular file format because it
allows for lossless picture compression. PNG has become one of the most widely
used image file formats as time has passed.
An overview of the past
The patented compression algorithm Lempel-Ziv-Welch, which was employed in the
GIF file format, was the primary motivation for the development of the PNG
file format. This, combined with other GIF limitations, necessitated the
necessity for a GIF file format successor. In January 1995, the PNG file
format was initially proposed and given a name. The following are important
events related to PNG file formats:
-
PNG requirements, October 1996 Version 1.0 was published, and it was later
renamed RFC 2083. In October 1996, the same became a W3C Recommendation. -
Version 1.1 was released in December 1998, with a few minor adjustments and
the addition of three new chunks. - Version 1.2, which included one extra chunk, was released in August 1999.
-
PNG became an international standard in November 2003 (ISO/IEC 15948:2003).
This version of PNG differs from version 1.2 only slightly and contains no
new chunks. - March 2004: ISO/IEC 15948:2004
Comparison of GIF vs PNG in terms of functionality
The PNG file format was created with the goal of being simple and portable, as
well as legal, interchangeable, adaptable, and robust. The features of the GIF
file format that are inherited by the PNG file format, as well as additional
features, are shown in the table below.
Structure of PNG Files
PNG files can be opened by almost all operating systems.
For example,
Microsoft Windows Viewer can open PNG files by default because the OS includes
support as part of the installation.
A PNG file is made of of a PNG
signature and several /chunks/.
Header of the file
The following (decimal) values are always present in the first eight bytes of
a PNG file:
137 80 78 71 13 10 26 10
This signature denotes that the rest of the file is made up of a single PNG
image made up of a sequence of chunks starting with an IHDR chunk and ending
with an IEND chunk.
Chunk
Each chunk is divided into four sections:
1 Length: The number of bytes in the chunk's data field is represented
by a 4-byte unsigned integer. Only the data field, not the chunk type code or
the CRC, is counted in the length. A length of zero is acceptable. Although
the length should be treated as unsigned by encoders and decoders, its value
must not exceed 231 bytes.
2 Chunk type: A chunk code of four bytes. Type codes are limited to
uppercase and lowercase ASCII letters for ease of description and examination
of PNG files (A-Z and a-z, or 65-90 and 97-122 decimal). Encoders and
decoders, on the other hand, must consider the codes as fixed binary values
rather than character strings. For example, using the EBCDIC equivalents of
those letters to represent the type code IDAT would be incorrect. The next
section goes over additional chunk type naming conventions.
3 Chunk data: If applicable, the data bytes for the chunk type. This
field may have no length.
4 CRC: The chunk type code and chunk data fields, but not the length
field, are subjected to a 4-byte CRC (Cyclic Redundancy Check). Even for
chunks with no data, the CRC is always present.
Implementors cannot presume that chunks are aligned on any boundaries greater
than bytes because the chunk data length can be any number of bytes up to the
maximum.
The sequence in which chunks appear is determined by the limits imposed on
each chunk type. (One important constraint is that IHDR must come first and
IEND must come last; as a result, the IEND chunk acts as a file end marker.)
Multiple chunks of the same type can occur, but only if that kind is
explicitly allowed.
Types of Chunks
Based on the 4-byte case-sensitive ASCII value supplied to the Chunk Type, it
is divided into Critical and Ancillary chunks. The standard critical chunks
must be understood and rendered effectively by all implementations. An IHDR
chunk, one or more IDAT chunks, and an IEND chunk must all be present in a
valid PNG picture.
Compression
Deflate/inflate compression with a sliding window of at most 32768 bytes is
specified by PNG compression method 0 (the only compression method currently
defined for PNG). Deflate compression is an LZ77 derivative that is utilised
in programmes like zip, gzip, and pkzip. Its patent-free status has been
supported by extensive research.
Each block in the zlib datastream can represent raw (uncompressed) data,
LZ77-compressed data encoded with fixed Huffman codes, or LZ77-compressed data
encoded with custom Huffman codes. The final block has a marker bit that
identifies it as the last block, allowing the decoder to recognise the
compressed datastream's end.
Filtering Before Compression
To prepare the image data for optimal compression, pre-compression filters are
used.
The PNG filter method defines the following five fundamental filter
types:
Filtering algorithms are applied to bytes, not to pixels,
regardless of the bit depth or color type of the image. The filtering
algorithms work on the byte sequence formed by a scanline. If the image
includes an alpha channel, the alpha data is filtered in the same way as the
image data.
Each pass of the interlace pattern is handled as an individual image for
filtering purposes when the image is interlaced. The filters work on the byte
sequences created by the pixels actually communicated during a pass, and the
"prior scanline" is the one that was previously broadcast in the same pass,
not the one next to it in the entire image.
It's worth noting that the subimage broadcast in each pass is always
rectangular, but smaller in width and/or height than the entire image. When
this subimage is empty, no filtering is applied.
