将 SWIG 代理对象作为输入传递给 PIL.Image.frombuffer

发布于 2024-12-26 20:48:31 字数 628 浏览 2 评论 0原文

我正在使用 crays.i 中定义的 SWIG array_class 宏来创建一个无符号字符缓冲区，该缓冲区可以发送到我的项目的 c++ 端，用于处理拍照。这工作得很好——在相机触发后，缓冲区填充了宽度数据，我可以使用 python 中的 [] 取消引用缓冲区以查看它保存的内容。我现在想使用 Image.frombuffer 从该缓冲区创建一个 PIL 图像：

Image.frombuffer(mode, size, data) => image

（PIL 1.1.4 中的新增功能）。使用标准“原始”解码器从字符串或缓冲区对象中的像素数据创建图像内存。

但我收到一条错误消息，告诉我我提供的 SWIG 对象不是 python 缓冲区：

文件“/usr/lib/python2.7/dist-packages/PIL/Image.py”，第 1853 行，frombuffer
core.map_buffer（数据，大小，解码器名称，无，0，args）
类型错误：预期的字符串或缓冲区

如何使 SWIG 对象的此代理与 Image.frombuffer 期望的缓冲区类型兼容？

原文

I'm using the SWIG array_class macro defined in carrays.i to create an unsigned char buffer which can be sent to the c++-side of my project, which handles picture taking. This works fine – the buffer is filled width data after the camera has triggered, and I can dereference the buffer using [] from python to see what it holds. I now want to create a PIL image from that buffer, using Image.frombuffer:

Image.frombuffer(mode, size, data) => image

(New in PIL 1.1.4). Creates an image memory from pixel data in a string or buffer object, using the standard "raw" decoder.

but I get an error message telling me that the SWIG object I supply is not a python buffer:

File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 1853, in frombuffer
core.map_buffer(data, size, decoder_name, None, 0, args)
TypeError: expected string or buffer

How can I make this proxy of a SWIG Object compatible with the type of buffer that Image.frombuffer expects?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

So要识趣 2025-01-02 20:48:31

如果您可以处理强制 SWIG 缓冲区的符号，则可以直接创建 PIL ImagingMemoryInstance。在 libImaging/Imaging.h 中，您会发现：

struct ImagingMemoryInstance {

    /* Format */
    char mode[4+1]; /* Band names ("1", "L", "P", "RGB", "RGBA", "CMYK") */
    int type;       /* Data type (IMAGING_TYPE_*) */
    int depth;      /* Depth (ignored in this version) */
    int bands;      /* Number of bands (1, 2, 3, or 4) */
    int xsize;      /* Image dimension. */
    int ysize;

    /* Colour palette (for "P" images only) */
    ImagingPalette palette;

    /* Data pointers */
    UINT8 **image8; /* Set for 8-bit images (pixelsize=1). */
    INT32 **image32;    /* Set for 32-bit images (pixelsize=4). */

    /* Internals */
    char **image;   /* Actual raster data. */
    char *block;    /* Set if data is allocated in a single block. */

    int pixelsize;  /* Size of a pixel, in bytes (1, 2 or 4) */
    int linesize;   /* Size of a line, in bytes (xsize * pixelsize) */

    /* Virtual methods */
    void (*destroy)(Imaging im);
};

... ImagingMemoryInstance* 被类型定义为 Imaging，这是您在整个 PIL 中随处可见的基本结构C 扩展源。别相信我的话，看看——就 API 源代码而言，PIL 代码库非常清晰且相当连贯。

正如 @maxy 指出的，您还可以创建一个 NumPy 数组结构，同样简单（如果不是更容易的话）——但是虽然 NumPy C API 与 Guido 的个人剧本一样稳定，但我个人发现一个库源依赖项是在这些场景中就足够了。

If you can deal with coercing the signedness of your SWIG buffer, you can create a PIL ImagingMemoryInstance directly. In libImaging/Imaging.h you will find this:

struct ImagingMemoryInstance {

    /* Format */
    char mode[4+1]; /* Band names ("1", "L", "P", "RGB", "RGBA", "CMYK") */
    int type;       /* Data type (IMAGING_TYPE_*) */
    int depth;      /* Depth (ignored in this version) */
    int bands;      /* Number of bands (1, 2, 3, or 4) */
    int xsize;      /* Image dimension. */
    int ysize;

    /* Colour palette (for "P" images only) */
    ImagingPalette palette;

    /* Data pointers */
    UINT8 **image8; /* Set for 8-bit images (pixelsize=1). */
    INT32 **image32;    /* Set for 32-bit images (pixelsize=4). */

    /* Internals */
    char **image;   /* Actual raster data. */
    char *block;    /* Set if data is allocated in a single block. */

    int pixelsize;  /* Size of a pixel, in bytes (1, 2 or 4) */
    int linesize;   /* Size of a line, in bytes (xsize * pixelsize) */

    /* Virtual methods */
    void (*destroy)(Imaging im);
};

... ImagingMemoryInstance* is typedef'd to Imaging, which is the base struct you'll find ubiquitously throughout the PIL C extension source. Don't take my word for it, have a look -- as far as API source goes, the PIL codebase is notably legible and pretty coherent.

As @maxy points out, you can also create a NumPy array struct just as easy (if not easier) -- but while the NumPy C API is as stable as out of Guido's personal playbook, I personally find that one library-source dependency is enough, in these scenarios.

回复收藏 0 原文

~没有更多了~