[OSGeo Africa] Compression of Aerial Imagery

[Grant Slater]

Hi Aslam,

Answers below...

On Thu, 11 Jul 2024 at 14:20, Aslam Parker via Africa
<africa at lists.osgeo.org> wrote:
>
> Good day
>
> Can anyone please advise on recommended compression for 3 Band (RGB) 16 bit aerial imagery that is suitable in a photogrammetric workflow?
>
> Also, is there a compression that can be recommended for 4 band 8 bit RGBNIR imagery that can be used in photogrammetric workflow. Although CD: NGI acquires 4 band imagery, it only orthorectifies 3 bands , due to the limitation of JPEG compression, which can only compress three bands.
>

The simple answer is: It depends. There are Saving Performance / Image
Quality / File Size / $$$ cost tradeoffs.

Do you perhaps have an example of the workflow steps? Ideally with
file load / save steps, because each additional save step is likely to
increase compression artifacts.
Could publish samples of the files in original format?

Some initial thoughts...

* ECW: is very common in the proprietary world, but I understand it
has expensive licensing costs. I have no experience with it.
* MrSID: as above.
* JPEG (GeoTIFF): is open, widely adopted, quality / file size is
poor. 12-bit not widely adopted/supported. YCBCR "RGB" only.
* LZW, DEFLATE (GeoTIFF): are open, lossless, but huge file size.
Likely option for intermediate steps.
* ZSTD (GeoTIFF): open, lossless, but large file size. Likely option
for intermediate steps.
* LERC / LERC_DEFLATE / LERC_ZSTD (ESRI) (GeoTIFF): open, lossy /
lossless, limited adoption.
* JPEG2000  (JP2) is open, but software support is poor / mixed
adoption / buggy.
* JPEG-XL / JXL (GeoTIFF) is open, but has very limited adoption / buggy.
* WEBP (GeoTIFF) is very good quality for small file size, Slow to
compress. What I use for aerial.openstreetmap.org.za

Outside of compression:

* Files should be internally tiled. For GeoTIFF this needs to be
specified when saving.
* Published / Archived files should not contain internal "overviews".
This bloats the filesize by 20%+.  gdaladdo, QGIS or similar tools can
create external overviews if needed.
* Ideally RGB and NIR are published as separate files.

Observations about the 25cm series that are being published:

* Publish 1 file per grid square. Do not combine squares: eg:
3217DD_23_3317BB_03_2022_1556_RGB_RECT.tif and
2816DA_03_BC_23_2022_1584_RGB_RECT.tif
The combined squares makes it more difficult for end users to find
gaps and find missing files.
Publish a list of grid squares which will / are available.
Sometimes small bits get missed / not published:
eg: 2420CC_01 was missed in 2022 Capture: 1669.
eg: 2523AC_04 and 2523AC_05 were missed in 2021 Capture: 1447

* Multiple rounds of Compression / Sensor issues?
Quality seems to vary greatly. Output files are JPEG at Q95 or Q97 but
it seems like during workflow the imagery has been over compressed and
has severe compression artifacts.
eg: 2729DD_05_2022_1712_RGB_RECT.tif (poor) vs
2730CC_01_2022_1713_RGB_RECT.tif (ok)
Example view: https://aerial.openstreetmap.org.za/#zoom=19&lat=-27.754098&lon=30.001725

* High number of published files are corrupt or truncated and
therefore are unusable.
eg: 3220AD_17_2022_1625_RGB_RECT.tif and 3325CB_24_2021_1437_RGB_RECT.tif

* High number of published files use a different projection than the
other files in the same 50k grid square.
eg: 2624CC_06_2021_1455_RGB_RECT.tif and 2520AC_01_2022_1669_RGB_RECT.tif

The imagery published by NGI is an amazing resource. Thank you!
Next 5 year cycle 20cm? ;-)

Kind regards,

Grant