问题标签 [gdi+]

我需要专门加载保存为 blob 的 JPG 图像。GDI+ 可以很容易地从文件中检索图像，而不是从数据库中检索图像......

我的想法是在内存上绘制几个 Graphics 对象，并在绘制图像时将它们组合起来。

但我对如何做到这一点没有一个确切的想法。我应该使用 GraphicsContainer 的吗？或者将对象保存为元文件？（这些是临时对象，我想将它们保留在内存中）

我在 C++/MFC 应用程序中使用 GDI+，我似乎无法在调整窗口大小时避免闪烁。

我已经尝试了这些步骤：

• 返回 TRUE OnEraseBkGnd();
• 返回 NULL OnCtlColor()；
• 根据此代码使用双缓冲：

难道我做错了什么？还是有另一种方法可以实现这一目标？

有没有一种将 RAW 图像文件（尤其是 Canon CR2 和 Adob​​e DNG 文件）作为 GDI+ 位图读取的好方法，而且速度相当快？

我发现了一个在 WPF 下运行的示例，该示例将使用任何已安装的图像编解码器读取图像，然后将其显示在图像控件中。我修改了这个示例，通过将 WPF 图像写入 MemoryStream 并从中创建位图来创建 GDI+ 位图。但是这个过程很慢！慢得可怕！在我的电脑上打开一张简单的图片大约需要 10 秒。此解决方案还需要对 WPF 程序集的引用，这感觉不对，尤其是因为我想在 ASP.NET 项目中运行代码。

有些程序会对图像进行批量转换，但我更喜欢在请求时动态转换图像。

那么，有什么建议吗？

我有一系列需要即时裁剪的 GIF，我在 C# 中使用 HTTP 处理程序，因此我可以更好地封装代码 - 为结果提供缓存等。

Image目前，当我通过对象将现有图像绘制到新图像时，Graphics所有透明度都会丢失。

我尝试了各种技术来尝试保持透明度，但无济于事。

我尝试过的事情：

• 使用MakeTransparent (Color)方法调用
• 使用andImageAttriutes的组合ColorMapSetColorKey

我真的不想开始使用不安全的运算符或 Win32 调用。

有任何想法吗？

我正在从文件加载位图图像。当我尝试将图像保存到另一个文件时，出现以下错误“GDI+ 中发生一般错误”。我相信这是因为文件被图像对象锁定。

好的，所以尝试调用 Image.Clone 函数。这仍然会锁定文件。

唔。接下来我尝试从 FileStream 加载位图图像并将图像加载到内存中，这样 GDI+ 就不会锁定文件。这很好用，除非我需要使用 Image.GetThumbnailImage 方法生成缩略图，它会引发内存不足异常。显然我需要保持流打开以停止此异常，但如果我保持流打开，则文件保持锁定状态。

所以这种方法不好。最后，我创建了该文件的副本。所以现在我有两个版本的文件。1 我可以在我的 c# 程序中锁定和操作。这个其他原始文件保持解锁状态，我可以将修改保存到其中。这样做的好处是即使在保存更改后也可以恢复更改，因为我正在操作无法更改的文件副本。

当然有更好的方法来实现这一点，而不必拥有 2 个版本的图像文件。有任何想法吗？

我在 .Net 中有一些代码可以使用 GDI+ 绘制一些文本内容。我使用 GraphicsUnit.Point 来调整文本大小。它在屏幕上运行得非常好，即使打印它也是如此。

我被要求制作一个生成 PDF 的系统，并且我得到了 ComponentOne 的 PDF 控件。它具有与 GDI+ 类似的界面。

问题是：字体大小不起作用。如果我使用 GraphicsUnit.Point，文本会小得多，并且文本下方会出现空白。当我使用 GraphicsUnit.World 时，文本仍然很小，但文本下方没有多余的空白空间。

我想了解如何将 GraphicsUnit.World 转换为 GraphicsUnit.Point。

所有帮助将不胜感激。

谢谢

我想将 BYTE* 转换为 gdi+ Image 对象。

我怎样才能做到这一点？

BYTE* 似乎是一个 Dib 点。

我发现 Image 有一个名为 Image::FromStream() 的方法可能会有所帮助，但我找不到任何关于如何将 BYTE* 转换为 IStream 对象的参考。我怎样才能做到这一点？

提前致谢！

实际上，很难相信 MS 提供了 IStream 接口，但没有提供任何实现该接口的 c++ MemoryStream 类。

我正在使用 GDI+ Graphic 将 4000*3000 的图像绘制到屏幕上，但它真的很慢。大约需要 300 毫秒。我希望它只占用不到 10 毫秒。

// - - - - - - - - - - - - - - - - - - - - - - // 这部分大约需要300ms，太可怕了！

//------------------------------------------------------

我不能使用 CachedBitmap，因为我想稍后编辑位图。

我该如何改进它？还是有什么不对？

这个原生 GDI 函数也将图像绘制到屏幕上，它只需要 1 毫秒：

//------------------------------------------------ --------------

如果我想使用 StretchDIBits，我需要传递 BITMAPINFO，但是如何从 Gdi+ 位图对象中获取 BITMAPINFO？我通过 FreeImage lib 进行了实验，我使用 FreeImageplus 对象调用 StretchDIBits，它绘制得非常快。但是现在我需要绘制Bitmap，并在Bitmap的位数组上写一些算法，如果我有一个Bitmap对象，我怎么能得到BITMAPINFO呢？真的很烦-_______________-|

谢谢大家的解答，其实我并不疑惑draw 1024*768像素比100*100像素慢...就是这么简单的一个逻辑..让我不解的是DrawImage的插值算法可能很慢，虽然存在很多更好的算法，它的解码器似乎可以从具有一定分辨率的 jpg 解码，这真的很酷，我搜索了一段时间但没有找到任何免费的库来做到这一点......

真的很奇怪！我在 Paint 方法中添加了以下代码。c:\1.jpg 为5M jpg文件，约4000*3000

//------------------------------------------------ --------------

上面的速度真的很快！甚至是实时的！我认为解码 5m JPG 不会那么快！

//------------------------------------------------ --------------

上面的代码变得非常慢

//------------------------------------------------ --------------

如果我添加 Bitmap = Bitmap::FromFile(L"c:\1.jpg", true); //进入构造

离开

在 OnPaint 方法中，代码还是有点慢~~~

//------------------------------------------------ ------------------

与解码相比，drawImage 的过程真的很慢……

他们为什么以及如何做到这一点？微软给负责解码的人支付的工资是负责编写绘图图像的人的两倍吗？