Próbuję scalić 14 geotiff w ten sposób:
Każda geotiff ma około 50 Mb. Potrzebuję geotiffa na wyjściu
Mój obieg pracy:
gdalbuildvrt -input_file_list list.txt test.vrt (gdzie moja lista zawiera nazwy tifów)
Następnie :
gdal_translate -of Gtiff test.vrt test.tif
Input file size is 79841, 59955Działa, ale wynikiem jest geotiff o wartości 13,3 Gb! Dla 14 plików, każde 50 Mb, próbowałem geotiff 700 Mb, a nie 13 Gb.
Wiem, że gdal nie kompresuje się domyślnie, więc wypróbowałem to polecenie:
gdal_translate -of Gtiff -co COMPRESS=JPEG test.vrt test_compressed.tifAle „scalenie” pliku jest zbyt duże do kompresji 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
...Więc spróbowałem innego przepływu pracy i przekonwertowałem wszystkie moje pliki tif w formacie jpeg (14 Mb każdy), zbudowałem plik vrt i przetłumaczyłem go z kompresją LZW. Ale wyjściowa geotiff wynosi około 5 Gb.
Czy możesz mi powiedzieć, jaka jest najlepsza praktyka do wykonania tej pracy i czy można uzyskać jedną geotiffę o wartości 14 * 50 Mb?
Nie próbowałem tego, ale pomyślałem o scaleniu tych tifów w Photoshopie, a następnie ponownej georeferencji za pomocą współrzędnych górnego lewego / dolnego prawego. Przy takim przepływie pracy myślę, że będę miał 14 * 50 Mb, ale nie jestem pewien. I chcę nauczyć się najlepszych praktyk gdal, więc nie próbowałem tego na razie
przychodzi do brań: jeśli wejście jest w formacie tif z 8-bitowym, a eksport jest domyślnie 32-bitowy, będziesz mieć poważne problemy. więc upewnij się, że zachowałeś swoją definicję bajtu taką, jaka jest. I pamiętaj: pełny tif będzie prob. mieć 20x 50mb, ponieważ tiff jest zawsze prostokątny
Jeśli rozumiem, liczba, którą wskazałem na zielono na tym zrzucie ekranu, musi być taka sama po lewej i po prawej stronie?
Obraz wyjściowy będzie miał więcej pikseli niż suma obrazów wejściowych, ale to nie wyjaśnia dużej różnicy. Sugeruję, abyś spojrzał na cechy swoich obrazów w oparciu o gdalinfo, aby zobaczyć, jaka kompresja jest używana i sprawdzić, czy zakresy są poprawne.
14 tifów po 50 Mb były pierwotnie 14 tifami po 700 Mb, które przetworzyłem za pomocą gdal_translate przy -co COMPRESS = JPEG. Skompresowałem raster, aby zmniejszyć liczbę Mb, ale może to nie był dobry pomysł?
Ten zrzut ekranu przedstawia informacje o 2 gdalach tego samego geotiffa (01.tif), po lewej stronie zrzutu ekranu znajduje się gdalinfo nieskompresowanego Gtiffa o przepustowości 700 Mb, a po prawej ten sam Gtiff COMPRESS = JPEG, więc 50 Mb, z różnicą w kolorze zielonym:
Według mnie zakresy są poprawne, ponieważ w qgis pasuje do innego źródła danych i zdjęć satelitarnych.
* zakładając, że twoje obrazy wejściowe mają taki sam rozmiar, to daje 20000 * 12000 pikseli na obrazy wejściowe, co jest duże jak na obraz o wielkości 50 Mb, być może przekraczasz zasięg swojego układu współrzędnych podczas tworzenia mozaiki. *
Nie jestem pewien, czy rozumiesz, co rozumiesz przez „przekroczenie zasięgu”. Ale próbowałem otworzyć moją 5 Gb LZW w QGIS, a zakres jest dobry, ponieważ pasuje do innego źródła danych.
Twoja odpowiedź uświadamia mi, że Gtiff nie ma tego samego rozmiaru. Czy uważasz, że może to być przyczyną zwiększenia rozmiaru po połączeniu? Ponieważ gdal woli plik o tym samym rozmiarze. Zrobiłem gdalinfo na każdym Gtiffie, aby uzyskać jego rozmiar, jest bardzo mała różnica między rozmiarem Gtiffa:
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, 11994Następnie powinieneś spojrzeć na głębokość pikseli swoich obrazów: jeśli dane wejściowe były w bajtach,> powinieneś zachować bajty. gdal_translate -of Gtiff -ot Byte -co COMPRESS = LZW test.vrt test.tif
Próbowałem tego polecenia, ale gdal powiedział mi, że rozmiar tiff został przekroczony.
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.Ale jeśli muszę stworzyć dużą tiff, to nie rozwiązuje mojego problemu, ponieważ jest większy niż 4 Gb. Czy głębokość pikseli jest w moim przypadku ważna? (Zdjęcie HD map, następnie georeferencyjnych, a nie DEM)
Uwaga 1: Konwersja obrazów do formatu JPEG przed zbudowaniem vrt nie pomaga i możesz stracić dane.
To nie jest poważne, jeśli stracę trochę informacji. Oczywiście wolę go nie tracić, ale jeśli muszę, nie stanowi to problemu. Byłem przekonany, że wyjście byłoby jaśniejsze, gdybym pracował z JPEG, ale podsumowując, nie jest prawdą, gdy wyjście to Gtiff. To nie jest dobre rozwiązanie. Porzucam to rozwiązanie.
> Uwaga 2: pomocne jest użycie vrt: czy na pewno potrzebujesz GTiff?
Tak, potrzebuję Gtiffa, ponieważ muszę go zaimportować do aplikacji mobilnej, która wymaga geotiffu do pracy (myślę, że aplikacja może również pobierać dane geoprzestrzenne w formacie pdf, ale nigdy z tym nie pracuję i chcę zrozumieć mój problem z gdal, bo nie pierwszy raz go mam).
Próbowałem -co kafelkami = tak -co bigtiff = tak -co kompres = jpeg -co fotometryczne = ycbcr i próbowałem -co TILED = tak -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512
Te 2 polecenia działają dobrze, mam rozmiar ~ 700 Mb. Dokładnie tego się spodziewałem.
Teraz mam inny problem: nie można go szybko otworzyć przez QGIS. Muszę poczekać 15 minut (ale wychodzę, zanim QGIS otworzy tif pomyślnie). Nie wiem dlaczego. W mojej aplikacji na Androida to nie działa (być może przyczyną jest „kafelkowanie = tak”). Muszę przeczytać jakiś dokument na własną rękę.