[gdal-dev] Fwd: NBITS=1 not preserved from vrt to tiff in multilayer tiff

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[gdal-dev] Fwd: NBITS=1 not preserved from vrt to tiff in multilayer tiff

Ritchie, Andrew
From: Ritchie, Andrew <[hidden email]>
Date: Thu, Jun 22, 2017 at 10:30 AM
Subject: NBITS=1 not preserved from vrt to tiff in multilayer tiff
To: [hidden email]


We are building TIFFs with fourteen layers, four of which are byte, and the remainder being binary. We are able to generate binary tiffs with NBITS=1 and stack them with gdalbuildvrt -separate, but when muiltilayer tiffs are created with gdal_translate or gdal_merge -separate, the NBITS metadata are ignored and the resulting tiff has the same bit depth (byte) for all fourteen layers.

Is there a way to force NBITS per band with a -co NBITS=1 option when using gdal_merge with the -separate flag? alternatively, is there a way to force gdal_translate to honor the NBITS of the source layers in a VRT?

Andy

--
====================================
Andy Ritchie
U.S. Geological Survey
Pacific Coastal and Marine Science Center
2885 Mission St.
Santa Cruz, CA 95060
Office (831) 460-7454
Cell (360) 460-9453
---------------------------------------------------------------

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: NBITS=1 not preserved from vrt to tiff in multilayer tiff

Even Rouault-2

On jeudi 22 juin 2017 11:00:26 CEST Ritchie, Andrew wrote:

> From: Ritchie, Andrew <[hidden email]>

> Date: Thu, Jun 22, 2017 at 10:30 AM

> Subject: NBITS=1 not preserved from vrt to tiff in multilayer tiff

> To: [hidden email]

>

>

> We are building TIFFs with fourteen layers, four of which are byte, and the

> remainder being binary. We are able to generate binary tiffs with NBITS=1

> and stack them with gdalbuildvrt -separate, but when muiltilayer tiffs are

> created with gdal_translate or gdal_merge -separate, the NBITS metadata are

> ignored and the resulting tiff has the same bit depth (byte) for all

> fourteen layers.

>

> Is there a way to force NBITS per band with a -co NBITS=1 option when using

> gdal_merge with the -separate flag? alternatively, is there a way to force

> gdal_translate to honor the NBITS of the source layers in a VRT?

 

Andy,

 

NBITS metadata is honoured by the GeoTIFF driver if you translate the following single-band VRT

 

<VRTDataset rasterXSize="20" rasterYSize="20">

<VRTRasterBand dataType="Byte" band="1">

<Metadata domain="IMAGE_STRUCTURE">

<MDI key="NBITS">1</MDI>

</Metadata>

<SimpleSource>

<SourceFilename relativeToVRT="1">byte.tif</SourceFilename>

<SourceBand>1</SourceBand>

<SourceProperties RasterXSize="20" RasterYSize="20" DataType="Byte" BlockXSize="20" BlockYSize="20" />

<SrcRect xOff="0" yOff="0" xSize="20" ySize="20" />

<DstRect xOff="0" yOff="0" xSize="20" ySize="20" />

</SimpleSource>

</VRTRasterBand>

</VRTDataset>

 

However in the particular case you mention, multiple bands with different bit depth, there's nothing we can do. At least not easily.

In theory, the BitsPerSample tag could be used to record a different bit depth per band.

See http://www.awaresystems.be/imaging/tiff/tifftags/bitspersample.html

But the libtiff library used by GDAL (and lots of other software!) only support one single value (the first one). So basically the GeoTIFF writer looks at the parameter of the first input band and use them to create the TIFF file.

 

One potential format candidate would be the HFA / Erdas Imagine format. From a quick test, it doesn't look that multiple bit depth is supported on writing write now by the driver (but I think it supports that on reading). I think this is a limitation that could be relatively easily removed.

 

Even

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Loading...