Talk about common image formats

Ma Jian
Email:[email protected]
Published: 2013.02.15
Last update: 2013.02.19

Directory
One, BMP
Second, GIF, PNG
Third, JPEG (JPG)
Four, JPEG 2000
V. TIFF
Liu, DjVu
VII. PDF
Viii. Summary

Many image formats are supported in CEP, CV, and UV, so I am often asked the same question: what is the difference between different image formats? What kind of image format should I choose when I save an image?

This article hope to be able to give a simple answer to the above questions, of course, whether it has been shallow enough to let you understand the extent, it is necessary to see the creator.

One, BMP

BMP is a Microsoft proposed image format, the full name is bitmap, so also translated into "bitmap." BMP has the following characteristics:

1. For screen display, so the format itself is related to the development of graphics technology. For example, in a common image format, only BMP supports 16-bit color, because an entire generation of graphics card is 16-bit color.
2. Although the new generation of Windows API can directly display images in JPG, PNG and other formats, but the early GDI function can only display BMP images, so the general image display, image editing software will be the other format of image files in memory decoded into BMP, and the pixel lattice information in BMP editing , modify, display, save as required format.

In the image compression, although according to Microsoft's rules, BMP itself supports lossless RLE (Run Length Encode, stroke encoding) compression algorithm, but in addition to the Windows 2000 source code to see several BMP files using this compression algorithm, I see all the other BMP files are non-compressed, we generally think that BMP uncompressed image format, and therefore consider the BMP file length is very large.

There are very few people who use RLE compression for BMP, and I guess the possible causes include:

1. RLE itself is not a very efficient compression method, in the worst case, the length of the compressed data is much longer than the original data length.
2. Everyone is lazy, not compression is certainly more convenient than compression. and uncompressed BMP is easier to handle (basically a two-dimensional array), which is faster to display.

In the case of non-compression, the BMP file length is:
BMP file Length = BMP file Header length + palette bytes + pixel lattice information Length (1)

In the Formula 1, the BMP file header length is fixed, the color palette only when the image is a palette image, 16-bit color, 24-bit color, 32-bit color is no color palette. The palette image allows for monochrome, 16-color, 256-color, and 4 bytes per color in the palette, so even with a maximum of 256 colors, the palette occupies only 1024 bytes =1kb, which has little effect on file length.

The pixel lattice information length in type 1 can be estimated using the following formula (the result is in bytes):
Pixel lattice information length ≈ The pixel height of the image × the pixel width of the image x bytes consumed per pixel (2)

Note that the 2 is "approximately equal", not "equal", because the general BMP file is stored, need Bashi 2 in
The pixel width of the image × the number of bytes consumed per pixel
Part (scan line width) is rounded to a multiple of 4, while Formula 2 ignores this rounding, so the number of bytes calculated may be slightly less than the actual number of bytes consumed. However, this difference is not very large, so in order to facilitate the calculation, it has been simplified. The real calculation formula should be:
Pixel lattice information length = pixel height x (pixel width × number of bits per pixel +31) ÷32x4) (3)

From the formula 2, 3 can be seen, BMP file really accounted for the big head of the pixel lattice information, and in the case of no compression, BMP pixel lattice information and image pixel height, pixel width, the number of bytes per pixel is related to the image content. To reduce the length of BMP files, you can start from the following aspects:

1. thumbnail, which reduces the pixel height and pixel width of the image.
2. Subtractive, which reduces the number of bytes consumed per pixel. If the 24-bit color chart occupies 24 bits per pixel, or 3 bytes, the subtractive 256 color is only 1 bytes per pixel, minus 16 bytes per pixel after reducing the color to a single color after 1/2 bytes per pixel, the difference is very considerable.

Of course there is no free lunch, the above two methods will cause image quality changes, and this change is irreversible, so later want to regret is not. But as long as it's done properly, the huge gains are worth worked. For example, in the foreign e-book scanning world's famous operating course "the Scan and Share tutorial", it is advocated to use a grayscale scan to improve the efficiency of scanning (ordinary home scanners after more than 600 dpi sweep slow), and then use the software to zoom in one times to up to a factor of up to a maximum rate of up to DPI, then after trimming, skew, uniform size, centering and other processing, subtractive into a monochrome image, and then converted to PDF or DjVu. Now do you know why foreign-scanned books look so clear? DPI!

Without considering the subsequent image compression, the image size is enlarged one times, and then reduced from 24-bit color to monochrome (1-bit color), although the image magnification caused the image pixel area is 4 times times the original, but each pixel occupies only the original 1/24 bytes, so the total file length is about the original 1/6. If the scan is a 256-level gray scan, after sweeping the image size magnification, and then from 256 grayscale subtractive to monochrome (1-bit color), although the image magnification caused the image pixel area is the original 4 times times, but the number of bytes per pixel only the original 1/8, so the total file length is about the original 1/2.

"The Scan and Share tutorial" advocated first amplification and then subtractive, in fact, a psychological and software to drill a loophole: when the image pixel size exceeds the screen display area pixel size (plainly, a screen does not display the entire image), people usually choose the thumbnail display, For the conventional software with conscience, monochrome image will usually become 256 levels of gray, with the middle gray point to cover the defects caused by the reduction of aliasing. Therefore, although amplification, subtractive text edge may appear to be no original scan image clear, mellow, always feel a bit of burr, but the actual thumbnail display, the effect is not worse than the original, but the file length can be greatly reduced.

CX's large plate PDG, in fact, is also an example of increasing the level of gray after scaling: the large plates are from the clear version of the PDG thumbnail, but the black and white two-color clear version of the image to save as 16 levels of gray or 256 levels of gray, in the middle gray level of the transition looks good. The fast version of the PDG is also from the clear version of the thumbnail, but in order to use the DjVu compressed text layer and force the reduced image remains black and white, there is no intermediate transition, looks a lot worse.

BMP format is Microsoft's own definition, in the Windows API also provides a common operating interface, so the image acquisition, preservation, transfer is very simple, a lot of "digital image processing" related textbooks also provide relevant example code, interested in the search has.

Second, GIF, PNG

GIF full name Graphics Interchange format, translated as "Graphics Interchange Format", pronounced [d?if];png Full name Portable Network Graphics, translated into "portable web graphic", pronounced [ping].

GIF, PNG are lossless compressed image format, but GIF with LZW compression algorithm, PNG compression using a similar compression algorithm WinZip. In other words, PNG is basically the equivalent of a zip-compressed BMP. So every time I see someone suspected BMP to PNG will not appear image quality loss, my answer is consistent: You find a file, zip, unzip 100 times, and then see the contents of the file has not changed.

LZW and zip (more professional parlance is flate) algorithms who have a higher compression rate? This is said on page 71st of PDF Reference Sixth Edition:
Usually, both flate and LZW encodings compress their input substantially. However, in the worst case (in which no pair of adjacent characters appears twice), flate encoding expands their input by no More than bytes or a factor of 1.003 (whichever are larger), plus the effects of algorithm tags added by PNG predictors . For LZW encoding, the most zeros provides a compression approaching 1365:1 for long files, but the worst-case E Xpansion is at least a factor of 1.125, which can increase to nearly 1.5 in some implementations, plus the effects of PNG tags as with flate encoding.

Can't you read it? That's a popular argument: the compression ratio of the two compression algorithms is different, and many times look at character and luck. So when the image is stored in the choice of GIF or PNG, from the compression algorithm is difficult to choose, mainly to see the use.

GIF format appears earlier than PNG, the current popular is the GIF89A standard, according to the version of the GIF file features are:

• Supports up to 256-color palette images and does not support 24-bit, 32-bit images. Some software now supports 24-bit, 32-bit GIF, but is not compatible with the GIF89A standard, so it is basically a niche software.
• Support animations. In the common image format GIF is the only support animation, but the animation of each frame image is subject to a limit, so the display of some artificial animation no problem, but the color-rich video into GIF animation, because the color forced to reduce to 256 colors, will cause the image quality degradation, the appearance of "contour" and other phenomena.
• Background transparency is supported by specifying a color in the palette as a transparent color. When you draw a GIF image, the color of the pixel you need to paint is transparent if it's a clear color.

It is clear that GIF's "transparency" has the following characteristics:

• Only "Transparent" is supported, "translucent" is not supported, that is, a pixel is either transparent or opaque, and cannot be "transparency 60%".
• Transparent color is a data field in the GIF file structure, so there is no transparent color and has no effect on the length of the GIF file. I once saw someone excitedly announcing his "great discovery" in an e-book forum: After turning BMP into GIF and specifying a transparent color, he was surprised to find that the length of the file was smaller, and he guessed it was because he "stole the transparent color" that he thought GIF did not need to store the transparent part. After reading this article I think we all know where the problem is: 24-bit color BMP into 256 colors, and then use LZW compression, the file is not small to blame, and transparent opaque there is no correlation.

PNG appears to be quite similar to GIF in name, and the two sides actually really have a source: all of a sudden, the Unisys company claimed that the LZW algorithm used in GIF violated the company's patents and began to charge patent fees for all software that supported GIF format. So everyone is angry, simply throw away gif, instead of patent dispute zip algorithm, and combined with the latest image requirements, tinker out the PNG format. This story is described in the relevant documents of Giflib and libpng, and is interesting to see.

PNG is characterized by:

• In addition to the palette image, multi-channel images are supported, and the number of samples per channel can be 8-bit, 16-bit, and so on. This passage genteel not understand? That's easy: PNG supports 24-bit true color images, so many high-quality footage on the network uses PNG instead of GIF to avoid being restricted by 256 colors.
• For palette images, the same transparent color as GIF is supported. For multichannel images, the alpha channel transparency is supported, which allows for a "translucent" effect. Of course, the extra alpha channel also consumes storage space.
• Animations are not supported.

In conclusion, I think we can decide whether to choose GIF or PNG according to the following principles:

• If you need an animated effect, you have no choice but to GIF.
• If you want to store 24-bit color, it is also not optional, only PNG.
• If you want to implement translucency, you can choose PNG only, or PNG or GIF if you want to make it transparent on the palette.
• For the palette image, if you really, really care about the size of the file, to the extent of the pinching irritate D, the only way is to GIF, PNG each press again, and then choose the smallest file. If you are afraid of trouble, it is recommended to choose PNG directly, from a statistical point of view LZW compression rate is inferior to zip, but in the compression speed LZW better than zip.

As mentioned earlier, PNG is equivalent to zip compression of BMP (GIF is LZW compression of BMP), so the final PNG file length is limited by the following factors:

• The original BMP file length, see the above formula (1) ~ (3), that is, the image pixel height, pixel width, the number of bytes per pixel occupied.
• The compressible nature of pixel data. The compression rate of all lossless compression algorithms is based on the repeatability of the data, for example, for the string aaaaaaabbbbb, can be recorded as A7B5, from 12 characters compressed into 4 characters, but for the string afhrswnm if the same way, will not achieve the "compression" effect. Do not understand? That would be a simple argument: when the image's pixel height, pixel width, and bytes per pixel are the same, the more "clean" the image, the smaller the final PNG image size. Don't believe me? Please find a full text of PNG, with software processing into pure white, and then save, compare the length of the file to know.

So the trick of shrinking PNG and GIF files is:

• Use the same tips as the length of the BMP image, including thumbnails, subtractive, and so on.
• Use image processing software to process and make the image as clean as possible. Simple point: A blank file length is the smallest, white paper on the black dots, gray dots, color points more, the image file length is greater.

The above steps should be used in a comprehensive way, without any omissions. For example, I have seen a comic book release of the self-sweeping comics, hard to process the image is very clean, and even manually to the image grayscale level processing to 16 levels, but in the preservation of the time, do not know why it is in accordance with 256 levels of grayscale preservation, the results should only occupy 1/2 bytes per pixel, alive to occupy 1 bytes.

In terms of standardization, the standard specification for GIF format is "gif89a specification", the Open source project that supports LZW compression is giflib, and the open source project to eliminate LZW support to avoid patent disputes is libungif, However, many people directly read GIF files using the interface provided by Windows itself, and it is Microsoft's business to make a patent lawsuit. PNG standard specifications and open source projects are maintained by libpng organization, there is no multiplicity problem.

Third, JPEG (JPG)

JPEG full name is Joint Photographic Experts Group, translated into "Joint photographic Expert Group", wherein "union" means the International Telecommunication Telegraph Advisory Committee (Consultative Committee of the International Telephone and
Telegraph, CCITT) and the International Organization for Standardization (International Standardization Organization, ISO) are jointly composed of an image expert group. This expert group defines the JPEG international standard, ISO 10918, which is known as the JPEG format and the three-bit file extension is abbreviated to JPG as the image format implemented by this standard. So foreign flavor a bit of pronunciation is [d?? Peg], the natives of the pronunciation is "tick the chickens."

One of the most widely misunderstood misconceptions about JPEG is that this format is fit all's universal format, with images of whatever content stored as JPEG. In fact, this misunderstanding in turn to think about it is not difficult to understand: if the JPEG is really so omnipotent, other formats have died out, it is impossible to survive to the present.

In the first section of ISO 10918-1, scope (scope), the scope of application of JPEG is clearly defined: this CCITT recommendation | International standard was applicable to Continuous-tone-grayseale or colour-digital still image data. That is, JPEG is for "continuous tone (Continuous-tone)" grayscale or color images, in addition to the image is not the original intent of JPEG. Popular point, "continuous tone" of the image refers to the color or grayscale level richer, transition natural images, such as photographic works or realistic works. Images that contain few colors, have large areas of similar color, or have significant luminance differences, such as images scanned in black and white, or images that are manually drawn and filled with large chunks of solid color, are clearly not part of continuous-tone images, which are more appropriate to save as TIFF, GIF, or PNG than JPEG.

This "JPEG Magnum" misunderstanding is nothing for ordinary people, but it is meaningful for professionals. A few years ago I heard a rumor: A file electronic project before bidding, after several rounds of technical exchanges with various manufacturers, party a suddenly asked all scanned images are stored in the JPEG format, so many manufacturers uproar, have speculated that someone has been done. It is said that later in the tender process really strange, and the subject upside down. Tell me the reason the rumor has explained this to me is:

• Party A's business relies heavily on online access to scan generated electronic files, and the number of large amount of archives, whether from storage, transmission or OCR and other purposes, should be carefully measured to choose the most appropriate file format, will not affect the current and future business of party a negative impact.
• The project is not the first time in the industry to eat crabs, before the same industry has been a number of successful cases, after many arguments after the original scan image taken is JPEG + TIFF, that is, color image with JPEG, black and white image with TIFF. Convert the original scan format to PDF or other format as needed later. This uncharacteristically, for the reasons and vague, will naturally be suspected by some manufacturers of guidance.
• Have the strength of the scanning outsourcing professional high-speed scanners, can automatically determine whether the scan is black and white pages or color pages, black and white pages in the internal processing out of black and white images, compared to gray-scale after the use of software processing into black and white effect is better ("The Scan and Share tutorial" For home scanners, not in this case), the efficiency is also higher. and less powerful scanning subcontractors use a less professional scanner, in order to make the image look more "clean", usually increase the brightness of the scan, resulting in black turned gray, can only be saved as JPEG files. CX has a period of time to scan the clear version of the PDG looks shining white, the file length is also much larger, readfree on the people are guessing whether CX replaced a low-cost scanning subcontractor.

Of course rumors are rumors, I did not go to confirm. However, for a black-and-white image with a resolution of a DPI scan, the file length difference between the JPEG format and the CCITT G4 compressed TIFF format is indeed quite large, and anyone who has seen the Real clear version of the PDG should be aware of it.

Another common question for JPEG on the Web is "is JPEG lossy or lossless?" ”。 In fact, in ISO 10918-1, it is stipulated that JPEG can be lossy compression based on discrete cosine transform (discrete cosine TRANSFORM,DCT) or lossless compression based on DCT. But people with the purpose of JPEG is generally the pursuit of lossy compression brought about by the high compression ratio, JPEG lossless compression has become a chicken, only academic significance, in fact, but no one to use.

lossy compression than lossless compression ratio of the larger, the reason why it can be written a professional paper, the popular point is: Since the permit image loss, some people can not distinguish the visual image of the details could be thrown away, do not need to be like lossless compression as pinching irritate D, natural can be hard to press a little.

In the case of JPEG images with lossy compression, the final file length, in addition to the image pixel width, image pixel height, the number of bytes per pixel (grayscale 1 bytes, color 3 bytes), and whether the image is "clean", there is an important factor is the quality factor specified during compression. It should be noted that, even if the specified mass factor is 100%, the damage is lossy, and in any case it becomes non-destructive. In addition, the loss of image quality caused by lossy compression is cumulative, so if you want to edit the image more than once, or if you expect to edit the image later, you should not store the image in JPEG format to avoid unnecessary loss.

The various models of JPEG in ISO 10918-1 are described in detail, but for how to store JPEG compressed data with a file vague, only say that the data to be segmented storage, and in the segment header with 2-byte mark (marker) to explain what the data mean--feeling and now the XML is similar, It's just binary, not a readable character. Some common tags are defined in the standard, but also left alive, such as the APPN tag, which can be extended by the application itself, allowing for the extension of the APP0~APP16, a total of 16 tokens.

Currently more popular, the de facto standard JPEG file storage format is Eric Hamilton's proposed JPEG Files Interchange Format (jfif,jpeg file interchange), which is marked with a file header for the FF D8 FF E0, Starting with the 6th byte is four fixed character jfif. In fact, the file header of the Jfif file is fixed, in the early years of the domestic D version of the scanning comic format UFO format is to jfif the first few bytes of encryption, and then as a proprietary format began to sell, the results of minutes are experts see flaws.

With the popularity of digital cameras, another type of JPEG file storage format began to emerge in--exif format. This format does not contradict jfif, except that the file begins with the FF D8 FF E1, which begins with the 6th byte, which is the 4 characters of Exif. EXIF is more than JFIF this data segment marked with APP1 (FF E1), which stores thumbnails of photos, photo shooting parameters, and other data segments. In theory, it is possible to JFIF (using the APP0 tag, ff E0) and EXIF mixed storage in a file, because the data segment tag is not contradictory, but do not know why to separate out.

The APPN tag specified in ISO 10918-1 is a large backdoor that allows the application software to extend the stored data according to its own needs, as JFIF expands the app0,exif to extend the APP1, but on the other hand it can cause some confusion. One of the most famous examples of this is Adobe's expanded APP14, a JPEG image--jfif format for storing CMYK color space, a single-channel grayscale image, or a 3-channel color image, while the publication is widely used in 4-channel CMYK colors, As a result, Adobe, the leader of the publishing press, stepped forward to extend the APP14 to support the CMYK color space. Unfortunately, Adobe has little to say about its technical details, and most of the JPEG decoding software I see today doesn't seem to pay much attention to CMYK, and only uses a set of conversion formulas to convert from CMYK to RGB, and the result is that some of the images are decoded and the colors look weird- The APP14 segment can contain more than one parameter. I myself also on the basis of a large number of tests, only for CEP, CV and so selected two sets of conversion formula, at least decoding my hand CMYK color space JPEG image is not a problem. So from the compatibility considerations, it is recommended in Photoshop and other software output JPEG file, try not to choose CMYK color space, but first converted to RGB or grayscale and then output JPEG, otherwise in the third-party software decoding is not necessarily the color you want.

If you want to analyze the JPEG data, I recommend the cpicture, not only to view the data structure of JPEG, but also to edit EXIF information directly, or to rotate and crop jpeg images without damage. Of course, clipping is only a non-destructive condition that satisfies certain conditions.

In the area of JPEG encoding and decoding, the most famous open source project is JPEG LIB released by the Independent JPEG Group (IJG, Independent JPEG Group), its v6b version is stable, fault tolerant, and widely spread (more than the newer V8, V9), Even become a standard tool to check the compatibility of JPEG files-JPEG files that can be unpacked with IJG v6b, basically decoding in most software is fine, and vice versa. In Pdg2pic, I also use the V6B super fault tolerance to achieve "jpg repair" function--the problem of the JPEG compressed PDG file with v6b forcibly untied, and then re-encode, to avoid a little bit of a problem caused by the Ssreader JPEG decoder crashes, exit.

Another fame is smaller than IJG, but much faster is Intel's release of the Intel JPEG Library (IJL), which is specifically optimized for Intel processors, so it is first-rate in win-tel environments. There are only six functions in this tool (Ijlinit, Ijlfree, Ijlread, Ijlwrite, Ijlgetlibversion, Ijlerrorstr), and a complete VC + + instance is attached to the random document. As a result, VC programmers can use the JPEG without any brains.

The IJL has two major versions: version 1.5 and 2.0. The former is free and the latter charges. After 2.0 Ijl was replaced by the newly introduced UIC (v6.1 Image Unified) in Intel Integrated Performance Primitives (IPP) Codec.

Free Ijl v1.5 is a closed source software, but because it is more than IJG faster speed and spread very wide, but in my opinion, there are the following problems:

• Memory vulnerability. This DLL version with IJL can not see, to use the static Lib version to see: Every file opened, the VC will report 72 bytes (3 channel jpg) or 24 bytes (single channel jpg) of the vulnerability. Online An article explains how to fix this problem with inline assembly patching.
• The rotation parameters specified in EXIF are not supported. This problem is not big, can be decoded after the rotation, but need to decode the EXIF itself.
• The manual says that the CMYK color space is not supported, but the Jpgview example supports some CMYK JPEG, and some of the decoded colors are incorrect. This can also be corrected, and the same needs to be handled by itself.
• Fault tolerance is poor. Some data abnormal files can be decoded with IJG, but not with Ijl. The source code is easy to fix, without the source code is difficult.

IJL v2.0 provides some source code. But from my trial situation, in addition to fix the memory leak, other problems still exist, including some JPEG files with IJG can decode and Ijl can not decode the problem. But after all, there are some source code, so you can fix it yourself. This sentence to a different angle of understanding is: if there is no source code, the proposal should not use IJL, whether it is v1.5 or v2.0, lest because some files can not be decoded and be said. Of course it doesn't matter if you just use it yourself.

From the speed, on the current mainstream CPU Ijl v2.0 faster than v1.5, after all, can adopt the latest processor instructions.

Four, JPEG 2000

JPEG 2000 is an upgraded version of JPEG with the standard number ISO/IEC 15444. In addition to the pursuit of compression ratio, image quality, JPEG 2000 also put forward some of the new Dongdong Fox whistle, such as "area of interest (Regfon of-interest coding)" feature, that can arbitrarily specify the image of your area of interest compression quality, you can also select the specified part of the first decompression.

On the technical side, JPEG 2000 discards the block encoding used by the JPEG using discrete cosine transform (discrete cosine transform,dct) instead of the multi-resolution encoding method based on wavelet transform (wavelet transform). The mathematical foundation behind this is too abstruse, and it is interesting to read the monograph.

In ISO/IEC 15444, the panel also did not specify a specific implementation of JPEG 2000, but instead encouraged competition among the members. At present, the more famous open source projects include Michael D. Adams Jasper, openjpeg organization Libopenjpeg, the former seems to be more famous, used as a little more. But in my opinion, these two add up in speed, compatibility also compared with Kakadu software Kakadu.

One of the most interesting aspects of my personal interest in JPEG 2000 is that the compressed file length can be specified quantitatively, and both Kakadu and Jasper support this feature. Djvutoy when converting layer 3 DjVu into PDF, the foreground layer of IW44 compression, the background layer is converted to JPEG 2000 compression, and the compressed JPEG 2000 length is calculated according to the IW44 data stream length in the original DjVu to ensure that the file length difference is not small before and after the conversion. DjVu IW44 compression is also based on the wavelet transform, for conventional continuous-tone images in the same compression ratio as the JPEG 2000 effect, but in the low bit rate situation seems to be a better quality than JPEG 2000.

V. TIFF

The TIFF full name is the tag lmage file format, translated "Tagged image files", pronounced [TIF]. The standard was first proposed by Aldus, but now the publisher of the V6 version of the standard is Adobe. Tag means the same as the JPEG standard marker, that is, the TIFF file is also segmented storage, each paragraph at the beginning of the tag tag, and the current XML is almost, but binary.

Compared with the previous common image formats, I personally think that TIFF is characterized by:

• Supports multi-page packaging storage, where a TIFF file can contain multiple pages or even the entire book. It's kind of like a PDF.
• The support of color is quite rich, the general person is not clear at all. This may be related to the manufacturers involved in the TIFF standards for scanners, printer manufacturers. On the other hand, TIFF is popular in the fields of scanning, faxing, printing and publishing.
• The TIFF standard is more open, the custom space is relatively large, so TIFF is a big empty basket, each family is constantly stuffing their own things, in some cases, there will be compatibility issues. Probably for this reason, although TIFF files appear earlier, from Netscape to IE to Opera to Chrome, no HTML browser supports TIFF.

In terms of compression algorithms, the baseline (base line) provided by the TIFF standard is uncompressed, CCITT G3 compression (for black and white images), RLE compression (for grayscale, color images). "Do not compress" do not say, RLE is not what efficient compression algorithm, so in the ordinary people's impression, TIFF files have a "file relatively large" bad reputation.

In addition to the baseline section, the TIFF standard also defines extensions, which are also extended in addition to the CCITT G4 compression specifically for black-and-white images. However, it is up to the manufacturers to decide whether to support extensions, so if you want to maintain maximum compatibility, you should use as few extensions as possible. However, the algorithm of the TIFF baseline is too inefficient, so the CEP uses the extended portion of the CCITT G4 (for black and white images) and the LZW algorithm (for grayscale, color images) when coding tiff.

TIFF Open Source project is Libtiff, the project is frequently upgraded, in terms of standard extension is more vanguard, not only extended to support PNG zip compression algorithm, even jbig (equivalent to DjVu JB2 compression), JPEG 2000 is expanded in, However, these extended compression algorithms can only be solved by a corresponding version or a later version of Libtiff, not much compatibility.

There is a definition in the TIFF standard, but a compression algorithm with ambiguity in the actual use is JPEG compression. In the TIFF standard, the various table structures in JPEG and pixel data can be separated, and multiple pages can share the same table structure, so a complete jfif file converted to TIFF, will be decomposed into several parts, decoding the need to assemble each part and then decode. This is undoubtedly a challenge for software developers, and in my case, the JPEG compressed TIFF files produced by each scanner manufacturer can only be solved by their own software, when I was in a project in order to be compatible with the JPEG compressed TIFF files generated by different manufacturers Dickens, Finally, it is decided that grayscale, color image directly into JPEG files, no longer forced to uniformly stored in TIFF format. Libtiff also scoffed at this provision in the TIFF standard, called "Old jpeg," and expanded the new JPEG support in its own code, stipulating that the table structure is no longer stored separately, but that the entire JPEG file can be embedded in a TIFF.

In Tifftoy, the "File merge" section merges JPEG into TIFF, using the Libtiff tricks to embed the entire JPEG file into TIFF, the resulting TIFF file opened under Libtiff-based software should have no problem, at least my own CV, CEP, There is no problem with UV open. The file splitting section, when exporting an image of "old JPEG", uses the source code in Libtiff's tiff2pdf to compose a whole piece of the JPEG file and then write to the JPEG file, so that a lossless conversion can be achieved.

It is also because I know Libtiff's "all-encompassing" ambitions and status quo, and I will be determined to build on the tiff2pdf that it provides, when I develop freepic2pdf. It turns out that, at least, there are few more powerful and more professional ways of TIFF to PDF.

I'm not a publisher, so the color support for the Raccoon Fox whistle in TIFF is useless to me, but the CCITT G4 compression specifically for black and white images in TIFF is useful for me: I like to enlarge the scanned image of a book into a monochrome image and save it as a CCITT G4 compressed TIFF file.

CCITT G4 is a lossless compression algorithm that can only be used to compress black-and-white two-value images and not for grayscale or color images. The algorithm was first used in the field of fax, and now extends to the field of publishing. Fax field is usually passed is "black and white", so for the main, the middle of the dark text, the lines of the image, CCITT G4 has a good compression ratio, but if beyond this range, it may be more pressure. I heard a friend said that someone to develop the fax software, the results of a test when the software suddenly crash, call the past a question, the other side put a towel in the fax machine passed over. Coolman in the test of the cottage version of the PDG encoder, also a figure + scenery of the color picture jitter processing into half-tone black and white image (with the density of black dots to represent grayscale), the results found that compressed into CCITT G4 after the PDG than the original BMP file is much longer.

In a word: CCITT G4 as a lossless image compression algorithm, the more clean the screen, the smaller the file length.

Liu, DjVu

For the DjVu format, I think I'm in "DjVu to PDF", "No, djvu! "," DjVu, the hidden text in PDF "has already said enough, there is no need to waste saliva, just want to mention a few advice:

• If the original image has a resolution of less than a dpi, don't think about turning it into a djvu. If you have to turn, don't go around asking why the quality of the image you're turning out is so bad, it looks so blurry.
• In not really clear the 1-layer, 2-layer, 3-layer DjVu of the difference and the scope of application, thoroughly understand the djvu of the meaning of the various compression parameters before, or do not touch DjVu bar, lest astray mistake oneself. If not to touch, it is recommended to save the original scanned image, to the future of their own a chance to regret.
• If you see the DjVu format of the Chinese e-book There is a typo, or the stroke of the lack of arms and legs, should not be the first to suspect that the original book author or scanner has a problem, but should be suspected of making DjVu the guy has a problem, whether in the case of insufficient scanning resolution, forced to use a large compression ratio of lossy compression. A typical example is some fast version of the PDG.

VII. PDF

If I directly say that PDF is an image file format, it will normally be laughed by people. But given that people are now often turning images into PDFs, others are thinking about returning images from PDFs every day, so here's a look at the images in the PDF.

10 types of filter are specified in section 3.3 of the PDF Reference Sixth Edition, where Asciihexdecode filter, Ascii85decode filter will not be used for images, Crypt The filter is used for encryption, and the remaining 7 relationships with common image formats are:

Filter Name	The corresponding compression algorithm is commonly known	corresponding image format	Compression type	Description
Lzwdecode	Lzw	GIF, TIFF	Nondestructive	Typically used for indexed color (palette) images
Flatedecode	Zip	PNG, TIFF	Nondestructive	Indexed color images or True color images
Runlengthdecode	Rle	BMP, TIFF	Nondestructive	Typically used for monochrome images
Ccittfaxdecode	G3/g4	Tiff	Nondestructive	Dedicated to monochrome images
Jbig2decode	JBIG2	JBG, DjVu	Nondestructive	Dedicated to monochrome images
Dctdecode	Jpeg	JPG, TIFF	Lossy	For 256-level grayscale, 24-bit true color continuous tone images
Jpxdecode	JPEG2000	JP2, J2K, JPC	Lossy/Lossless	Standard for upgrading JPEG

As a result, the common image format can be converted to PDF without loss when converting from image to PDF. The method of judging lossless or lossy conversion is very simple: if the length of the file before and after the conversion is basically unchanged, it can be considered as lossless, otherwise it is lossy. Of course, the exception is the non-compressed BMP, TIFF in the conversion to LZW or zip compression, the length will be greatly reduced, or other formats of monochrome image conversion to CCITT G4, may also lead to changes in file length is more obvious.

When extracting images from PDFs, lossless conversions can be achieved if the color space of the image does not require any special conversion. But if the color space in the PDF doesn't match the color space in the image file format, that's another thing. To determine whether a software is lossless or lossy, it can be based on:

• The length of the file before and after extraction. If the length is almost the same, it may be lossless, otherwise it may be lossy.
• Whether you can only turn all images into one format. If all the images can only be converted to a format, or extract the image before the user to choose the format of the image saved, then do not ask, the software is lazy writing. If the software itself can automatically select the most appropriate export format based on the characteristics of the image data in the PDF, it will naturally no longer ask what format the user is going to export to.

It is because of the trouble of extracting pictures from the PDF, so it is generally not advocated to generate PDF files directly after scanning (some scanners bring their own software directly to generate PDF), but instead, it is recommended to scan the image first, then to the PDF as needed, and to save the original image file to meet other needs.

Viii. Summary

The front cost so much saliva, or summarize, the choice of image format to point to suggest it:

• For scanned images of black words on the white background, it is recommended to grayscale scan (unless you have a very professional scanner), scanning resolution is not less than the DPI, the condition then magnified to the DPI, and then subtractive into monochrome, saved as CCITT G4 compressed TIFF file, or lossless compressed DjVu file.
• If you want to play animations, you can only select GIF in common image formats.
• If you want to play transparent, you can only select GIF, PNG in the common image format, but GIF only supports color palette-based background color transparency, PNG also supports alpha channel transparency. For color palette-based GIF, PNG, transparency does not change the length of the file, increasing the alpha channel will increase the length of the PNG file.
• If it is an intermediate format for image processing, it is recommended to select BMP or PNG.
• If there is a large, solid color in the image, it is recommended to select GIF or PNG with subtractive processing.
• If you are a continuous-tone image, such as natural scenery, people and other photos, or color, grayscale scanned images, it is recommended to select JPEG.
• If you want to quantitatively control the size of the generated file, you can consider JPEG 2000.
• For the JPEG format, it is not recommended to choose a CMYK color space.
• For the TIFF format, it is not recommended to select a compression algorithm other than CCITT G3/g4, LZW.

For lossless compressed GIF, PNG, TIFF with CCITT G3/G4 or LZW compression algorithm, etc., the pixel size of the image is the same:

• The more "clean" the screen, the smaller the final file length.
• "Subtractive" can also effectively reduce the final file length, such as from 24-bit color reduced to 256 levels of gray, or from 256-level grayscale reduced to 16-level grayscale.

Finish

Talk about common image formats