2

When accessing Sentinel-2 through Earth Engine search bar, the info page that pops up reports the bands as UINT16 when in reality they are 12-bit. Am I interpreting this incorrectly?

1
  • 3
    It's kind of hard to work with a 12 bit image, it's much easier to populate an unsigned integer of 16 bits (two bytes) with the value from the sensor 12 bits (1.5 bytes) as it's the smallest word that can hold the range. By having the data as words the file can be read with normal I/O without having to bit-shift internally; I don't know what GIS raster formats could even support 12 bits but there are plenty of UInt16 capable formats. Dec 4, 2019 at 4:37

1 Answer 1

1

I think it is common to do the same than GDAL and use either 8, 16, or 32 bit storage but with less meaningful numbers. See GDAL GeoTIFF documentation https://svn.osgeo.org/gdal/trunk/gdal/frmts/gtiff/frmt_gtiff.html

NBITS=n: Create a file with less than 8 bits per sample by passing a value from 1 to 7. The apparent pixel type should be Byte. From GDAL 1.6.0, values of n=9...15 (UInt16 type) and n=17...31 (UInt32 type) are also accepted. From GDAL 2.2, n=16 is accepted for Float32 type to generate half-precision floating point values.

The corresponding TIFF tag is BitsPerSample https://awaresystems.be/imaging/tiff/tifftags/bitspersample.html

GDAL test about creating a 6-bit image shows that the image type is still 8-bit (byte) and the correct BitsPerSample is written into the metadata.

gdal_translate -co nbits=6 8bit.tif 6bit.tif

Band 1 Block=1200x9 Type=Byte, ColorInterp=Gray
  NoData Value=255
  Image Structure Metadata:
    NBITS=6

For GEE it may not mean any differece if BitsPerSample is 12 or 16 but it will process both images as 16 bit, but this is just my guess.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.