[gdal-dev] Support for the LUT transformation of the vrt bands

Tamas Szekeres szekerest at gmail.com
Tue Mar 11 19:15:43 EDT 2008


Hmmm. I'd slightly modify the previous post to distiguish between the
source nodata masking and the post lookup nodata masking. The latter
would provide an additional option to clip the sections based on the
LUT. So the processing order would be:

1. Calculate the scalar representation of the complex source value
based on the user definied setting. (If the scalarvalue option is
set).
2. Source nodata mask.
3. Apply scaling and offset.
4. LUT transformation.
5. Post lookup nodata masking (an additional attribute would be added
to the lookup table to specify the nodata value)


Best regards,

Tamas


2008/3/11, Tamas Szekeres <szekerest at gmail.com>:
> Frank,
>
>  Yes it seems comfortable to add this here. I haven't noticed this
>  element before, it may be missing from the documentation, though.
>
>  In this regard I'll apply the following processing chain inside
>  VRTComplexSource::RasterIO:
>
>  1. Calculate the scalar representation of the complex source value
>  based on the user definied setting. (If the scalarvalue option is
>  set).
>  2. Apply scaling and offset.
>  3. LUT transformation.
>  4. Nodata masking
>
>  I'll proceed with this if there's no objection and update the docs accordingly.
>
>  Best regards,
>
>  Tamas
>
>
>
>  2008/3/11, Frank Warmerdam <warmerdam at pobox.com>:
>
> > Tamas Szekeres wrote:
>  >  > Folks,
>  >  >
>  >  > In my recent work I need a limited support for a LUT based
>  >  > transformation of the bands to apply some colorization  and threshold
>  >  > operations created with the gdal_grid application. I wonder if we
>  >  > could implement this enhancement in the gdal vrt driver, and the
>  >  > dataset could be created from the scripting interfaces (like C#)
>  >  > either. By adding this functionality the vrt driver the config could
>  >  > be stored in a separate configuration profile (XML) that could be
>  >  > preserved and used for subsequent transformations.
>  >  >
>  >  > In my proposal this functionality would be implemented in a new
>  >  > VRTRasterBand subclass, like subClass="VRTLUTRasterBand", and we
>  >  >
>  >  > could specify the lookup table in the following pseudo fromat:
>  >  >
>  >  > <LUT>[source value1]:[dest value1],[source value2]:[dest value2] ...</LUT>
>  >  >
>  >  > We could also specify the interpolation mode when gathering the
>  >  > intermediary values (linear or none at the moment)
>  >  >
>  >  > There would be another transformation parameter assigned to a LUT
>  >  > denoting how the scalar value is computed in case when we have a
>  >  > complex source band (the possible values are
>  >  > magnitude/phase/real/imaginary)
>  >  >
>  >  > For example:
>  >  > <VRTRasterBand dataType="Byte" band="1" subClass="VRTLUTRasterBand">
>  >  >   <LUT interpolation="linear"
>  >  > scalarvalue="magnitude">23400.34:0,75234.45:255</LUT>
>  >  >   <SimpleSource>
>  >  >       <SourceFilename relativeToVRT="1">source.tif</SourceFilename>
>  >  >       <SourceBand>4</SourceBand>
>  >  >   </SimpleSource>
>  >  > </VRTRasterBand>
>  >  >
>  >  >
>  >  > I wouldn't address creating complex bands with this method at the
>  >  > moment. However we could probably extend this by adding multiple LUT
>  >  > nodes and data sources to a single VRTLUTRasterBand.
>  >  >
>  >  > In the future we could possibly add helper functions to create
>  >  > predefinied LUT XML nodes based on some common use cases (like
>  >  > equidinstant or histogram based partitions of the source values) but
>  >  > currently it's up to the user and script developer how to create the
>  >  > desired vrt xml. However a graphical application could easily
>  >  > visualize the LUT by applying the vrt on a sample image with linear
>  >  > range of the values.
>  >  >
>  >  > I'd like to know whether the idea above would be reasonable to
>  >  > implement. Should I create an RFC on this?
>  >
>  >
>  > Tamas,
>  >
>  >  I would like to suggest that you handle this as additional parameters
>  >  on the VRTComplexSource rather than as a distinct band object type.
>  >
>  >  The VRTComplexSource can already apply rescaling on the fly, and it
>  >  seems like a reasonable extension to add interval based LUTs.  In
>  >  some cases it may also be helpful to be able to apply different LUTs
>  >  to different sources in a virtual mosaic.
>  >
>  >  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    | President OSGeo, http://osgeo.org
>  >
>  >
>


More information about the gdal-dev mailing list