OpenCV可以在内存缓冲区或文件指针中使用。

20

openCV中的两个函数cvLoadImage和cvSaveImage接受文件路径作为参数。

例如,保存图像时使用cvSaveImage("/tmp/output.jpg", dstIpl)将其写入磁盘。
有没有办法提供一个已经在内存中的缓冲区?因此,输出图像将存储在内存中而不是磁盘上。
我还想知道这个问题是否适用于cvSaveImage和cvLoadImage(读写内存缓冲区)。谢谢!
我的目标是将编码(jpeg)版本的文件存储在内存中。同样适用于cvLoadImage,我想将已经在内存中的jpeg加载到IplImage格式中。


1
你想将图像写入内存吗?但dstIpl已经在内存中了,您希望实现什么目标?您可以通过dstIpl->imageData或->data等方式访问图像数据。 - mpen
同样地,您可以操作iplImage的数据缓冲区来加载已经在内存中的图像...只需要是BGR格式。 - mpen
我认为原帖作者想要对图像进行编码,但又想避免磁盘读写。 - M456
1
这种技术在需要将压缩图像嵌入到较大二进制文件中时特别有用。例如,PDF文件可以嵌入PNG和JPG图像。直接创建PDF文件的程序希望避免在磁盘上创建临时PNG或JPG文件,然后将它们传输到PDF流中。 - Mr Fooz
1
澄清一下:是的,我想将文件的编码版本(例如jpeg)存储在内存中,而不是写入磁盘。 - The Unknown
6个回答

19

这对我起作用了

// decode jpg (or other image from a pointer)
// imageBuf contains the jpg image
    cv::Mat imgbuf = cv::Mat(480, 640, CV_8U, imageBuf);
    cv::Mat imgMat = cv::imdecode(imgbuf, CV_LOAD_IMAGE_COLOR);
// imgMat is the decoded image

// encode image into jpg
    cv::vector<uchar> buf;
    cv::imencode(".jpg", imgMat, buf, std::vector<int>() );
// encoded image is now in buf (a vector)
    imageBuf = (unsigned char *) realloc(imageBuf, buf.size());
    memcpy(imageBuf, &buf[0], buf.size());
//  size of imageBuf is buf.size();

有人问我是否可以提供使用C语言而非C++语言的版本:

#include <opencv/cv.h>
#include <opencv/highgui.h>

int
main(int argc, char **argv)
{
    char *cvwin = "camimg";

    cvNamedWindow(cvwin, CV_WINDOW_AUTOSIZE);

    // setup code, initialization, etc ...
    [ ... ]

    while (1) {      
        // getImage was my routine for getting a jpeg from a camera
        char *img = getImage(fp);
        CvMat mat;

   // substitute 640/480 with your image width, height 
        cvInitMatHeader(&mat, 640, 480, CV_8UC3, img, 0);
        IplImage *cvImg = cvDecodeImage(&mat, CV_LOAD_IMAGE_COLOR);
        cvShowImage(cvwin, cvImg);
        cvReleaseImage(&cvImg);
        if (27 == cvWaitKey(1))         // exit when user hits 'ESC' key
        break;
    }

    cvDestroyWindow(cvwin);
}

imdecode的意图不是解码图像吗?那么为什么需要将imageBuf放置在cv::mat中?我遇到了问题,我有一个包含通过网络加载的原始数据(它是一个tiff图像)的unsigned char *,但在对原始数据进行imdecode后,Mat具有其mat.data == 0且没有给出任何错误。 - Poul K. Sørensen
@pksorensen 需要将 imageBuf 放入 Mat 中,以便它可以作为参数被 imdecode() 接受,除非有 C++ 魔法可以将其转换为 imdecode() 所需的 InputArray。不解码 TIFF 图像的原因可能是 (1) 传递给 imgdecode 的 Mat 的 rows*cols 小于 1,(2) 您的 OpenCV 库未编译 TIFF 支持或 (3) TIFF 解码器未将您的图像缓冲区识别为有效的 TIFF 图像。 - codeDr

15

在SVN版本的该库中有几个未经记录的函数:

CV_IMPL CvMat* cvEncodeImage( const char* ext, 
                              const CvArr* arr, const int* _params )

CV_IMPL IplImage* cvDecodeImage( const CvMat* _buf, int iscolor )

最新的检查消息显示他们正在为bmp,png,ppm和tiff(仅编码)进行本地编码/解码。

或者,您可以使用标准的图像编码库(例如libjpeg),并操纵IplImage中的数据以匹配编码库的输入结构。


10
请不要依赖未记录的函数,否则将为自己创建一个维护噩梦。它们未被记录的原因是因为设计者不希望它们随时间稳定下来。它们可能会在下一个版本中消失! - j_random_hacker
3
我认为在任何开发版本中都隐含了警告。此外,文档一直是OpenCV的问题,许多稳定的函数仍未被记录。 - M456

1

我假设你正在Linux上工作。来自libjpeg.doc的简要概述:

JPEG压缩操作的大致轮廓是:
分配并初始化一个JPEG压缩对象
指定压缩数据的目标(例如,一个文件)
设置压缩参数,包括图像大小和颜色空间

jpeg_start_compress(...);
在还有扫描行未写入之前:
jpeg_write_scanlines(...);

jpeg_finish_compress(...);
释放JPEG压缩对象

实现您想要的功能的真正技巧是提供一个在jpeglib.h中定义的自定义“数据目标(或源)管理器”:

struct jpeg_destination_mgr {
  JOCTET * next_output_byte;    /* => next byte to write in buffer */
  size_t free_in_buffer;        /* # of byte spaces remaining in buffer */

  JMETHOD(void, init_destination, (j_compress_ptr cinfo));
  JMETHOD(boolean, empty_output_buffer, (j_compress_ptr cinfo));
  JMETHOD(void, term_destination, (j_compress_ptr cinfo));
};

基本上设置好源和/或目标是您想要的内存缓冲区,那么您应该就可以开始了。

另外一件事,这篇文章可能会更好,但libjpeg62文档实际上非常好。只需apt-get libjpeg62-dev,然后阅读libjpeg.doc并查看example.c。如果遇到问题并且无法使某些内容正常工作,请再次发布,我相信有人会能够帮助您。


0

从内存缓冲区加载文件所需的全部内容均在不同的源管理器(libjpeg)中。我已在Ubuntu 8.10中测试了以下代码。

/******************************** First define mem buffer function bodies **************/
<pre>
/*
 * memsrc.c
 *
 * Copyright (C) 1994-1996, Thomas G. Lane.
 * This file is part of the Independent JPEG Group's software.
 * For conditions of distribution and use, see the accompanying README file.
 *
 * This file contains decompression data source routines for the case of
 * reading JPEG data from a memory buffer that is preloaded with the entire
 * JPEG file.  This would not seem especially useful at first sight, but
 * a number of people have asked for it.
 * This is really just a stripped-down version of jdatasrc.c.  Comparison
 * of this code with jdatasrc.c may be helpful in seeing how to make
 * custom source managers for other purposes.
 */

/* this is not a core library module, so it doesn't define JPEG_INTERNALS */
//include "jinclude.h"
include "jpeglib.h"
include "jerror.h"


/* Expanded data source object for memory input */

typedef struct {
  struct jpeg_source_mgr pub;   /* public fields */

  JOCTET eoi_buffer[2];     /* a place to put a dummy EOI */
} my_source_mgr;

typedef my_source_mgr * my_src_ptr;


/*
 * Initialize source --- called by jpeg_read_header
 * before any data is actually read.
 */

METHODDEF(void)
init_source (j_decompress_ptr cinfo)
{
  /* No work, since jpeg_memory_src set up the buffer pointer and count.
   * Indeed, if we want to read multiple JPEG images from one buffer,
   * this *must* not do anything to the pointer.
   */
}


/*
 * Fill the input buffer --- called whenever buffer is emptied.
 *
 * In this application, this routine should never be called; if it is called,
 * the decompressor has overrun the end of the input buffer, implying we
 * supplied an incomplete or corrupt JPEG datastream.  A simple error exit
 * might be the most appropriate response.
 *
 * But what we choose to do in this code is to supply dummy EOI markers
 * in order to force the decompressor to finish processing and supply
 * some sort of output image, no matter how corrupted.
 */

METHODDEF(boolean)
fill_input_buffer (j_decompress_ptr cinfo)
{
  my_src_ptr src = (my_src_ptr) cinfo->src;

  WARNMS(cinfo, JWRN_JPEG_EOF);

  /* Create a fake EOI marker */
  src->eoi_buffer[0] = (JOCTET) 0xFF;
  src->eoi_buffer[1] = (JOCTET) JPEG_EOI;
  src->pub.next_input_byte = src->eoi_buffer;
  src->pub.bytes_in_buffer = 2;

  return TRUE;
}


/*
 * Skip data --- used to skip over a potentially large amount of
 * uninteresting data (such as an APPn marker).
 *
 * If we overrun the end of the buffer, we let fill_input_buffer deal with
 * it.  An extremely large skip could cause some time-wasting here, but
 * it really isn't supposed to happen ... and the decompressor will never
 * skip more than 64K anyway.
 */

METHODDEF(void)
skip_input_data (j_decompress_ptr cinfo, long num_bytes)
{
  my_src_ptr src = (my_src_ptr) cinfo->src;

  if (num_bytes > 0) {
    while (num_bytes > (long) src->pub.bytes_in_buffer) {
      num_bytes -= (long) src->pub.bytes_in_buffer;
      (void) fill_input_buffer(cinfo);
      /* note we assume that fill_input_buffer will never return FALSE,
       * so suspension need not be handled.
       */
    }
    src->pub.next_input_byte += (size_t) num_bytes;
    src->pub.bytes_in_buffer -= (size_t) num_bytes;
  }
}


/*
 * An additional method that can be provided by data source modules is the
 * resync_to_restart method for error recovery in the presence of RST markers.
 * For the moment, this source module just uses the default resync method
 * provided by the JPEG library.  That method assumes that no backtracking
 * is possible.
 */


/*
 * Terminate source --- called by jpeg_finish_decompress
 * after all data has been read.  Often a no-op.
 *
 * NB: *not* called by jpeg_abort or jpeg_destroy; surrounding
 * application must deal with any cleanup that should happen even
 * for error exit.
 */

METHODDEF(void)
term_source (j_decompress_ptr cinfo)
{
  /* no work necessary here */
}


/*
 * Prepare for input from a memory buffer.
 */

GLOBAL(void)
jpeg_memory_src (j_decompress_ptr cinfo, const JOCTET * buffer, size_t bufsize)
{
  my_src_ptr src;

  /* The source object is made permanent so that a series of JPEG images
   * can be read from a single buffer by calling jpeg_memory_src
   * only before the first one.
   * This makes it unsafe to use this manager and a different source
   * manager serially with the same JPEG object.  Caveat programmer.
   */
  if (cinfo->src == NULL) { /* first time for this JPEG object? */
    cinfo->src = (struct jpeg_source_mgr *)
      (*cinfo->mem->alloc_small) ((j_common_ptr) cinfo, JPOOL_PERMANENT,
                  SIZEOF(my_source_mgr));
  }

  src = (my_src_ptr) cinfo->src;
  src->pub.init_source = init_source;
  src->pub.fill_input_buffer = fill_input_buffer;
  src->pub.skip_input_data = skip_input_data;
  src->pub.resync_to_restart = jpeg_resync_to_restart; /* use default method */
  src->pub.term_source = term_source;

  src->pub.next_input_byte = buffer;
  src->pub.bytes_in_buffer = bufsize;
}

然后使用起来非常简单。您可能需要将SIZEOF()替换为sizeof()。找到一个标准的解压缩示例。只需将“jpeg_stdio_src”替换为“jpeg_memory_src”。希望这有所帮助!


0
这里是 Delphi 的一个示例。它将 24 位位图转换为可用于 OpenCV 的格式。
function BmpToPIplImageEx(Bmp: TBitmap): pIplImage;
Var
  i: Integer;
  offset: LongInt;
  dataByte: PByteArray;  
Begin
  Assert(Bmp.PixelFormat = pf24bit, 'PixelFormat must be 24bit');
  Result := cvCreateImageHeader(cvSize(Bmp.Width, Bmp.Height), IPL_DEPTH_8U, 3);
  cvCreateData(Result);
  for i := 0 to Bmp.height - 1 do
  Begin        
    offset   := longint(Result.imageData) + Result.WidthStep * i;
    dataByte := PByteArray(offset);    
    CopyMemory(dataByte, Bmp.Scanline[i], Result.WidthStep);
  End;
End;

0

这是一个间接的答案...

过去,我直接使用 libpnglibjpeg 来完成这个任务。它们具有足够低级的 API,可以使用内存缓冲区而不是文件缓冲区进行读写。


如果您给出反对票,请留下评论解释为什么这个答案是错误的。这样就可以改进它了。 - Mr Fooz

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接