Abstract: The Cloud Optimized GeoTIFF (COG) format for Remote sensing images on the Cloud is a detailed introduction to the Cloud Optimized GeoTIFF (COG) format for remote sensing images on the Cloud.

This article is shared from huawei cloud community “COG cloud native Optimization of remote sensing image, tile segmentation best practice”, author: TSJSDBD.

1. Remote sensing image file format

Remote sensing images are self-portraits of the earth, usually with large files of around 5GB.

Most of these image files are saved in TIFF (not JPEG), because TIFF records relatively raw multi-band information and does not lose information due to compression.

1.1 TIFF format

Here is the TIFF file format:

TIFF is a flexible and adaptable file format that can store multiple images in a single file. Then each image carries a label catalog (multiple labels) to record its pixel depth, information of each pixel band, RGB coding and other detailed information.

Note: There is no order between the attributes in the figure above, they are all searched by offset. It’s actually a linked list:

Therefore, the order between blocks within a TIFF file can be very flexible.

1.2 TIFF Label Directory Format

Each image comes with a set of label catalogs that record the various attributes of the image.

The format of the label directory is as follows:

Each tag (attribute) has a different value due to different information content. Some information is small, and its Value is directly inside the tag. If there is a large amount of information, its label Value cannot be placed in the label, so it needs to be recorded in other positions of the file, which is matched by offset.

1.3 TIFF single-label format

1 tag, which is an attribute of the recording image. Attribute name + attribute value.

The specific format is as follows:

Generally a picture, about 10 attributes.

As you can see, the TIFF file is divided into discrete chunks to record the image data. All information is related by the offset offset.

Ps: HERE I put a bold label on “block and scatter”. This is the advantage of its flexibility, which will be discussed in subsequent topics.

On the TIFF format in detail, may refer to: www.jianshu.com/p/ff32eb09e…

1.4 GeoTIFF format

Because TIFF is a tagging format, it’s easy to expand and add geographic information to images. So GeoTIFF adds a series of (geographic information related) extension tags to TIFF label specification to record the geographic coordinates of an image.

So you can see a GeoTIFF, which is a normal TIFF file. So its contents are kept in separate chunks in a file. It’s just a series of geo-information tags.

For all label explanations, see: www.loc.gov/preservatio…

1.5 Flexible TIFF format

Because TIFF files are all linked lists internally, the file standard does not require the order of the blocks to each other.

Sometimes it goes like this:

A more common one is this:

A few might go something like this:

Regardless of the organization, it is a standards-compliant TIFF file.

1.6 TIFF File Debugging

Since my personal programming language is GO, I chose github.com/google/tiff

This package (Google open source TIFF file parsing package), function calls using TIFF.Parse() will do.

TIFF file properties: TIFF file properties:

As you can see in the above image, there are 5 images in the TIFF file currently analyzed.

As shown above, the first image has 21 attributes. This is the original image with geo-information attributes (tag ID > 3000) as follows:

The other four, they all only have 15 attributes. Overview, no geographic information, simple image (no Geo Geo attribute, tag ID is 2xx~ 3XX), as follows:

Let’s open one of the tabs and look at its value:

Here we see that the attribute ID is 256 and the query specification is:

Given that this represents the width of the image, and then the size side property, we calculate that the second byte is 28 and the first byte is 174, and the actual value is: 28 * 256 + 174 = 7342 pixel width.

You can see the pixels of the actual image, which is 7342.

The remaining properties can be viewed in this manner.

2. Problems faced by clouds on remote sensing images

The characteristics of remote sensing images are mainly large. Generally, a picture is 5~10GB, and a single satellite increases TB level every day, and the world increases PB level every day. As satellite sensors become more precise, individual image files become larger and larger.

Large, the problem is not easy to save, local data center can not store, have to go to the cloud. However, after a large amount of remote sensing data on the cloud, there are many challenges:

1. A large number of existing software cannot remotely read image files on the cloud (especially object storage, such as S3). You must Download it locally before you can open analysis.

2. Add an S3 driver to the software. To analyze a file remotely, you also have to read the full contents of the file (because it is a linked list file). Notice that this is done over the network, so it’s inefficient.

3. To take part of the image file (tiles, or thumbnails) separately, you have to download or access the entire file. Even though the tiles are only 1/N of the total image.

So is it possible to access remote sensing image data in the cloud and access only a fraction (as small as possible) of the content?

2.1 GeoTIFF is suitable for cloud optimization

To achieve this, the following abilities are required:

1. The cloud storage protocol supports reading cloud files in Range mode.

2. GeoTIFF image file, support to read “all tag data” first, and then read the target data Offset.

The first of the two conditions is supported by object storage (such as S3) of major cloud vendors.

The key is condition number two. First of all, can you put all the GeoTIFF “metadata” at the top of the file and put the actual Data at the bottom of the file?

That is:

That way, to access a large GeoTIFF remote sensing image, you can send an HTTP GET for the 16K bytes in the header of the file, and then the rest of the file is known. It is enough to send an HTTP GET to access XX bytes of the target image data based on the offset of what you want to access next.

The image is then cut into small pieces that can be “tiled” to access the target area. Since we already have the label information for the header, to access the specific area, we just need to read the specified Offset of the file on the cloud, according to Offset.

That is:

In this mode, the remote sensing image file is still a standard GeoTIFF format, but it is more suitable for cloud access.

2.2 COG Format (Cloud Optimized GeoTIFF)

In order to make the Cloud optimized GeoTIFF format more popular, the COG (Cloud Optimized GeoTIFF) standard is specially established. The specification can be found at www.cogeo.org/

The introduction article can refer to:

Medium.com/planet-stor…

The standard is now recognized by many companies in the industry:

Importantly, a COG image file, which is also a standard GeoTIFF file, is compatible with existing software ecosystems.

TIFF and the relationship between GeoTIFF and COG.

3. COG document best practices

With the background introduction of COG file format, next we will analyze a COG file in detail, how can we achieve the optimal cloud performance?

3.1 Obtaining the number of file header bytes

An image file, the most commonly used remote reading of the bottom library is GDAL. When it first accesses a file, the default is to fetch 16KB of content first. For most GeoTIFF headers, 16KB is definitely enough, as follows (1 header to Open) :

But some GeoTIFF files have too much information, making their headers too big. Gdal will have to fetch the file header again, as shown below:

It takes 2 HTTP requests to get a complete TIFF file header, which is obviously inefficient.

At this point, it is up to the underlying GDAL library configuration to control the number of bytes retrieved for the first time.

Environment variable: GDAL_INGESTED_BYTES_AT_OPEN=2000

You can get a larger header on the first request, as shown below:

But if the actual header of the image file is very small, you can waste too much of it the first time.

Therefore, please choose the number of bytes to first fetch the file header according to your image size and image attributes. Avoid wasting efficiency by sending an additional HTTP request each time.

3.2 Effect of tile size

An image, for example, whose original pixels are 512 by 512.

If we save as 256 by 256 tiles, there will be 4 tiles.

If you save as 512 by 512 tiles, there is only 1 Tile.

As a result, the amount of information to be recorded in the file header is different. Four tiles, you have to record four offsets. For each tile, only one offset is required.

Taking a GeoTIFF file of about 5GB as an example, tile at 128*128 pixels, all tile offsets are as follows:

(Tag ID=324, TileOffsets, 8-byte integer.)

So in order to record all the tile information: 65,905 (tile number) * 8(bytes) = 527240, you need 520KB.

If saved as 256*256 tiles, it can be directly reduced to 1/4, recording the offset information of all tiles only requires 520KB /4 = 130KB. It can be seen that the TIFF file header size can be reduced by increasing the tile area appropriately.

However, the tiles should not be too large, as this would affect the pixel efficiency of the local area.

Examples are as follows:

If the target area is within a small tile, then 256 by 256 tiles, the contents of the file retrieved are very small. 512 times 512, you get the whole tile in one fetch. Obviously, the efficiency of network transmission will be much lower.

4, tile size performance analysis

The following is a detailed analysis of the impact of performance vs tile size as follows:

  • The default tile size of Gdal is 256*256.

  • Rio’s default tile size is 512 by 512. See: github.com/cogeotiff/r…

Gdal command:

gdal_translate input.tiff output.tiff \

-co TILED=YES -co COPY_SRC_OVERVIEWS=YES -co COMPRESS=LZW
Copy the code

Rio command:

rio cogeo create input.tif output.tif
Copy the code

If you only have Gdal, you can also use the following command:

gdal_translate input.tif output.tif \ -co TILED=YES -co COMPRESS=LZW -co COPY_SRC_OVERVIEWS=YES \ -co BLOCKXSIZE=256 -co  BLOCKYSIZE=256 \ --config GDAL_TIFF_OVR_BLOCKSIZE 256Copy the code

To control tile size.

The gdal command can be obtained directly from docker:

docker pull osgeo/gdal
Copy the code

To start the gDAL container, simply mount the host directory into the container using -v. For example, mine:

docker run -it -v /home/tsjsdbd/cog/:/tmp/cog/ osgeo/gdal /bin/bash
Copy the code

The tiff file in /home/tsjsdbd can be seen in/TMP /cog.

The following is a comparison of the two. The detailed operations are as follows:

4.1 Take a pixel

512 * 512 tiles:

The second HTTP response: 105119744-105840639 = 720,895 bytes

256 * 256 tiles:

As you can see, the content of the second request is much smaller: 139476992-139722751 = 245,759 bytes

Comparison found that 256 tiles, the second HTTP response is only 1/3, delay is also obvious advantage.

4.2 Take an area

512 * 512 tiles:

The second HTTP response: 32522240-33095679 = 573,439 bytes

256 * 256 tiles:

Similarly, the second fetch is much smaller: 41402368-41533439 = 131,071 bytes

Similarly, with 256 tiles, the size of the second HTTP response is only 1/3, and the latency is also a significant advantage.

4.3 512 tile performance

The official test report (see: trac.osgeo.org/gdal/wiki/C…).

Display 512*512 tile size, performance is better because

256*256 small tiles, resulting in TIFF header too large. This is caused by the failure to complete the first 16KB retrieval and another retrieval.

Ps: The number of bytes taken for the first time can be controlled by configuration.

Therefore, in actual business scenes, the specific size of tiles should be adjusted appropriately according to the characteristics of project images.

4.4 Performance Summary

By comparison, 256*256 tiles perform better when loading local online Web preview.

However, 256*256 tiles mean more tiles and larger TIFF headers, so the “first fetch header” configuration needs to be properly controlled.

The above GDAL operation steps can be referred to:

Trac.osgeo.org/gdal/wiki/C…

For other GADL configuration tuning, see:

Developmentseed.org/titiler/adv…

5. COG’s future

After sharing some of the best practices behind the cloud on GeoTIFF images, we asked if any cloud vendors could offer more in-depth optimization for COG performance in the future.

One thing to think about is: getting the COG header size quickly so that the first HTTP request can fetch exactly the data it wants without wasting extra network packets. However, this requires the object store to provide some customization capabilities.

COG has been widely recognized in the industry as a cloud-native remote sensing image data format, which will definitely be more popular and play a greater value in the future. Other good ideas are also welcome to discuss and share.

Huawei cloud geographic remote sensing platform GeoGenius, after years of technical project accumulation, adopts the industry’s best cloud-native remote sensing image management practices and provides end-to-end optimal performance experience. We welcome peers in the field to know and use it.

See: www.huaweicloud.com/product/geo…

Click to follow, the first time to learn about Huawei cloud fresh technology ~