[gdal-dev] RawRasterBand and rotated images ?

Even Rouault even.rouault at spatialys.com
Mon Feb 2 04:26:12 PST 2015


Le lundi 02 février 2015 13:01:08, Andrew C Aitchison a écrit :
> I'm preparing to write a readonly driver for a file format where the image
> is an array of bytes, so the RawRasterBand helper class seems appropriate.
> However the image data starts at the bottom left and each scanline goes
> up; viewing the data in the conventional (for gdal) manner gives west at
> the top.

Andrew,

This reminds me of how data is organized in the DTED format. The DTED format 
exposes blocks of width = 1 and height = raster_height (so column 
organization).

> 
> I see two possible ways around this with RawRasterBand:
> 
> 1) apply a rotation in the geotransform matrix; or
> 
> 2) abuse the pixel and line offsets to rotate the data on the fly,
> so that we actually read the pixel values in the standard order
> but successive memory accesses are a row apart
> (I see that ctable2dataset.cpp, gtxdataset.cpp and
> loslasdataset.cpp use a similar trick to reflect on the fly
> but don't see any "raw" drivers that rotate).
> 
> The files are small; less than a megabyte and under 1000x1000 pixels.
> 
> Both methods risk making a mess of any memory caching, but one passes the
> problem up to the application and two passes it down to the RawRasterBand
> implementation.
> 
> Does anyone have advice on whether either of these is OK,
> or should I write the driver without the RawRasterBand helper class ?

If you use RawRasterBand with appropriate pixel and line offsets value, for 
each line, the whole file will be read. So you will end up reading 1 GB for a 
1000x1000 images. This might be slow.

So if you don't want to use the RawRasterBand approach, you could :
- use the DTED approach with column-shaped blocks. This minimizes the memory 
consumption but is a bit inefficient when processing line by line, although that 
the GDAL cache block will minimize the inefficiency
- or reserve an array for the full raster and fill it at the first pixel access, 
by doing reorganization from column to lines. And then you can expose line-
shaped blocks efficiently

Even

> 
> Thanks,
> 
> Andrew C Aitchison
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list