Frank Warmerdam pisze:
Maciej Sieczka wrote:
It is very important for all gdalwarp users.
I disagree with the above statement. I think it is a small
segment of people who create compressed files with gdalwarp, and
there is a fairly straightforward workaround (warp then compress).
Since gdalwarp supports compressing tiffs, who would guess he has to do
something extra? gdalwarp makes an impression of being able to warp and
compress in one step. Not many users will expect that gdalwarp writes a
compressed TIFF bigger than not compressed, and that he has to fix this
with gdal_translate afterwards.
Moreover, I wonder if the guts of the issue that gdalwarp handles
compression wrong, might also affect GDAL-dependent software. Eg.
r.out.gdal in GRASS - I took the sample [1], imported into GRASS and
re-exported with:
r.in.gdal in=M-33-21-A-b-4.tif out=M-33-21-A-b-4 -o
g.region rast=M-33-21-A-b-4.red -a
r.out.gdal in=M-33-21-A-b-4 out=M-33-21-A-b-4_gr_lzw.tif
-createopt="COMPRESS=LZW" type=Byte
which created an LZW-compressed TIFF 2.33 times bigger than the
original, also LZW-compressed. Could this r.out.gdal issue be related to
gdalwarp issue?
Maciek
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
