什么文件格式可以表示每像素 48 或 64 位的未压缩光栅图像？
我正在 Windows 下创建屏幕截图并使用 LockBits 函数从 GDI+ 提取像素数据，然后将其写入文件。
为了最大限度地提高性能，我还：
- 使用相同的
PixelFormat作为源位图，以避免格式转换 - 使用
ImageLockModeUserInputBuf标志将像素数据提取到预分配的缓冲区中 - 这个预分配的缓冲区（由<代码>BitmapData::Scan0) 是内存映射文件的一部分（以避免再次复制像素数据。）
我还将编写读取该文件的代码，因此我可以使用（或发明）我希望的任何格式。然而，我更喜欢使用现有程序（最好是网络浏览器）能够读取的众所周知的格式，因为这意味着我可以在为其他程序（读取图像的程序）编写代码之前直观地确认图像是否正确。 ）
我已经成功地针对 PixelFormat32bppRGB 格式实现了此功能，该格式与 32bpp BMP 文件的格式匹配，因此如果我将像素数据直接提取到内存映射的 BMP 文件中，并在其前面加上 BMP 标头我得到了一个有效的 BMP 图像文件，可以在画图和大多数浏览器中打开。
不幸的是，我正在测试的一台机器返回 PixelFormat64bppPARGB 格式的像素（大概这是受视频适配器驱动程序的影响），并且没有相应的 BMP 像素格式。
转换为 16、24 或 32bpp BMP 格式会大大减慢程序速度（并且有损），因此我正在寻找一种无需转换即可使用此像素格式的文件格式，因此我可以直接提取到内存映射文件中正如我对 32bpp 格式所做的那样。
哪些光栅图像文件格式支持 48bpp（BGR 顺序，little-endian）和/或 64bpp（BGRA 顺序，little-endian）？
编辑
到目前为止，我已经排除了这些格式：
- BMP：深度限制为<=32bpp（否则将是完美匹配。）
- PNG ：样品顺序只能是RGBA。
- TIFF：样本顺序只能是 RGBA。
可能的部分解决方案：
- OpenEXR：仅限 48bpp。样本顺序按频道名称的字母顺序排列； BGR 适合，但 BGRA 不适合。
I am creating screenshots under Windows and using the LockBits function from GDI+ to extract the pixel data, which will then be written to a file.
To maximise performance I am also:
- Using the same
PixelFormatas the source bitmap, to avoid format conversion - Using the
ImageLockModeUserInputBufflag to extract the pixel data into a pre-allocated buffer - This pre-allocated buffer (pointed to by
BitmapData::Scan0) is part of a memory-mapped file (to avoid copying the pixel data again.)
I will also be writing the code that reads the file, so I can use (or invent) any format I wish. However I would prefer to use a well-known format that existing programs (ideally web browsers) are able to read, because that means I can visually confirm that the images are correct before writing the code for the other program (that reads the image.)
I have implemented this successfully for the PixelFormat32bppRGB format, which matches the format of a 32bpp BMP file, so if I extract the pixel data directly into the memory-mapped BMP file and prefix it with a BMP header I get a valid BMP image file that can be opened in Paint and most browsers.
Unfortunately one of the machines I am testing on returns pixels in PixelFormat64bppPARGB format (presumably this is influenced by the video adapter driver) and there is no corresponding BMP pixel format for this.
Converting to a 16, 24 or 32bpp BMP format slows the program down considerably (as well as being lossy) so I am looking for a file format that can use this pixel format without conversion, so I can extract directly into the memory-mapped file as I have done with the 32bpp format.
What raster image file formats support 48bpp (BGR order, little-endian) and/or 64bpp (BGRA order, little-endian)?
Edit
I have ruled out these formats so far:
- BMP: Depth limited to <=32bpp (would be a perfect match otherwise.)
- PNG: Sample order can only be RGBA.
- TIFF: Sample order can only be RGBA.
Possible partial solutions:
- OpenEXR: 48bpp only. Sample order is alphabetical by channel name; BGR fits but BGRA does not.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
似乎您需要标准格式的唯一原因是为了显示/测试目的。因此，滚动您自己的格式，但转换为 PNG 或 TIFF 进行显示。然后继续前进……生命短暂。
It seems that the only reason you need a standard format is for display/testing purposes. So roll your own format, but convert to PNG or TIFF for display. And then move on...life is short.
您真的想为 14 种不同的 PixelFormat 中的每一种实现并仔细测试单独的读取器吗？我知道到目前为止您只遇到过其中 2 个，但我保证市面上有几乎所有其他 12 个显卡。举一个简单的例子，将您的显示器设置为 256 色...
您说您想要为了最大化性能，但是将位图写入磁盘上的文件，即使使用内存映射，平均也会比将其转换为内存中与设备无关的位图花费更多的时间。另外，如果将 64 位位图转换为 32 位位图，生成的文件的写入时间将缩短一半，因此实际上可能会更快。
Do you really want to implement and carefully test separate readers for each of the 14 different PixelFormats? I know that so far you've only encountered 2 of them, but I guarantee there are video cards out there with almost all of the other 12. As one easy example, set your monitor to 256 colors...
You say that you want to maximize performance, but writing the bitmap to a file on disk, even with memory mapping, is going to take more time on average than the time it'd take to just convert it to a device-independent bitmap in memory. Plus if you convert the 64-bit bitmap to a 32-bit bitmap, the resulting file will take half as long to write, so it could actually be faster.
支持哪种位图颜色深度取决于您的 Windows 版本，这意味着 gdi+ 版本，而不是图形适配器。
您还可以使用 TIFF 或 PNG（png 有很多参数，我想您也可以告诉它进行未压缩）。您也可以考虑RAW格式。
具有 .net 包装器的图像库 imagemagick 支持数百种图像格式，无论您最终决定使用哪种格式，我确信它都支持它:)
Which bitmap color depths are supported depends on your windows version which means gdi+ version, not the graphics adapter.
You can also use TIFF or PNG (png has lots of parameters, I think you also can tell it to do uncompressed). You can also consider the RAW format.
The imaging library imagemagick which has an .net wrapper includes supports hundreds of image formats, no matter which format you decide to sue at the end, Iam sure it has support for it :)
当桌面和网络文件格式让您失望时，请考虑使用大武器：FITS （灵活的图像传输系统）或HDF5，甚至DICOM 也许。
When the desktop and web file formats let you down, think of reaching for the big guns: FITS (flexible image transport system) or HDF5, even DICOM perhaps.
巴布亚新几内亚？ 48 位 + alpha = 64 位
用于压缩，“可以仅使用未压缩的 deflate 块来存储未压缩的数据”
PNG? 48 bit + alpha = 64 bit
for the compression, "It is possible to store uncompressed data by using only uncompressed deflate blocks"
文件的读取与写入一样对性能至关重要吗？如果您可以轻松填充缓冲区，然后在方便时阅读，这应该是轻而易举的事。只需有一个代表数据格式的 1 字节标头，然后是您获得的原始数据。
Is the reading of the file just as performance critical as the writing? If you can fill a buffer easily, and then read at your convenience, this should be a cakewalk. Just have a 1byte header representing the data-format and then the raw data you got.