AW: [gdal-dev] Create gdaldataset from in-memory Image/Bitmap/byte[]/MemoryStream

Tamas Szekeres szekerest at gmail.com
Wed May 26 17:22:27 EDT 2010


2010/5/26 Even Rouault <even.rouault at mines-paris.org>

> Felix,
>
> yes you should be able to use FileFromMemBuffer() to create a virtual file
> and
> open it with the PNG driver (since the PNG driver supports virtual IO -->
> as
> confirmed by gdalinfo --format PNG)
>
> Here's the C API for it :
> http://gdal.org/cpl__vsi_8h.html#1ecb3a78729ecea4d2ce22065a605244
>
> And here's an extract of a test in the Python autotest suite.
>
>    content = open('data/byte.tif', mode='rb').read()
>
>    # Create in-memory file and initialize it with the content
>    gdal.FileFromMemBuffer('/vsimem/tiffinmem', content)
>
>    # Open the in-memory file
>    ds = gdal.Open('/vsimem/tiffinmem')
>
>    # do something with the dataset
>
>    # Close the dataset
>    ds = None
>
>    # Release memory associated to the in-memory file
>    gdal.Unlink('/vsimem/tiffinmem')
>
>
> Disclaimer: You should be able to adapt the above for C#, but I haven't
> tested
> with the C# bindings, so there's a risk that they aren't ready if there's
> some missing required typemap.
>
>
Felix,


The current version of the C# signature of FileFromMemBuffer is rude and not
user friendly, though I could imagine the following transcript of the python
code above for the C# bindings (not tested):


byte[] bytes = File.ReadAllBytes("data\\byte.tif");
GCHandle handle = GCHandle.Alloc(bytes, GCHandleType.Pinned);
try
{
    Gdal.FileFromMemBuffer("/vsimem/tiffinmem",
handle.AddrOfPinnedObject());

    using (Dataset ds = gdal.Open("/vsimem/tiffinmem"))
    {
    // do something
    }
    Gdal.Unlink("/vsimem/tiffinmem");
}
finally
{
    handle.Free();
}


In the future I'm about to add a second signature to the bindings  "*public
static void FileFromMemBuffer(string pszFilename, int nBytes, byte[]
pabyData)*" which could also avoid the extra memcopy implemented in the
current version.

Feel free to add a ticket <http://trac.osgeo.org/gdal/newticket> to require
this addition.


Best regards,

Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100526/bf0a14f2/attachment-0001.html


More information about the gdal-dev mailing list