У меня есть функция, которая считывает многодиапазонное изображение в качестве объекта растрового кирпича, выполняет итерации по группам, выполняющим различные вычисления, а затем записывает растровые изображения как новый .tif. Все это прекрасно работает, но размер файла нового изображения примерно в четыре раза больше (я предполагаю, что исходное изображение имеет 4 полосы). Мне интересно, есть ли параметр в функции writeRaster(), о котором я не знаю, или если есть какой-то другой способ, я могу гарантировать, что выходное изображение в основном такое же размер файла, как и вход.Размер файла выходного файла writeRaster
Оригинальный размер файла - 134 МБ; выходной диапазон от 471 до 530 МБ или около того, в зависимости от формата.
упрощенный код:
library(rgdal)
library(raster)
path = "/Volumes/ENVI Standard Files/"
img = "qb_tile.img"
imageCorrection = function(path, img){
raster = brick(paste0(path, img))
raster = reclassify(raster, cbind(0, NA))
for(i in 1:[email protected]@nbands){
raster[[i]] = raster[[i]] - minValue(raster[[i]])
}
writeRaster(raster, paste0(path,img,"_process.tif"), format = "GTiff", overwrite=TRUE)
}
Итак, входы и выходы имеют точно такое же количество пикселей и диапазонов? Так что ваш файл .img использует лучшее сжатие, чем ваш .tiff, или файл .img хранит с меньшей точностью (например, 8-битные int), и ваш .tiff хранит 4 байтовые поплавки .... Или и то и другое. Что говорит sp :: GDALinfo о ваших файлах? – Spacedman
Да, похоже, это проблема. GDALinfo указывает, что выход записывается как FLT4S, в то время как вход поступает как INT2U. Я попытался изменить тип данных вывода, но ничего, кроме FLT4S, создает пустую картинку (data = 0-1). – Danple
https://stat.ethz.ch/pipermail/r-sig-geo/2015-January/022246.html – Danple