2009-04-29 10 views
15

openCV cvLoadImageおよびcvSaveImageの2つの関数は、ファイルパスを引数として受け入れます。メモリバッファまたはファイルポインタで使用するOpenCV

たとえば、画像を保存するときは、cvSaveImage( "/ tmp/output.jpg"、dstIpl)となります。これはディスクに書き込みます。

このバッファを既にメモリに供給する方法はありますか?したがって、ディスク書き込みの代わりに、出力イメージはメモリに格納されます。

私はcvSaveImageとcvLoadImage(メモリバッファへの読み書き)についてもこれを知りたいと思います。ありがとう!


私の目標は、ファイルのエンコードされた(jpeg)バージョンをメモリに保存することです。同じcvLoadImageに行く、私はIplImage形式にメモリ内のjpegをロードしたい。

+1

画像をメモリに書き込みたいですか?しかしdstIplはすでに記憶に残っていますが、正確に何を達成したいのですか? dstIpl-> imageDataまたは - > dataなどで画像データにアクセスできます。 – mpen

+0

同様に、iplImageのデータバッファを操作して、既にメモリ内にあるイメージをロードすることができます。ちょうどBGR形式でなければなりません。 – mpen

+0

私は元のポスターがイメージをエンコードしたいが、ディスクの読み書きを保存したいと思う。 – M456

答えて

14

文書化されていない機能のカップルがlibaryの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のデータを操作して、エンコードライブラリの入力構造と一致させることもできます。

+7

文書化されていない関数に依存しないでください。あなた自身でメンテナンスの悪夢を作成します。彼らが文書化されていない理由は、デザイナー**が時間の経過とともに安定しているとは思わないからです**。それらは次のバージョンで消えるかもしれません! –

+3

私は、警告はあらゆる開発版に暗示されていると思います。また、OpenCVでは常に文書化が問題となっていますが、安定した関数の多くはまだ文書化されていません。 – M456

0

これは間接的な答えは...過去には

は、私が直接これを行うために直接libpnglibjpegを使用しました。彼らは低レベルの十分なAPIを持っているので、ファイルバッファの代わりにメモリバッファを読み書きすることができます。

+0

downvoteの場合、この回答が間違っている理由を説明するコメントを残してください。そうすれば、改善することができます。 –

1

私はあなたがLinuxで作業していると仮定しています。

JPEG 圧縮動作の大まかな概要は次のとおりです:libjpeg.docから
が オブジェクト
が 圧縮されたデータの保存先を指定します(例えば、ファイル)
を割り当て、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-libjpeg62-devを入手し、libjpeg.docを読んでexample.cを見てください。あなたが問題に遭遇し、何かを稼働させることができない場合は、再び投稿し、誰かが助けることができると確信しています。

0

メモリバッファからファイルをロードするには、別のsrcマネージャ(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"に置き換えてください。希望が助けてくれる!

15

これは私

// 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); 
} 
+0

imdecodeがイメージをデコードするのではなく、なぜimageBufをcv :: matに配置する必要があるのでしょうか?私は、私がワイヤ上にロードされた生データ(そのTIFF画像)を含むunsigned char *を持つ問題を抱えていますが、生データ上のdoign imdecodeの後、Matはmat.data == 0を持ち、エラーはありません。 –

+0

@pksorensen imageBufは、imdecode()が望むInputArrayに変換できるC++の魔法がない限り、imdecode()のパラメータとして受け入れることができるように、Matに入れる必要があります。あなたのTIFFイメージをデコードしない理由は、(1)imgdecode行に渡されたMat *が1未満だった、(2)OpenCVライブラリにTIFFサポートがコンパイルされなかった、(3)TIFFデコーダが画像バッファを有効なTIFF画像として表示します。 – codeDr

0

ここでは、Delphiでの例です。 OpenCV用の24ビットビットマップを変換する

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; 
関連する問題