GDAL, sıkıştırılmış GeoTIFF dosyaları üretecek şekilde ayarlanmalı mı? Hangi algoritma kullanılmalı?

Genelde GeoTIFF dosyalarından oluşan bir CBS verisi klasörüm var. Bütün set yaklaşık ağırlıkta 1.2 GB. İçeriği bir tarball'a paketlersem, parçalanacağını fark ettim 82 MB. Setin revizyon kontrol sistemi olarak kontrol edilmesini istiyorum, başkaları tarafından çalışabileceği ve sıkılabilecek bir yer olduğu anlaşılıyor.

GDAL GeoTIFF sürücü sayfası , sıkıştırılmış GeoTIFF dosyaları oluşturmak için kullanılabilecek birçok seçenek listeler. Her algoritmanın çalışmasını etkileyen birçok seçenek de vardır.

Yardım sayfası, seçenekleri tanımlamakta iyi bir iş çıkarsa da, bir algoritmanın nasıl seçileceğini veya değişen sıkıştırma seviyesine bağlı değişimlerin nasıl yapıldığını ayrıntılandırmaz. Bu, aşağıdaki sorulara yol açar:

• Sıkıştırma kullanmanın artıları uzayda önemli bir tasarruftur. Eksileri neler? Görüntü sıkıştırıldığında bilgi kayboluyor mu?

• Bir algoritma ve sıkıştırma seviyesi seçmeye nasıl başlanmalı? Bazı görüntü türleri kendilerini belli bir algoritmaya borçlu mu?

Sıkıştırma yöntemini seçmek için aşağıdaki gibi bir komut kullanmanız gerekir:

gdal_translate -co "COMPRESS=method" src_dataset dst_dataset

Sıkıştırma kullandığınızda en büyük takas, görüntüyü açmak için gereken ekstra işlem süresidir ve görüntüyü açtıktan sonra hala aynı miktarda bellek tüketir. Bilgi kaybı hakkında iki temel sıkıştırma türü vardır :

• kayıpsız - orijinal veri değerlerini korur
• kayıp - daha fazla yer kazanmak için verileri bozar

Orijinal veri değerlerinin DEM'ler veya raster özellikler gibi korunması gerektiğinde kayıpsız algoritmalar kullanırsınız. PACKBITS , DEFLATE ve LZW gibi algoritmalar kayıpsızdır ve sıkıştırma oranına göre sipariş edilebilir:

1. LZW - en yüksek sıkıştırma oranı, en yüksek işlem gücü
2. DEFLATE
3. PAKETLER - en düşük sıkıştırma oranı, en düşük işlem gücü

Sıkıştırma oranı yine de verilere bağlıdır, eğer verilerde çok benzer değerler varsa, PACKBITS iyi sonuçlar verecektir.

Kayıpsız aksine, kesin değerleri döndürmek zorunda kalmayan rasterleri sıkıştırmak için JPEG gibi kayıplı algoritmalar kullanırsınız . Örneğin, ortofotolar veya uydu görüntüleri kayıplı algoritmalar kullanılarak sıkıştırılabilir.

İle lzwve deflatesıkıştırma kullanarak -co predictor=2yerine mutlak değerlerin pikselden piksele farklılıkları sıkıştırır sorunsuz değişmektdir görüntüleriyle yardımcı olabilir ve bunlar küçük olma eğilimindedir ve daha fazla kalıp (olacak ref ). Predictor sadece sıkıştırma lzwve deflatesıkıştırma ile kullanışlıdır , seçeneğin diğer yöntemlerle etkisi yoktur.

gdal_translate -co compress=lzw -co predictor=2 ...

Öngörücü tasarrufları çarpıcı olabilir. Varsayılan LZW ayarları ile 17GB kullanarak belirteç = 2 ile sadece 5GB'a 16bit geotiff yükseklik modelleri dizinini yeniden sıkıştırdım.

2 ve 3 öngörücüleri arasındaki farklar ve her birinin en iyi şekilde uygulandığı durumlarda çelişkili bilgi vardır ( ref1 , ref2 ). Belki başka bir soru için yakıt.

Tasarruf için bir başka kolay seçenek -co tiled=yes. Döşenmiş görüntüleri okuyamayan bazı yazılımlar var, ancak bunlar daha nadir ve çoğunlukla GIS'in dışında kalıyor (şu anda bunları okuyan herhangi bir ana akış GIS yazılımını bilmiyorum).

@ Alfonx'un sıkıştırılmış genel bakışları kullanma cevabı üzerine inşa etmek : Bu, temel bütünlüğün veri bütünlüğü ve piramitlerin kaybedilmeden hızlanmasını ve az yer kazanmasını sağlar. Neredeyse her iki dünyanın en iyisi. gdaladdoRGB görüntülerde mümkün olan en küçük genel bakışlar için : jpeg sıkıştırması, ortalama veya Gauss örneklemesi kullanarak en yakın varsayılan komşu yerine (genel bakış daha pürüzsüz hale gelir) ve YCBCR fotometrik genel görünümü kullanın. Bu seçenekler hakkında daha fazla bilgi için gdaladdo referans sayfasına bakın (tüm fotometriklerin neyle ilgili olduğu hakkında pek bir şey söylemez).

Bu, bir dizindeki tüm tifflere harici jpeg genel bakışları uygulamak için kullandığım windows toplu iş dosyasının bir parçasıdır:

set _opts= -r gauss --config PHOTOMETRIC_OVERVIEW YCBCR ^
--config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 85

for %%a in (*.tif) do gdaladdo -ro %_opts% %%a 2 4 8 16 32 64

notlar

GDAL 1.6.0 , yüksek kontrastlı veya gürültülü desenleri olan keskin kenarlarda gaussdaha iyi sonuçlara yol açabilen yeniden örneklemeyi başlattı average. 2 seviyeli (2 4 8 ...) güçler kullanılmalı, böylece 3x3 örneklemeli bir Gauss çekirdeği seçilmelidir.

JPEG_QUALITY_OVERVIEW 85 - Belirtilmezse, varsayılan% 75 kullanılır, bu da daha küçük bir dosya oluşturur, ancak% 85'i kalite ticaretiyle kıyaslandığında daha iyi bir uzlaşma buluyorum.

Güncelleme, 2015: GDAL 1.8 ve 2.0 burada ele alınmayan ve sindirmeye vaktim olmadı. Resmi gtiff format sayfasını okuyun, ayrıntılı ek ayarlar bulunduğundan eminim.

Büyük rasterler için GeoTiff, GeoTiff dosyasına ekstra görüntüler olarak küçültülmüş genel bakışları kaydetme (önceden) imkanı sunar. Bu gladladdo ile yapılabilir (= GDAL ADD Genel Bakış). Bu genel bakışları oluştururken, gdal'a onları da sıkıştırmasını manuel olarak söyleyebilirsiniz:

gdaladdo --config COMPRESS_OVERVIEW JPEG 

Çok fazla boyut eklemeden verilerinizi görüntülemeyi hızlandırır. Not: Geoserver, uDig, AtlasStyler , Geopublisher gibi Geotools uygulamaları bu özelliği kullanabilir ve genel bakıştan yararlanabilir.

Kısmi görüntü dekompresyonunu etkinleştirmek için, sadece TILED = YES kullanın.

Peter

Sonuçta muhtemelen farklı seçeneklerle denemeler yapmanız ve ihtiyaçlarınızı karşılayan şeyleri görmeniz gerekir.

JPEG sıkıştırmalı GeoTIFF'leri dalgacık tabanlı formatlar üzerinden daha fazla kullanıyorum. Sonuçlarım oldukça iyi geçti. Bunu yapmak için GDAL kullanılması, çok fazla veri kaybı olmadan dalgacık tabanlı formatlarla karşılaştırılabilir sıkıştırma oranları sağlamıştır. Dekompresyon ile gelen performans isabeti kabul edildi.

Bu yaklaşımdan en çok sevdiğim şey, GeoTIFF desteğinin neredeyse evrensel olması, dalgacık tabanlı format desteği her zaman garanti edilemiyor ve bazen de ciddi lisans sorunlarına maruz kalıyor.

GeoTIFF'e karşı Dünya Kaynak Haritalaması'nın ECW ( Geliştirilmiş Sıkıştırılmış Dalgacık ) sıkıştırmasını karşılaştırma deneyimim , ECW'nin yüksek çözünürlüklü hava fotoğrafları sıkıştırırken daha büyük siparişler olduğu yönünde. Dalgacık tabanlı sıkıştırmanın bir diğer önemli avantajı, GeoTIFF, JPEG - JPEG 2000 değil - eski biçimlerden farklı olarak , görüntünün sadece bir kısmının açılabilmesidir [ref. 1]. Bu avantajın önemi, özellikle “yaklaşık yarım bilgisayar bellek boyutundan daha büyük” ile çalışırken göz ardı edilmemelidir.

Öyle görünüyor - o - Ben onu test şansını yoktu MrSID , başka propietary, dalgacık tabanlı dosya biçimi, aynı zamanda "eski" biçimleri ve seçici dekompresyon daha yüksek sıkıştırma oranları sergiler.

ref. 1: http://www.ifp.uni-stuttgart.de/publications/phowo01/Ueffing.pdf

@Dodobas ve @ matt-wilkie'nin yanıtları, görüntü boyutunu azaltmak için GDAL ile sıkıştırma ve bulanıklaştırma eylemleriyle ilgili her şeyi kapsar.

İki şey eklemek istiyorum:

• GDAL'den dosya formatı dokümantasyonu: http://www.gdal.org/frmt_gtiff.html ;
  • Özellikle oluşturma seçeneklerine ( -co) bakın :
    • COMPRESS
    • NUM_THREADS
    • PREDICTOR
    • ZLEVEL
• ve GeoTIFF’leri tüketecek olan yazılımın doğrulanmasının şart olduğunu;
  • istenen sıkıştırma yöntemini destekler;
  • sıkıştırma kullanılmasını önerir.

Örneğin, GeoServer yok değil GeoTiff sıkıştırarak tavsiye :

Son bir not olarak, Geotiff çeşitli sıkıştırma türlerini desteklemektedir, ancak kullanmamanızı öneririz. Çok daha küçük dosyalara izin verirken, dekompresyon işlemi pahalıdır ve her veri erişiminde gerçekleştirilir, böylece görüntülemeyi önemli ölçüde yavaşlatır. Tecrübelerimize göre, dekompresyon zamanı, saf disk verisi okumasından daha yüksektir.

Bu, özellikle genel bakış, döşeme ve yüksek performanslı depolama ortamı (şirket sınıfı disk veya SSD) kullanıyorsanız geçerlidir.

Daha yeni GDAL sürümleri kullananlar için kayıpsız ZStandard ( ZSTD ) sıkıştırma (GDAL> = 2.3) ve kayıplı Sınırlı Hata Raster Sıkıştırma ( LERC ) sıkıştırma (GDAL> = 2.4) seçenekleri de mevcut.

Genellikle rağmen konuşma, ZSTDdaha hızlı veri hem daha hızları okuma sunuyor LZWve DEFLATEdosya yazarken biraz daha yavaş olabilir gerçi (kullandığınız ayarlara bağlı olarak), benzer sıkıştırma oranları.

Veri kesinliği konusunda endişeli değilseniz (örneğin yalnızca analiz yerine görselleştirme yapıyorsanız), LERCiyi bir seçenek olabilir. MAX_Z_ERRORNe kadar hassasiyetten fedakarlık yapmaya istekli olduğunuzu ayarlayabilmeniz için bir ayar var. Örneğin, a MAX_Z_ERROR=0.001veya 1 mm, bir referans değerinde% 50'lik bir yer tasarrufu sağlamıştır (bkz. Ref ).

En iyi kısmı da kullanarak LERCile birleştirebilirsiniz ! Veya kullanmayı tercih ediyorsanız yapabilirsiniz . Ayrıca, resmi GDAL GeoTIFF docs https://gdal.org/drivers/raster/gtiff.html#creation-options adresindeki kombinasyonların / ayarların tam listesine bakın.ZSTDCOMPRESS=LERC_ZSTDDEFLATECOMPRESS=LERC_DEFLATE

Bu değerli referansta daha fazla ayrıntı ve tam karşılaştırma karşılaştırması bulabilirsiniz:

• 'GeoTIFF sıkıştırma ve GDAL ile optimizasyon kılavuzu ' by @kokoalberti