[gdal-dev] GDAL Speed Optimization

[Stefano Moratto]

Frank,
        The source images are  a sequence of tiles from openstreetmaps.
Every tiles has a fixed size (256 x 256) and the area they covers depends
from the zoom level.
It is explained very well in
http://www.maptiler.org/google-maps-coordinates-tile-bounds-projection.

I use interpolation (via a virtual dataset)  because my window size and the
paper size are not a multiple of 256 x 256.
I use reprojection because I've to mix this raster datasource with a vector
datasource that has a different projection. Reprojecting my vector data to
openstreet projection do not affect the performance.

So I think the key factor is the resizing ( I use "bilinear" interpolation)
and the size of the bitmap that may cause paging.

I use the following :

hWarp := GDALAutoCreateWarpedVRT (hSized,

         nil,
                                        PChar(FMapSRSWkt),

GDALResampleAlg_GRA_NearestNeighbour,
                                        0.5,
                                    nil);

where hSized is a

hSized =  F (hDataset) ;

F (hDataset) := Virtual Dataset of hDataset. I use it for in memory resizing
.
It is generated by: (I do not write all the details but I think it is clear)


VRTAddSimpleSource (poVRTBand,
                          poSrcBand,
                             Round(anSrcWin[0]),
                          Round(anSrcWin[1]),
                             Round(anSrcWin[2]),
                          Round(anSrcWin[3]),
                             0, 0,
                          size.cx,
                          size.cy,'Bilinear', 0.0 );


and hDataset = GDALOpen( ... "openstreet.xml" )

Can you suggest some other parameters?


Thanks,
Stefano




On Thu, Jun 10, 2010 at 4:53 PM, Frank Warmerdam <warmerdam at pobox.com>wrote:

> Stefano Moratto wrote:
>
>> The performances are quite acceptable but when I try to print they are
>> not.
>>
>> The drawing to be printed has a resolution larger of the screen (Screen :
>> 1024x1024, Printer 4096 x 4094 in A4 and 9000 x 9000 in A3 approximately).
>> I think tha the bottleneck could be found in:
>> 1) jpeg decompression.
>> 2) bitmap interpolation (I use the low qualitiy settings).
>> 3) warping ( I use an approsimated warping function).
>>
>> An increase of performance could be achieved using
>> 1) hw accelerated functions as IPP or GPU (e.g CUDA)
>> 2) parallel alghorithms that takes advantage from multicore CPU
>>
>> Has someone already approched these problems?
>>
>
> Stefano,
>
> Are the same number of jpeg tiles being used when producing print products
> as on screen?   I'm assuming the answer is yes, and that the warper is just
> interpolating a higher resolution result from them.
>
> If the answer is yes,  then presumably the time decoding the jpegs would
> not be greater for the prints than for screen display, though it is
> possible that more re-reading is occuring.  If re-reading is an issue
> you might want to increase the size of the GDAL block cache.
>  Programmatically
> this can be done with the C function GDALSetCacheMax().  Try setting it to
> 100
> (for 100MB).
>
> Are you using the warper just to interpolate to different sizes or are
> you also applying reprojection or some other non-linear warping?  If you
> are just using it to resize the image then I would suggest using something
> less general-purpose than the warper to do the interpolation.
>
> Seth's CUDA work may also be of interest of course, but before committing
> to that path I would suggest some analysis of where the time is really
> being
> spent.
>
> Best regards,
> --
>
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam<http://pobox.com/%7Ewarmerdam>
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
>


-- 
Dr.Eng. Stefano Moratto
stefano.moratto at gmail.com
stefano.moratto at csiat.it
http://www.csiat.it - Traffic Optimization Software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100611/0f8f63f0/attachment.html