[Gdal-dev] VRTFuncSource

[Frank Warmerdam]

On 8/14/05, Stefan Klug <Klug.Stefan at gmx.de> wrote:
> Hi everybody,
> 
> I'm fairly new to gdal and am currently stuck with the following problem:
> 
> My App needs to extract small parts of a geotiff and write them down as
> a JPEG
> With an RGB Tiff my approach would be the following:
> - create a VRTDataset with three bands
> - plug in the three Rasterbands of my geotiff as VRTSimpleSource
> - create a copy of the VRTDataset using the JPEG driver
> 
> would that be the best way to go?
> 
> 
> with indexed geotiffs I thought I could create three inbetween buffers
> (red/green/blue) and put them into the VRTDataset using a VRTFuncSource.
> But when creating a copy of the VRTDataset using the JPEG driver I get
> the following error
> VRTFuncSource::RasterIO() - Irregular request
> because of nPixelSpace set to 3

Stefan,

This is really just an incomplete implementation of the VRTFuncSource
class.  The VRTFuncSource::RasterIO() method should really be extended
to support reading data from funcs into a temporary buffer, and then 
re-interleaving the data into the callers buffer. 

I must confess I have no current plans to implement the VRTFuncSource
properly. If you provided clean looking patches, I would be willing to 
incorporate them. 

> Stepping through the code I realized that the JPEG driver requests 3
> interleaved bytes per Pixel. There seems to be no possibility to use the
> VRTFuncSource when writing color JPEGs as there is no GDALDataType with
> 3 bytes in size, which would prevent the error?!
> Wouldn't it make more sense to pass nPixelSpace to the VRTFuncSource
> callback, letting the user handle it?
> There is another issue with the speed of the taken approach. When
> writing JPEGs like described above, the JPEG driver creates a buffer for
> one scanline, passes it to the first band to write the read channel,
> then passes buffer+1 to the second band and then buffer+2 to the third
> band. All bands writing to the same buffer and propably reading from one
> (interleaved) source. Wouldn't it be much more efficient to introduce a
> RGB Band which would allow a direct copy of interleaved data?
> 
> Or did I completely misunderstand the philosophy behind gdal?
> Is the only working solution to write a JPEG from a indexed tiff to
> convert the Tiff to a temporarily RGB Tiff, and then writing the JPEG?

RGB images are 3 distinct bands in the GDAL model.  The RasterIO()
call supports a variety of ways of interleaving bands in work buffers,
and - in theory - drivers can provide particular interleavings quite
efficiently if implemented appropriately.

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
and watch the world go round - Rush    | Geospatial Programmer for Rent