[gdal-dev] gdal_rasterize processed GTiff filesize question

[Andrey VI]

Yes, the target files already exists. Yes, I’ve tried to investigate this issue on some small and medium files. For example:
original hillshade.tif size is 11469 bytes, after gdal_rasterize its size is 26465 bytes, and after gdal_translate - 15426 bytes,
original - 7477 K, gdal_rasterize - 8705 K, gdal_translate - 5964 K,
original - 39110 K, gdal_rasterize - 39112 K, gdal_translate - 446 K.
So,  it depends on the content of the raster.
I would like to avoid intermediate processing if possible. This will require additional time for processing and space for the data. Moreover, in some cases a lot of space needs to be allocated for intermediate files.
 
Andrey
>Tuesday, March 19, 2024 4:25 PM +03:00 from Rahkonen Jukka < jukka.rahkonen at maanmittauslaitos.fi >:
> 
>Hi,
> 
>So the target files dem.tif and hillshade.tif exist already? Maybe it is not so simple to update already compressed data in place. Have you tried what happens if you re-write the results into new files
>
>gdal_translate -co tiled=yes -co compress=LZW hillshade.tif final_hillshade.tif.
> 
>-Jukka Rahkonen-
> 
>Lähettäjä: gdal-dev < gdal-dev-bounces at lists.osgeo.org >  Puolesta  Andrey VI via gdal-dev
>Lähetetty: tiistai 19. maaliskuuta 2024 14.43
>Vastaanottaja: gdal-dev at lists.osgeo.org
>Aihe: [gdal-dev] gdal_rasterize processed GTiff filesize question
> 
>Hello.
> 
>I’m using gdal_rasterize to remove some data from DEM (Int16) and hillshade (Byte) rasters with shape-file, like this:
>gdal_rasterize -burn -32768 shape.shp dem.tif and gdal_rasterize -burn 0 shape.shp hillshade.tif
>Both DEM and hillshade GTiffs created with -co COMPRESS=LZW -co TILED=YES options. After processing with gdal_rasterize the  size of GTiffs becomes 1.5 times larger . Why it happens?  I assumed that it should be the other way around, because a significant portion of the data is replaced with the same values and should be compressed well.
> 
>Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240319/b18369b1/attachment.htm>