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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
