A better approach might be to favor the most recently used filter even if its absolute sum of differences is slightly larger than that of other filters, in order to produce a more homogeneous data stream for the compressor--in effect, to allow short-term losses in return for long-term gains. The standard PNG library contains code to enable this heuristic, but a considerable amount of experimentation is yet to be done to determine the best combination of weighting factors, compression levels, and image types.
One can also imagine heuristics involving higher-order distance metrics e. Lossless compression is a necessity for many applications, but cutting-edge research in image compression tends to focus almost exclusively on lossy methods, since the payoff there is so much greater. Even within the lossless domain, preconditioning the data stream is likely to have less effect than changing the back-end compression algorithm itself.
So let's take a look at that next. The PNG specification defines a single compression method, the deflate algorithm, for all image types.
Independently implemented by Jean-loup Gailly and Mark Adler, first for Info-ZIP's Zip and UnZip utilities and shortly thereafter for the GNU gzip utility, the deflate algorithm is battle-tested and today is probably the most commonly used file-compression algorithm on the Internet. Although it is not the best-compressing algorithm known,[ 70 ] deflate has a very desirable mix of characteristics: high reliability, good compression, good encoding speed, excellent decoding speed, minimal overhead on incompressible data, and modest, well-defined memory footprints for both encoding and decoding.
As an LZderived algorithm, deflate is fundamentally based on the concept of a sliding window. One begins with the premise that many types of interesting data, from binary computer instructions to source code to ordinary text to images, are repetitious to varying degrees. The basic idea of a sliding window is to imagine a window of some width immediately preceding the current position in the data stream and therefore sliding along as the current position is updated , which one can use as a kind of dictionary to encode subsequent data.
For example, if the text of this chapter is the data stream, then the current position at the very instant you read this is here. Instead of encoding such strings as literal text, deflate replaces each with a pair of numbers indicating its length in this case, 10 bytes and the distance back to one of the previous instances perhaps bytes between the fifth and sixth.
The greater the length of the string, the greater the savings in encoding it as a pointer into the window. LZSS employs a look-ahead buffer and finds the longest match for the buffer within the sliding window. If the longest match is not sufficiently long, the first character in the look-ahead buffer is output as a literal value, and the buffer is advanced by one.
Either way, the algorithm continues by seeking the longest match for the new contents of the buffer. The deflate algorithm is actually a bit more clever than the preceding description would suggest. This approach is generically referred to as LZH; deflate's uniqueness lies in its method of combining literals and lengths into a single Huffman tree, its use of both fixed and dynamic Huffman codes, and its division of the output stream into blocks so that regions of incompressible data can be stored as is, rather than expanding significantly, as can happen with the LZW algorithm.
The PNG specification further dictates that the deflate data stream must conform to the zlib 1. In particular, the size of the sliding window must be a power of 2 between bytes and 32 kilobytes, inclusive, and a small zlib header and trailer are required.
Practically speaking, independent implementation of the deflate algorithm is both difficult and unnecessary. As an aside, note that the efficiency of the compression engine increases as more data is processed, with peak efficiency being reached when there is sufficient data to fill the sliding window.
But because of data buffering in network protocols and applications, any large disparities due to the truly low-efficiency encoding at startup will tend to be washed out at the byte level or higher. In fact, there are a number of patents that can be infringed upon by a compliant deflate implementation, including one held by PKWARE itself that involves sorted hash tables. But the deflate specification includes a section on implementing the algorithm without infringing,[ 72 ] and, of course, zlib itself follows that prescription.
The only convincing way to demonstrate the compression benefits of one image format over another is to do an actual comparison of the two on a set of real images. The problem is choosing the set of images--what works for one person may not work for another. What I've done here is to gather together results from a number of real-world tests performed over the past few years. Readers can expect to achieve similar results on similar sets of images, but keep in mind that one can always choose a particular set of images for which the results will be dramatically different.
I'll explain that remark after we see a few cases. For starters, let's look at a small, very unscientifically chosen set of images: seven nonanimated GIF images that happened to be the only ones readily available on my machine one fine day in June Table All but the first and last were interlaced. Five of the images shrank when converted to PNG--three of them quite significantly--while two grew. Overall, the set achieved a 6. But the owner of a web site will often be willing to spend a little more time up front on compression in return for additional bandwidth savings in the long run.
Table shows its results; the percentages are again relative to the original GIF file sizes. So we see that the current state-of-the-art PNG encoder ekes out another percentage point in the total size, with all but one of the images now smaller than the original. That lone holdout is worth a closer look in this case.
The noninterlaced GIF version is 4, bytes, only 16 bytes smaller than the original. But the noninterlaced PNG version is either 4, bytes gif2png or 4, bytes pngcrush --a savings of In other words, PNG's two-dimensional interlacing scheme can have a significant negative impact on compression , particularly for small images. This example may have been instructive, but seven images do not constitute a statistically valid sample.
Though the content of the course was otherwise outstanding, one slide comparing image formats for 3D textures was rather alarming from a PNG perspective.
It showed the information displayed in Table , together with the textures themselves which are omitted here :. Even with no more details than are shown here, at least one problem is apparent: in row 2, the JPEG image is 24 bits deep, while the GIF is only 8 bits. So on the one hand, PNG is being compared with an image of the same depth that uses lossy compression, while on the other it is being compared with an image only one-third as deep, which also amounts to lossy compression. That hurts. But this comes at a loss of image quality, which is why this is called lossy compression.
Sometimes the difference is noticeable, other times not. PNG files are high quality and often take up a lot of space on your hard drive.
By reducing file size with compression, you can store more images and other files. Coincidentally, file size also impacts loading times on websites. In image editing software, you can often set the amount of lossless compression when saving in PNG. First, GIF and PNG both get an automatic factor-of-three savings from the fact that each pixel is only 1 byte deep instead of 3 bytes.
Second, JPEG is at a relative disadvantage when dealing with grayscale images, because most of its compression benefits arise from how it treats the color components of an image. Third, this particular image is more artificial than natural, with quite a few relatively sharp features, which makes it particularly ill suited to JPEG-style compression. But perhaps the most striking feature of Table is just how poorly the original encoder did on its PNG images.
Indeed, the owner indicated that he had used ImageMagick's convert utility, older versions of which reportedly had the unfortunate habit of creating bit PNGs unless explicitly given the -depth 8 option. This problem seems to have been fixed in more recent versions, but even current versions include bytes' worth of text and background chunks per image. Individually, the GIFs were smaller in 15 of the 54 cases, but never by more than bytes.
Of the 39 images in which the PNG version was smaller, one-third of them differed by more than a kilobyte, and one was 14 KB smaller. Of these, 43 had embedded text comments and 39 were interlaced. The total size of the files was 1,, bytes. Conversion to PNG via gif2png , handling the interlaced and noninterlaced images separately in order to preserve their status, resulted in a total PNG size of 1,, bytes, or a Additional compression via pngcrush resulted in a total of 1,, bytes, or a Out of the images, PNG won the size comparison in cases, lost in cases, and tied in 2 cases.
As in the previous test, however, the magnitude of the differences was the critical factor: GIF won by more than a kilobyte in only 1 case, while PNG won by that amount in 37 cases of which were greater than 10 KB, 1 more than 64 KB. The average difference for the cases in which PNG was smaller was bytes; for the GIF cases, it was a mere 78 bytes.
Finally, I've mentioned an upcoming JPEG standard for lossless compression a couple of times; it's worth a quick look, too. As this is written, it is implemented in version 0. An independent implementation is available as C source code from the University of British Columbia. In a comparison performed by Adam Costello, the HP encoder was tested against pnmtopng and pngcrush on the eight standard color images in the Waterloo BragZone's ColorSet.
I have omitted its size results from the comparison since, as expected, pngcrush outperformed it in all cases, though at a considerable cost in speed. The results were fascinating.
These results are summarized in Table ; once again, the byte size of the winning format for each image is highlighted in boldface type.
In any case, the results are only slightly more statistically valid than the first comparison of GIF images was. Eight samples, even if they are a carefully chosen set of standard research images, cannot tell the full story. And results as intriguing as these certainly deserve more extensive testing, which will no doubt happen in due course.
I could hardly end this chapter without some practical pointers on optimizing PNG compression, both for users and for programmers. Herewith are some rough guidelines, arranged in descending order of effectiveness. Note that, as with any set of rules, there will always be exceptions. For example, don't convert a GIF which, from a practical perspective, always has a depth of 8 bits or less to a bit PNG; that will automatically boost the file size by a factor of three.
Similarly, if given the option, don't save a grayscale image as RGB; save it as grayscale or, at worst, as a palette-based PNG. This is something that only you, the user, can judge; no reasonable image application will ever quantize which is a lossy transformation unless instructed to do so by you. This is not an issue for GIF, which realistically supports only colormapped images i. Only PNG supports colormapped, grayscale, and truecolor images, as well as alpha channels.
Interlacing is a way to transmit the useful parts of an image more quickly, particularly on the Web, so that the end user can click on a hot-linked region before the image is fully downloaded, if she so chooses. Since small images are transmitted over the network fairly quickly anyway, they usually do not need to be interlaced.
In the first six chapters, I discussed a number of PNG-supporting applications and noted their limitations wherever possible; use that as a guide when choosing your tools, assuming you have a choice.
Even if your program generally compresses PNG images well, consider using an optimizer such as pngcrush on everything when you're done; [76] definitely do so if your program is not known for its compression performance. For converting GIFs to PNGs, the dedicated gif2png is the most capable solution, even given its permanently beta version number; it preserves both transparency and embedded text comments.
As of April , there are still a few optimization tricks it doesn't do, but its author is addressing those even as this is written. A lengthy copyright message or other text can add bytes or more, which is a lot for icons and other small images. Count colors! If there are or fewer colors, write a colormapped image; doing so will translate to a factor-of-three savings in the PNG file size relative to an RGB image.
If the image is colormapped, don't assume that the pixels must be 8 bits deep. If there are only one or two colors, write a 1-bit image. If there are three or four colors, write a 2-bit image. If there are between 5 and 16 colors, write a 4-bit image. These are the only useful cases for PNG. The compression engine cannot compensate for bloated pixels! Choosing the correct depth for a palette-based image will reduce the file size by a factor of anywhere from two to eight relative to an 8-bit image.
If you know the image is gray, see if it can be written more compactly as a grayscale PNG than as a colormapped PNG--this is automatically true if there are more than 16 shades of gray.
Doing so will save up to bytes by eliminating the palette. But don't assume that 16 or fewer shades automatically means the image can be written as 4-bit or smaller grayscale. Grayscale necessarily implies that the shades are evenly distributed from black to white. If, for example, the 16 shades are bunched up in one part of the gray spectrum, the image must be written as 8-bit grayscale or 4-bit palette-based.
For larger images, the palette-based approach is almost certainly better; for small ones it depends, but the 8-bit grayscale case may end up being smaller. Try both, if possible; it's very fast for small images. For programs that use libpng discussed at length in Part III, "Programming with PNG" , this is not a serious issue; it will automatically do the right thing if left to itself.
In many graphics programs it is possible to work not only on whole pixels, but also to move objects by half pixels. However, if you want to save a graphic from cloned objects perfectly as PNG, the objects must be absolutely identical so that only the first object occupies memory space.
Fortunately, you can recognize this in the compression view very quickly. This is often the case with masked images and ensures that space is wasted by invisible image information. The area around Lena should actually be transparent, but in the compression view you can see clearly that some data is compressed there:.
Usually the quality of an 8-bit PNG should always be sufficient. Your image will be reduced to a maximum of colors. Missing colors are simulated by Dithering. Play with the slider for the number of colors. Straight, flat pictures such as logos almost never need colors. A good rule of thumb is to calculate eight additional colors for each color in the picture so that the Antialiasing looks clean. If a logo consists of the colors red, blue and black, it should be enough to set the color slider to Posterization is the process of color reduction within an image.
This is useful because in an RGB image there are often more colors than the human eye can distinguish. Through the posterization very similar colors are now combined into one.
This is only disturbing if the colors really differ. Particularly in the case of grainy images with a slight image noise, it is a good idea to work with the selective blur that you find in COD in the "preprocessing" area.
It ensures that details remain sharp, but surfaces are softened. Since the PNG filters work better with the resulting clean surfaces, the image becomes smaller. Normally, JPG does not support transparency. But the use of javascript can compensate for this flaw as long as the image is used in the web environment.
Especially in the case of large transparent images such as images of products, the resulting image is much smaller than a transparent PNG would be. It is even smaller than an 8-bit PNG. And now we're at the end. If you have any questions, suggestions, wishes or the like drop me a line. Open the ball image in PNG compressor. Facebook Twitter. Your opinion is so important for me!
Don't hesitate to drop me a line.
0コメント