[gdal-dev] Amplitude virtual bands for complex datasets ?

[Antonio Valentino]

Hi Even, hi Julien,

Il 28/06/2016 12:39, Even Rouault ha scritto:
> Hi Julien,
> 
>>
>> I would like to discuss an idea that I think would be of great interest for
>> those using Gdal to access complex dataset, such as SLC SAR products.
>> Usually, when one want to visualize such data, looking at the real or
>> imaginary part of the signal does not make much sense. People will compute
>> amplitude, intensity, or even log-intensity and that is what they will
>> look at (phase is to my best knowledge not very useful for visualization,
>> but has a lot of value for processing).
> 
> Which definition do you give to intensity : amplitude^2 ?
> 
>>
>> Computing amplitude and phase from the complex value could be left to the
>> end-user software, but : - Most software do not provide such features
>> (think of Qgis for instance, or MapServer), - If overviews are generated
>> from the real/imaginary image values with interpolation (nearest neighbor
>> would be fine), then the generated overviews will be wrong, because you
>> cannot interpolate complex data this way.
> 
> AFAICS in the code, GDAL currently implements for complex data types : nearest 
> neighbour, average on both real and imaginary terms, and AVERAGE_MAGPHASE 
> which is average but with renormalization of the amplitude so that the  
> AVERAGE_MAGPHASE'ed amplitude is the average of the source amplitudes.
> 
>>
>> I think that Gdal could greatly ease the pain by exposing to the user
>> virtual subdatasets corresponding to the amplitude, phase, intensity and
>> log-intensity, for all complex datasets. In the case of multi-band complex
>> datasets, those virtual subdatasets should also be multi-band, so that
>> polarimetric data could be accessed directly as a multi-band amplitude
>> image for instance.

[CUT]


> Another solution would be to use VRT derived bands (see "Using Derived Bands" 
> in http://www.gdal.org/gdal_vrttut.html) and provide a few hard-coded pixel 
> functions to compute amplitude, phase, etc...
> and have API facilities like
> GDALRasterBandH GDALCreateDerivedBand( GDALRasterBandH hSrCband, const char* 
> pszPixelFunction [, GDALDataType eTargetDT ?] ) that would create the in-
> memory VRT. But I'm aware that doesn't address your idea of using unmodified 
> QGIS, MapServer, etc...
> 

Sometime ago I proposed to include in gdal a small set of pixel
function.  My use case at the time was mainly relater to SAR SLC data
visualization.

There is an open ticket #3367 [1] an also a git repo with pixel
functions implemented as gdal plugin [2]


[1] https://trac.osgeo.org/gdal/ticket/3367
[2] https://github.com/avalentino/gdal-pixfun-plugin

I hope this can help is some way.
It would be very nice to have an improved support for SAR complex data.

>> From what I know from Gdal capabilities this is not much work. I could try
>> to do it myself, but I would like to get your feedback first (and some
>> hints on where to start would be useful to me).
> 
> There would be likely changes to do in:
> - GDALOpen(), to detect a syntax like 
> "DERIVED_SUBDATASET:Amplitude:original_datasetname" and create the appropriate 
> dataset. Hum, or perhaps better, instead of hacking GDALOpen(), having a 
> driver that would recognize this syntax and instanciate the proper derived 
> dataset.
> - GDALDataset::GetMetadata( pszDomain ) when pszDomain equals "SUBDATASETS"
> -> with the issue I mentionned for drivers that already implement subdatasets 
> and will not call the base method.
> 
> 
> Hum, or perhaps a better solution would be to have a new metadata domain 
> "DERIVED_SUBDATASETS". Would solve the potential confusion between "natural" 
> and derived subdatasets, and would probably require little/no changes in 
> drivers. Would not confuse gdal_translate -sds. Could be used by mapserver 
> unmodified. But would require QGIS querying this new metadata domain.
> 
> Even
> 

ciao

-- 
Antonio Valentino