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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
