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

[Julien Michel]

PS: any comments welcome, I am not really familiar with gdal coding 
style & arch.

Julien

Le 04/07/2016 à 14:30, Julien Michel a écrit :
> Hi,
>
> Started the work here :
>
> https://github.com/OSGeo/gdal/compare/trunk...jmichel-otb:enhance-complex-datasets 
>
>
> For now, recognizes the following syntax :
>
> gdal_translate -srcwin 1000 1000 1000 1000 
> DERIVED_SUBDATASET:COMPLEX_AMPLITUDE:s1a-s6-slc-vv-20150619t195043-20150619t195101-006447-00887d-001.tiff 
> ~/tmp/test.tif
>
> I need to see about exposing those derived datasets properly.
>
> Antonio, I copied one of your pixel function for fast prototyping, I 
> hope you do not mind. Of course upon completion of this work we should 
> merge properly all your pixel functions with proper 
> credits/copyright/licence. Thing is I did not know where to put them 
> within gdal.
>
> Regards,
>
> Julien
>
> Le 04/07/2016 à 11:06, Even Rouault a écrit :
>> Hi,
>>> To check if I understood well :
>>>
>>> I will create a driver that will recognize the
>>> "DERIVED_SUBDATASET:Amplitude:original_datasetname" syntax. This driver
>>> needs to now if "original_datasetname" is of complex type (to report it
>>> can open it)
>> That or we could also possibly accept non-complex types (assume 
>> imaginary part
>> = 0). Antonio's functions handle complex & non-complex AFAICS
>>
>>> , and will also expose the derived band somehow (can I
>>> benefit from the CreateDerivedBand API,
>> If you write it, yes... (it doesn't exist yet if I wasn't clear)
>>
>> If you follow the VRT pixel function road, that's a matter of 
>> building a on-
>> the-fly VRT dataset.
>>
>> http://www.gdal.org/gdal_vrttut.html#gdal_vrttut_creation could 
>> possibly be
>> used. But AFAICS setting the pixel function name isn't supported. 
>> Could be
>> done by implementing CPLErr VRTSourcedRasterBand::SetMetadataItem( 
>> const char
>> *pszName, const char *pszValue, const char *pszDomain ), similarly to 
>> what
>> VRTSourcedRasterBand::SetMetadataItem(...) handles for vrt sources.
>>
>>> and the pixel functions from Antonio ?).
>> Would make sense to internalize this code (uses X/MIT license)
>>
>>> Also, "original_datasetname" can be a subdataset itself.
>> Yes, that shouldn't matter to the driver. It is just a string that it 
>> provides
>> to GDALOpen() (some care must be taken when parsing
>> DERIVED_SUBDATASET:algname:original_datasetname, since 
>> original_datasetname
>> can have columns too)
>>
>>> There should also be a mechanism that will report the existing
>>> DERIVED_SUBDATASETS upon query (this I did not get yet).
>> Implement in GDALDataset, the following method (from GDALMajorObject)
>>
>> virtual char **GetMetadata( const char * pszDomain = "" );
>>
>> char **GDALDataset::GetMetadata( const char * pszDomain = "" )
>> {
>>     if( pszDomain != NULL && EQUAL(pszDomain, "DERIVED_SUBDATASET") )
>>     {
>>         // some stuff. Be careful that ownership of returned char** 
>> belongs
>>         // to the dataset object
>>     }
>>     else
>>         return GDALMajorObject::GetMetadata(pszDomain);
>> }
>>
>> As well as :
>>
>> virtual char **GetMetadataDomainList(); to report DERIVED_SUBDATASET 
>> when it
>> makes sense (contrary to GetMetadata(), ownership of the returned char**
>> belongs to the caller)
>>
>> Even
>>
>
>


-- 
Julien MICHEL
CNES - DCT/SI/AP - BPI 1219
18, avenue Edouard Belin
31401 Toulouse Cedex 09 - France
Tel: +33 561 282 894 - Fax: +33 561 283 109