0

我目前正在使用 FreeImage 将 PFM 加载到一个使用 IplImages（OpenCV 的旧数据类型）的程序中。这是我正在做的一个示例（忽略有关 img 是 Mats 数组的部分，这与其他一些代码有关）。

FIBITMAP *src;

// Load a PFM file using freeimage
src = FreeImage_Load(FIF_PFM, "test0.pfm", 0);

Mat* img;
img = new Mat[3];

// Create a copy of the image in an OpenCV matrix (using .clone() copies the data)
img[1] = Mat(FreeImage_GetHeight(src), FreeImage_GetWidth(src), CV_32FC3, FreeImage_GetScanLine(src, 0)).clone();

// Flip the image verticall because OpenCV row ordering is reverse of FreeImage
flip(img[1], img[1], 0);

// Save a copy
imwrite("OpenCV_converted_image.jpg", img[1]);

奇怪的是，如果我使用 FreeImage 来加载 JPEG，而不是将 FIF_PFM 更改为 FIF_JPEG 并将 CV_32FC3 更改为 CV_8U，这可以正常工作，即复制的图片保持不变。这让我认为 OpenCV 和 FreeImage 普遍同意 RGB 通道的顺序，并且问题与 PFM 以及它们是非标准化格式有关。

我正在加载的 PFM 是用这段代码编写的（在“局部直方图均衡”下），它似乎以 RGB 顺序编写它们，尽管我可能错了。它只是从 MATLAB 3D 双精度矩阵中获取数据，并使用 fwrite 将其转储到文件中。此外，如果我修改该代码以编写 PPM，然后在 IrfanView 中查看它们，它们看起来是正确的。

所以，这让我认为 FreeImage 正在将文件数据作为 BGR 排序在磁盘上，它不是，也不应该是。

有什么想法吗？FreeImage 对 PFM 的读取是否存在错误，或者这里是否发生了更微妙的事情？谢谢。

4

1 回答 1

1

好吧，我从来没有真正解决过这个问题。长话短说，FreeImage 和 OpenCV 在加载大多数图像格式时就颜色通道顺序 (BGR) 达成一致，但在加载 PFM 时却不一致。我只能假设 FreeImage 的制造商因此误解了 PFM 公认的不太固定的规格。由于我只使用 FreeImage 来读/写 PFM，并且在使用 OpenCV 函数处理后将数据返回到 FreeImage 结构中非常复杂，因此我编写了自己的 PFM 读/写代码，结果非常简单。

于 2011-02-18T23:07:26.267 回答