Tại sao kết quả hợp nhất của nhiều raster là rất lớn? [đóng cửa]


10

Tôi cố gắng hợp nhất 14 geotiff như thế này:

nhập mô tả hình ảnh ở đây

Mỗi geotiff khoảng 50Mb. Tôi cần một trình duyệt địa lý ở đầu ra

Quy trình làm việc của tôi:

gdalbuildvrt -input_file_list list.txt test.vrt 

(nơi danh sách của tôi chứa tên của các tifs)

Sau đó :

gdal_translate -of Gtiff test.vrt test.tif
Input file size is 79841, 59955

Nó hoạt động, nhưng kết quả là một geotiff 13,3 Gb! Đối với 14 tệp, mỗi tệp 50 Mb, tôi đã thử một thẻ địa lý 700 Mb, không phải 13 Gb.

Tôi biết rằng gdal không nén theo mặc định, vì vậy tôi đã thử lệnh này:

gdal_translate -of Gtiff -co COMPRESS=JPEG test.vrt test_compressed.tif

Nhưng "hợp nhất" của tệp quá lớn để nén JPEG:

Input file size is 79841, 59955
0ERROR 1: JPEGPreEncode:Strip/tile too large for JPEG
ERROR 1: WriteEncodedTile/Strip() failed.
ERROR 1: JPEGPreEncode:Strip/tile too large for JPEG
ERROR 1: WriteEncodedTile/Strip() failed.
ERROR 1: An error occured while writing a dirty block
...

Vì vậy, tôi đã thử một quy trình công việc khác và chuyển đổi tất cả các tif của mình trong jpeg (mỗi tệp 14 Mb), xây dựng tệp vrt và dịch nó với nén LZW. Nhưng geotiff đầu ra là khoảng 5 Gb.

Bạn có thể cho tôi biết cách thực hành tốt nhất để thực hiện công việc là gì và liệu có thể có được một geotiff 14 * 50Mb không?

Tôi đã không thử nó, nhưng tôi nghĩ về việc hợp nhất các tif này trong photoshop, sau đó tái định vị địa lý với tọa độ trên bên trái / dưới bên phải. Với quy trình làm việc này, tôi nghĩ rằng tôi sẽ có 14 * 50 Mb, nhưng tôi không chắc chắn. Và tôi muốn học những cách thực hành tốt nhất của gdal vì vậy tôi đã không thử nó vào lúc này


đến cắn: nếu đầu vào là tif với 8 bit và xuất là 32 bit theo mặc định, bạn sẽ gặp rắc rối nghiêm trọng. vì vậy hãy chắc chắn rằng bạn giữ định nghĩa byte của mình. Và hãy nhớ rằng: tif đầy đủ sẽ thăm dò. Có 20x 50mb như một tiff luôn là hình chữ nhật

Nếu tôi hiểu, số tôi chỉ màu xanh lá cây trên ảnh chụp màn hình này phải giống nhau ở bên trái và bên phải?

chút ít

Hình ảnh đầu ra của bạn sẽ có nhiều pixel hơn tổng số hình ảnh đầu vào của bạn, nhưng điều này không giải thích được sự khác biệt lớn. Tôi khuyên bạn nên xem xét các đặc điểm của hình ảnh của mình dựa trên gdalinfo để xem nén nào được sử dụng và kiểm tra xem mức độ chính xác.

14 tif 50 Mb ban đầu là 14 tif 700 Mb mà tôi đã xử lý bằng gdal_translate với -co COMPRESS = JPEG. Tôi đã nén raster để giảm số lượng Mb, nhưng có lẽ đó không phải là một ý tưởng hay?

Ảnh chụp màn hình này đại diện cho thông tin 2 gdal của cùng một geotiff (01.tif), ở bên trái của ảnh chụp màn hình là gdalinfo của Gtiff không nén 700 Mb, kết thúc bên phải cùng Gtiff với COMPRESS = JPEG, vì vậy 50 Mb, với độ lệch màu xanh lục:

không nén và nén gdalinfo của tệp 01.tif

Theo tôi, phạm vi là chính xác bởi vì trong qgis, nó phù hợp với nguồn dữ liệu và hình ảnh vệ tinh khác.

* giả sử hình ảnh đầu vào của bạn có cùng kích thước, nó tạo ra 20000 * 12000 pixel cho mỗi hình ảnh đầu vào, lớn cho hình ảnh 50 Mb, có thể bạn đang vượt qua phạm vi hệ thống tọa độ của mình khi bạn tạo khảm. *

Tôi không chắc bạn hiểu ý của bạn bằng cách "vượt qua phạm vi". Nhưng tôi đã cố gắng mở 5 Gb LZW của mình trong QGIS, và mức độ là tốt, bởi vì nó phù hợp với nguồn dữ liệu khác.

Câu trả lời của bạn khiến tôi nhận ra rằng Gtiff không có cùng kích thước, bạn có nghĩ nó có thể là nguyên nhân của việc tăng kích thước khi sáp nhập không? Bởi vì gdal thích tập tin có cùng kích thước. Tôi đã tạo một gdalinfo trên mỗi Gtiff để có kích thước của nó, có một sự khác biệt rất nhỏ giữa kích thước của Gtiff:

02.tif Size is 19956, 11981
03.tif Size is 19959, 11993
04.tif Size is 19961, 11992
05.tif Size is 19958, 11993
06.tif Size is 19958, 11990
07.tif Size is 19956, 11984
08.tif Size is 19956, 11993
09.tif Size is 19958, 11993
10.tif Size is 19958, 11989
11.tif Size is 19958, 11985
12.tif Size is 19958, 11993
13.tif Size is 19959, 11993
14.tif Size is 19960, 11994

Sau đó, bạn nên xem độ sâu pixel của hình ảnh: nếu đầu vào của bạn bằng Byte,> thì bạn nên giữ byte. gdal_translate -of Gtiff -ot Byte -co COMPRESS = LZW test.vrt test.tif

Tôi đã thử lệnh này nhưng gdal nói với tôi rằng kích thước của tiff đã vượt quá.

Input file size is 79841, 59955
0...10...20...30...40...50..ERROR 1: TIFFAppendToStrip:Maximum TIFF file size exceeded. Use BIGTIFF=YES creation option.
ERROR 1: WriteEncodedTile/Strip() failed.

Nhưng nếu tôi phải tạo ra một tiff lớn, nó không giải quyết được vấn đề của tôi vì nó lớn hơn 4 Gb. Là độ sâu pixel quan trọng trong trường hợp của tôi? (Ảnh HD của bản đồ, sau đó tham chiếu địa lý, không phải DEM)

Lưu ý 1: Chuyển đổi hình ảnh của bạn sang jpeg trước khi xây dựng vrt không giúp ích và bạn có thể mất dữ liệu.

Nó không nghiêm trọng nếu tôi mất một chút thông tin. Tôi không muốn mất nó, tất nhiên, nhưng nếu tôi không phải là một vấn đề. Tôi đã bị thuyết phục rằng đầu ra sẽ nhẹ hơn nếu tôi làm việc với jpeg, nhưng như một kết luận, điều đó không đúng khi đầu ra là Gtiff. Vì vậy, đây không phải là một giải pháp tốt. Tôi từ bỏ giải pháp này.

> Lưu ý 2: sử dụng vrt rất hữu ích: bạn có chắc chắn rằng mình cần GTiff không?

Có, tôi cần một Gtiff, vì tôi phải nhập nó trong một ứng dụng di động cần đầu vào geotiff để hoạt động (Tôi nghĩ ứng dụng này cũng có thể nhập đầu vào pdf không gian địa lý, nhưng tôi không bao giờ làm việc với nó và tôi muốn hiểu vấn đề của mình với gdal, vì đó không phải là lần đầu tiên tôi có nó).


Tôi đã thử -co tiled = yes -co bigtiff = yes -co nén = jpeg -co photometric = ycbcr và tôi đã thử -co TILED = yes -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512

Hai lệnh này hoạt động tốt, tôi có kích thước ~ 700 Mb. Nó chính xác là những gì tôi mong đợi.

Bây giờ tôi có một vấn đề khác: nó không thể được mở nhanh chóng bởi QGIS. Tôi phải đợi 15 phút (nhưng tôi đã thoát trước khi QGIS mở tif thành công). Tôi không biết tại sao. Và trong ứng dụng Android của tôi, nó không hoạt động (có thể là nguyên nhân của "tiled = yes"). Tôi phải tự đọc một số tài liệu.


Sử dụng -co tiled = yes -co bigtiff = yes -co nén = jpeg -co photometric = ycbcr
user30184

Câu trả lời:


2

Hình ảnh đầu ra của bạn sẽ có nhiều pixel hơn tổng số hình ảnh đầu vào của bạn, nhưng điều này không giải thích được sự khác biệt lớn. Tôi khuyên bạn nên xem xét các đặc điểm của hình ảnh của mình dựa trên gdalinfo để xem nén nào được sử dụng và kiểm tra xem mức độ chính xác. (giả sử hình ảnh đầu vào của bạn có cùng kích thước, nó tạo ra 20000 * 12000 pixel cho mỗi hình ảnh đầu vào, lớn cho hình ảnh 50 Mb, có thể bạn đang vượt qua phạm vi hệ thống tọa độ của mình khi tạo khảm.) Sau đó, bạn nên nhìn vào độ sâu pixel của hình ảnh của bạn: nếu đầu vào của bạn bằng Byte, thì bạn nên giữ byte.

gdal_translate -of Gtiff -ot Byte -co COMPRESS=LZW test.vrt test.tif 

Lưu ý 1: Chuyển đổi hình ảnh của bạn sang jpeg trước khi xây dựng vrt không giúp ích (nó sẽ không bị nén trước bước tiếp theo) và bạn có thể mất dữ liệu.

Lưu ý 2: sử dụng vrt rất hữu ích: bạn có chắc chắn rằng bạn cần GTiff không?

EDIT: Không có phép màu nào với kích thước hình ảnh của bạn, nhưng bạn nên sử dụng tif tiled làm đầu ra để bạn có thể sử dụng nén jpeg với dữ liệu lớn của mình (-co TILED = yes -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512 ). Nếu nó vẫn quá lớn, giải pháp duy nhất là sử dụng gdalwarp để lấy mẫu lại ở độ phân giải thấp hơn.


đến cắn: nếu đầu vào là tif với 8 bit và xuất là 32 bit theo mặc định, bạn sẽ gặp rắc rối nghiêm trọng. vì vậy hãy chắc chắn rằng bạn giữ định nghĩa byte của mình. Và hãy nhớ rằng: tif đầy đủ sẽ thăm dò. có 20x 50mb như một tiff luôn là hình chữ nhật.
Riccardo

Bạn đã nhận được 20000 x 12000 từ đâu? Đầu ra được hiển thị trong câu hỏi sẽ đề xuất hình ảnh đầu vào là 79841 x 59955.
Evil Genius

79841, 59955 là kích thước của vrt đầu vào. nhưng có 5 hàng và 4 cột, vì vậy tôi chia ~ 80000 cho 4 và ~ 60000 cho 5. Như tôi đã nói, điều này giả định rằng các hình ảnh có cùng kích thước và được định vị như trên hình.
radouxju

Tôi đã trả lời bằng cách chỉnh sửa câu hỏi ban đầu của mình, tôi hy vọng nó phải tiếp tục.
grimdaemon
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.