[gdal-dev] GDAL ReadRaster thread-safe?

[Eric Domazlicky]

After fixing a bug on my part I was able to figure it out. The only strange
this was that the BandMap array had to declared in reverse order from what
one would expect. This may be a GDI+ issue but here is my code snippet for
the record:

            Dim bd As BitmapData = TileBmp.LockBits(New Rectangle(0, 0,
TileCropW, TileCropH), ImageLockMode.ReadWrite, PixelFormat.Format32bppArgb)
            Try
                Dim stride As Integer = bd.Stride
                Dim bandmap(3) As Integer
' destination is ARGB but this is BGRA go figure
                bandmap(0) = 3
                bandmap(1) = 2
                bandmap(2) = 1
                bandmap(3) = 4
                Dim buf As IntPtr = bd.Scan0
                GdalDataSet.ReadRaster(curRasterX, curRasterY, CropW, CropH,
buf, TileCropW, TileCropH, DataType.GDT_Byte, GdalDataSet.RasterCount,
bandmap, 4, stride, 1)
                allblack = False
            Finally
                TileBmp.UnlockBits(bd)
            End Try

On Thu, Jan 8, 2009 at 1:26 PM, Tamas Szekeres <szekerest at gmail.com> wrote:

> Eric,
>
> You could refer to the RasterIO documentation regarding to these
> parameters:
> http://www.gdal.org/classGDALDataset.html#e077c53268d2272eebed10b891a05743
>
> If you provide your source data then I could try reading it into a GDI+
> bitmap object.
>
>
> Best regards,
>
> Tamas
>
>
>
> 2009/1/8 Eric Domazlicky <edomazlicky at gmail.com>
>
>>   This looks like a great way to go but can anyone explain exactly what
>> the bandmap and bandspace parameters are? I know BandMap is an array but
>> what is it supposed to represent? I want the image data to be read and put
>> into my destination buffer in ARGB format, the source data is in RGBA
>> format. I tried making an array with elements in order: 4,1,2,3 but the
>> destination data is transparent so I'm thinking the alpha value isn't
>> getting read right.
>>
>> On Wed, Jan 7, 2009 at 4:12 PM, Tamas Szekeres <szekerest at gmail.com>wrote:
>>
>>> Eric,
>>>
>>> The most performant option I'm aware of is reading the dataset directly
>>> into a bitmap buffer something like:
>>>
>>> try
>>> {
>>>         int stride = bitmapData.Stride;
>>>         IntPtr buf = bitmapData.Scan0;
>>>
>>>         ds.ReadRaster(xOff, yOff, width, height, buf, imageWidth,
>>> imageHeight, dataType,
>>>         channelCount, bandMap, pixelSpace, stride, 1);
>>> }
>>> finally
>>> {
>>>         bitmap.UnlockBits(bitmapData);
>>> }
>>>
>>> In this case there's no internal buffers in the marshalling code used by
>>> the C# wrappers. The only challenge here is to ensure that the bitmap buffer
>>> should have the same structure as the gdal dataset represents. You could
>>> refer to the complete example in the C# wrapper for the details:
>>>
>>> http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALDatasetRasterIO.cs
>>>
>>> http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALReadDirect.cs
>>>
>>> I don't think if triggering multiple reads for different sections in
>>> multiple threads is currently supported by gdal, it might also be driver
>>> dependent how the reads are actually implemented by the drivers, however you
>>> might anyway try defining separate Dataset objects for the different when
>>> performing the read operations, but there might be locks in different places
>>> causing the operations to be serialized in effect.
>>>
>>> Best regards,
>>>
>>> Tamas
>>>
>>>
>>>
>>> 2009/1/8 Eric Domazlicky <edomazlicky at gmail.com>
>>>
>>>>  I am developing a tiling application and I was hoping to up the speed
>>>> a bit by doing some multithreading. What I want to do is start each of 3
>>>> ReadRaster calls in seperate threads (using BeginInvoke delegates), then
>>>> wait for them to complete and build my RGB image (using EndInvoke). I am
>>>> using the C# wrapper to the GDAL library. This multithreaded approach is
>>>> showing clear signs of race conditions, with some of the channels not
>>>> appearing, random crashes etc. If I ensure each thread completes before I go
>>>> on to read the next Raster Band it works fine.
>>>>
>>>> Is there anyway to make ReadRaster thread-safe? Maybe by disabling
>>>> caching which I suspect is the problem.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> gdal-dev mailing list
>>>> gdal-dev at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090108/1daa0106/attachment.html