В настоящее время я использую FreeImage для загрузки PFM в программу, которая в противном случае использует IplImages (старый тип данных для OpenCV).Вот пример того, что я делаю (игнорируйте часть о том, что img - это массив матов, это связано с другим кодом).
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-порядке, уже упорядоченном на диске, а это не так, и не должно быть.
Есть мысли?Есть ли ошибка в чтении PFM во FreeImage, или здесь происходит что-то более тонкое?Спасибо.