在哪里可以找到有关位图的详细介绍
我必须编写一些使用位图的代码。有没有关于该主题的良好介绍可以帮助我开始？
I have to write some code working with bitmaps. Is there a good introduction to the subject to get me started?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
最初发布于 每个开发人员应该做什么了解位图（用图片更好地格式化）。
事实上，每个开发人员在编程中有时都会使用位图。或者，如果不在他们的节目中，那么也可以在网站、博客或家庭照片中。然而，我们许多人并不知道 GIF、JPEG 或 PNG 文件之间的权衡，而且它们之间存在一些重大差异。这是一篇关于基础知识的简短文章，对于大多数人来说已经足够了，对于其他人来说也是一个良好的开始。其中大部分内容是我作为游戏开发人员（包括敌国）学到的，你确实需要对图形有深入的了解。
位图从根本上存储每个像素的颜色。但这有三个关键组成部分：
我们都熟悉 RGB，它
存储红色、绿色和蓝色的
每种颜色的成分。这是
实际上是最不有效的方法
正如人眼所能看到的微妙之处
某些部分的差异
色谱比其他的更多。
对于许多人来说这也是低效的
对颜色的常见操作，例如
提亮它。但这是
最简单最常见的
编程任务等已成为
标准。
每个像素。这对于
非矩形图像的边缘。一个
对角线，为了呈现最佳效果，将
是以下颜色的组合
的线条和颜色
底层像素。每个像素需要
具有一定的透明度
（或实际上不透明度）设置为 0%
（显示底层像素）至 100%
（仅显示来自
图像）。
是有关图像的信息
范围可以从颜色表和
向业主提出的决议
图像。
压缩
位图需要大量数据。或者更准确地说，它们可以占用大量字节。多年来，压缩一直是新位图格式的主要驱动力。压缩有三种风格：调色板压缩、有损压缩和压缩。无损。
在早期，减少调色板是最常见的方法。一些程序使用黑白位图。白色，所以每像素 1 位。现在就是把它挤出来。进入 Windows 3.1 时代，16 色图像（4 位/像素）仍在广泛使用。但主要用途是位图的 8 位/256 色。这 256 种颜色将映射到作为位图一部分的调色板，并且该调色板为每个条目保存一个 24 位颜色。这使得程序可以从全光谱中选择最能显示图片的 256 种颜色。
这种方法非常好，但对于表面过渡非常缓慢的平坦表面来说大多失败。它还在早期遇到了网络和窗口操作系统的一个主要问题——因为视频卡也是 8 位系统，整个屏幕只有一个调色板。对于拥有整个屏幕的游戏来说这很好，但对于来自不同来源的图像共享屏幕的情况则不然。解决方案是创建一个标准的 Web 调色板，并且如果存在调色板争用，大多数浏览器等都会使用该调色板。
最后，还有一些中间解决方案，例如 16 位/像素，它确实提供了整个光谱，但粒度较粗，人眼可以看到色调变化的跳跃。由于内存价格下降且显卡在一年内从 8 位快速跃升至 24 位，因此这种方法几乎没有被使用。
接下来是有损压缩。压缩是查找文件中重复的模式，然后在第二种情况下仅指向第一次运行。如果您有 20 个像素的运行，其中第二次运行的唯一区别是其中两个像素的红色值增加了 1，该怎么办？人眼无法看出这种差异。因此，您更改第二次运行以匹配第一次运行，瞧，您可以压缩它。大多数有损压缩方案都允许您设置有损级别。
当您使用单一颜色来指定透明度时，这种方法确实存在一个严重的问题。如果该颜色移动一位，它就不再是透明的。这就是为什么有损格式几乎专门用于图片而不是游戏。
终于无损了。这是程序将鼻涕从图像中压缩出来而不会丢失信息的地方。我不会深入探讨这是什么/如何进行，只是想指出压缩图像比解压缩图像花费更多的时间。因此可以快速显示压缩图像。压缩图像——没那么快。这可能会导致出于性能原因您不想即时以无损格式存储的情况。
透明度
透明度分为三种类型。 （如果您认识一位创建网页内容的艺术家，请让他们阅读本节。令人惊讶的是，在这个问题上毫无头绪的人数量如此之多。）第一种风格是没有——位图是一个矩形，并且会遮盖其下方的每个像素。
第二种是位图，其中指定的颜色值（大多数使用洋红色，但可以是任何颜色）表示透明。因此会绘制其他颜色，并且不会绘制洋红色像素，因此会显示底层像素。这需要在选定的背景颜色上渲染图像，并且边缘像素应该部分是图像，部分是背景像素，然后部分是背景颜色。您可以在实践中看到 256 种颜色的图标，它们在白色背景上具有完美的边缘，但在黑色背景上的边缘上却有奇怪的白色光晕效果。
第三种风格是每个像素 8 位透明度（即从 0 – 100% 的 256 个值）。这就是 32 位位图的含义，它是 24 位颜色和 8 位透明度。这提供了比人眼所能辨别的更精细的图像。与艺术家交谈时需要注意一点——他们都可以生成“32 位位图”。但其中 95% 的产品将每个像素设置为 100% 不透明度，并且对整个过程和透明度的需求一无所知。 （游戏艺术家是一个值得注意的例外 - 他们一直这样做。）有关如何正确执行此操作的一个很好的示例，请查看 Icon Experience - 我认为他们的位图非常棒（我们在 AutoTag 中使用它们）。
分辨率
许多格式都有分辨率，通常描述为 DPI（每英寸点数）。查看照片时，这通常不是问题。但以呈现为位图的图表为例。您希望图表中的文本可读，并且您可能希望它在 600 DPI 打印机上清晰地打印，但在屏幕上您希望仅使用 96 个像素来显示占据一英寸的 600 个点。该决议提供了这种能力。 DPI 在某些格式中不存在，而在其他格式中是可选的（注意：任何格式都不需要它，但在 PNG 中丢失它是不常见的）。
DPI 的重要问题是，在渲染位图时，用户可能希望能够放大和/或以打印机的分辨率打印，但以较低的分辨率显示 - 您需要为调用程序提供设置深度PI。有一个非常强大的图表程序，除了在显示器上进行标准查看之外没有任何用处，因为它以 96 DPI 渲染，仅此而已。不要限制你的用途。
文件格式
好的，那么您应该使用什么文件格式呢？让我们从最有用到最没用。
PNG – 32 位（或更少）、无损压缩、小文件大小 – 有什么不喜欢的。某些浏览器的旧版本（例如 Internet Explorer）会显示灰白色的透明像素，但新版本可以正确处理它。使用此功能（在 32 位模式下使用 8 位实现透明度）。
ICO – 这是用于表示桌面上的应用程序等的图标文件。它是位图的集合，每个位图可以具有任何分辨率和位深度。对于这些，仅使用 16x16 到 256x256 的 32 位 png 文件来构建它。如果您的操作系统或应用程序需要较小的位深度，它将即时减少 – 并保持 8 位透明度。
JPEG – 仅 24 位（即无透明度）、有损、文件大小小。除非有大量用户使用旧浏览器，否则没有理由使用此格式。这不是一个坏格式，但它比 PNG 差，没有优势。
GIF – 8 位、有损、文件大小非常小。 GIF 有两个独特的功能。首先，您可以将多个 GIF 位图放入一个文件中，并在每个位图之间设置延迟。然后它将播放那些为您提供动画位图的内容。这适用于 0.9 版本之前的所有浏览器，并且文件大小比 Flash 文件小。另一方面，它只有 8 位，在当今世界往往看起来很差（尽管有些艺术家只需 8 位就可以做出惊人的事情）。它还将颜色设置为透明，因此它本身支持透明度（开/关品种）。如果您想要动画位图而不需要 Flash 开销或者带宽是一个主要问题，那么这非常有用。
BMP（也称为 DIB）——从 1 位到 32 位、无损、大文件大小。有一种情况可以使用它——当速度是最重要的问题时。许多 2-D 游戏程序，尤其是在当今的显卡出现之前，会将所有位图存储为 BMP/DIB，因为不需要解压缩，并且当您尝试以 60 帧/秒的速度显示游戏时，节省时间至关重要。
TIFF – 任何位深度、任何压缩（有损或无损）、一切，包括厨房水槽 – 并不比 PNG 更好。基本上，政府和一些大公司决定他们需要一个“标准”，以便将来的软件仍然可以读取这些旧文件。整个争论毫无意义，因为巴布亚新几内亚符合要求。但对于某些客户（例如联邦政府）来说，它是 TIFF 而不是 PNG。当客户要求时使用它（但否则使用 PNG）。
其他一切 - 已过时。 （注意：许多人不同意我提出其他格式如何更小。它们只是内存和磁盘空间接近空闲。）如果您正在创建位图编辑器，那么无论如何都支持读/写每种格式。但对于其他用途 – 坚持上面的 2+4 格式。
Originally posted at What every developer should know about bitmaps (formatted better there with pictures).
Virtually every developer will use bitmaps at times in their programming. Or if not in their programming, then in a website, blog, or family photos. Yet many of us don't know the trade-offs between a GIF, JPEG, or PNG file – and there are some major differences there. This is a short post on the basics which will be sufficient for most, and a good start for the rest. Most of this I learned as a game developer (inc. Enemy Nations) where you do need a deep understanding of graphics.
Bitmaps fundamentally store the color of each pixel. But there are three key components to this:
of us are familiar with RGB where it
stores the Red, Green, & Blue
component of each color. This is
actually the least effective method
as the human eye can see subtle
differences on some parts of the
color spectrum more than others.
It's also inefficient for many
common operations on a color such as
brightening it. But it is the
simplest for the most common
programming tasks and so has become
the standard.
each pixel. This is critical for the
edge of non-rectangular images. A
diagonal line, to render best, will
be a combination of the color from
the line and the color of the
underlying pixel. Each pixel needs
to have its level of transparency
(or actually opacity) set from 0%
(show the underlying pixel) to 100%
(show just the pixel from the
image).
is informat about the image which
can range from color tables and
resolution to the owner of the
image.
Compression
Bitmaps take a lot of data. Or to be more exact, they can take up a lot of bytes. Compression has been the main driver of new bitmap formats over the years. Compression comes in three flavors, palette reduction, lossy & lossless.
In the early days palette reduction was the most common approach. Some programs used bitmaps that were black & white, so 1 bit per pixel. Now that's squeezing it out. And into the days of Windows 3.1 16 color images (4 bits/pixel) were still in widespread use. But the major use was the case of 8-bits/256 colors for a bitmap. These 256 colors would map to a palette that was part of the bitmap and that palette held a 24-bit color for each entry. This let a program select the 256 colors out of the full spectrum that best displayed the picture.
This approach was pretty good and mostly failed for flat surfaces that had a very slow transition across the surface. It also hit a major problem early on with the web and windowed operating systems – because the video cards were also 8-bit systems with a single palette for the entire screen. That was fine for a game that owned the entire screen, but not for when images from different sources shared the screen. The solution to this is a standard web palette was created and most browsers, etc. used that palette if there was palette contention.
Finally, there were some intermediate solutions such as 16-bits/pixel which did provide the entire spectrum, but with a coarse level of granularity where the human eye could see jumps in shade changes. This found little usage because memory prices dropped and video cards jumped quickly from 8-bit to 24-bit in a year.
Next is lossy compression. Compression is finding patterns that repeat in a file and then in the second case just point back to the first run. What if you have a run of 20 pixels where the only difference in the second run is two of the pixels are redder by a value of 1? The human eye can't see that difference. So you change the second run to match the first and voila, you can compress it. Most lossy compression schemes let you set the level of lossiness.
This approach does have one serious problem when you use a single color to designate transparency. If that color is shifted by a single bit, it is no longer transparent. This is why lossy formats were used almost exclusively for pictures and never in games.
Finally comes lossless. This is where the program compresses the snot out of the image with no loss of information. I'm not going to dive into what/how of this except to bring up the point that compressing the images takes substantially more time than decompressing them. So displaying compressed images – fast. Compressing images – not so fast. This can lead to situations where for performance reasons you do not want to store in a lossless format on the fly.
Transparency
Transparency comes in three flavors. (If you know an artist who creates web content – have them read this section. It's amazing the number who are clueless on this issue.) The first flavor is none – the bitmap is a rectangle and will obscure every pixel below it.
The second is a bitmap where a designated color value (most use magenta but it can be any color) means transparent. So other colors are drawn and the magenta pixels are not drawn so the underlying pixel is displayed. This requires rendering the image on a selected background color and the edge pixels that should be partially the image and partially the background pixel then are partially the background color. You see this in practice with 256 color icons where they have perfect edges on a white background yet have a weird white halo effect on their edges on a black background.
The third flavor is 8 bits of transparency (i.e. 256 values from 0 – 100%) for each pixel. This is what is meant by a 32-bit bitmap, it is 24-bits of color and 8 bits of transparency. This provides an image that has finer graduations than the human eye can discern. One word of warning when talking to artists – they can all produce "32-bit bitmaps." But 95% of them produce ones where every pixel is set to 100% opacity and are clueless about the entire process and the need for transparency. (Game artists are a notable exception – they have been doing this forever.) For a good example of how to do this right take a look at Icon Experience – I think their bitmaps are superb (we use them in AutoTag).
Resolution
Many formats have a resolution, normally described as DPI (Dots Per Inch). When viewing a photograph this generally is not an issue. But take the example of a chart rendered as a bitmap. You want the text in the chart to be readable, and you may want it to print cleanly on a 600 DPI printer, but on the screen you want the 600 dots that take up an inch to display using just 96 pixels. The resolution provides this ability. The DPI does not exist in some formats and is optional in others (note: it is not required in any format, but it is unusual for it to be missing in PNG).
The important issue of DPI is that when rendering a bitmap the user may want the ability to zoom in on and/or to print at the printer's resolution but display at a lower resolution – you need to provide the ability for the calling program to set the DPI. There's a very powerful charting program that is useless except for standard viewing on a monitor – because it renders at 96 DPI and that's it. Don't limit your uses.
File formats
Ok, so what file formats should you use? Let's go from most to least useful.
PNG – 32-bit (or less), lossless compression, small file sizes – what's not to like. Older versions of some browsers (like Internet Explorer) would display the transparent pixels with an off-white color but the newer versions handle it properly. Use this (in 32-bit mode using 8 bits for transparency) for everything.
ICO – This is the icon file used to represent applications on the desktop, etc. It is a collection of bitmaps which can each be of any resolution and bit depth. For these build it using just 32-bit png files from 16x16 up to 256x256. If your O/S or an application needs a lesser bit depth, it will reduce on the fly – and keep the 8 bits of transparency.
JPEG – 24-bit only (i.e. no transparency), lossy, small file sizes. There is no reason to use this format unless you have significant numbers of people using old browsers. It's not a bad format, but it is inferior to PNG with no advantages.
GIF – 8-bit, lossy, very small file sizes. GIF has two unique features. First, you can place multiple GIF bitmaps in a single file with a delay set between each. It will then play through those giving you an animated bitmap. This works on every browser back to the 0.9 versions and it's a smaller file size than a flash file. On the flip side it is only 8 bits and in today's world that tends to look poor (although some artists can do amazing things with just 8 bits). It also has a set color as transparent so it natively supports transparency (of the on/off variety). This is useful if you want animated bitmaps without the overhead of flash or if bandwidth is a major issue.
BMP (also called DIB) – from 1 up to 32-bit, lossless, large file sizes. There is one case to use this – when speed is the paramount issue. Many 2-D game programs, especially before the graphics cards available today, would store all bitmaps as a BMP/DIB because no decompression was required and that time saving is critical when you are trying to display 60 frames/second for a game.
TIFF – any bit depth, any compression (lossy or lossless), everything including the kitchen sink – and no better than PNG. Basically the government and some large companies decided they needed a "standard" so that software in the future could still read these old files. This whole argument makes no sense as PNG fits the bill. But for some customers (like the federal government), it's TIFF instead of PNG. Use this when the customer requests it (but otherwise use PNG).
Everything Else - Obsolete. (Note: Many disagree with me on this bringing up how other formats are smaller. They are but memory & disk space is close to free.) If you are creating a bitmap editor then by all means support reading/writing every format around. But for other uses – stick to the 2+4 formats above.
如果您想了解有关文件格式或使用的算法的信息，拥有 a 外观 位于这些链接。
If you want to know something about the file formats or the algorithms used, have a look at these links.