Markus Metz pisze:
Nikos Alexandris wrote:
7. Exporting a group (the ones that automatically are created for
each imported photo and contain the red, green and blue components respectively), gives "INTERLEAVE=PIXEL" but "Block=2500x3". Is it correct to force createopt="BLOCKYSIZE=1" which gives
"Block=2500x1"?
BLOCKXSIZE and BLOCKYSIZE affect the tile size, as far as I
understand the gdal documentation. I would not change the defaults.
Leaving BLOCKXSIZE on default = 256 and setting BLOCKYSIZE to 1
should produce tiles of size 256x1.
The explanation on GDAL ML:
http://www.nabble.com/forum/ViewPost.jtp?post=18059426&framed=y
I prefer to enforce "BLOCKYSIZE=1" because this assures best rendering
prformance in QGIS for me.
8. There are several compression methods? Does compression affect significantly reading/displaying an image?
I would stay away from tiff internal compression because other
software might not support it (LZW and DEFLATE are sometimes not
supported).
From my limited experience with ESRI products, LZW dose not pose
problems and provides an optimal tradeoff between the render times and
file size. Deflate seems less supported and although compresses better
requires more CPU power to decompress.
TFW=YES would only be needed if you export a raster for an
application that can not read GeoTIFF internal metadata.
Yet it never hurts to create a TFW just in case ;).
Maciek
--
Maciej Sieczka
www.sieczka.org
Markus Metz pisze:
Nikos Alexandris wrote:
Maciek suggested to compress the overviews to save disk space. Would
this cause a viewing problem in Arc? (Have no access to any commercial
package currently).
Don't create overviews in this case. And yes, there can well be problems with ESRI products,
Use external overviews. GDAL-based software will make use of them and
they will just be ignored by other software. You umight consider
external overviews in HFA format, which is supported also by some
non-GDAL software. Check QGIS user ML archive for a recent thread
regarding overviews for some more details.
Maciek
--
Maciej Sieczka
www.sieczka.org
All I wanted to say is that for best allround compatibility, the GEOTiff output should be kept as simple as possible. If a raster export is meant to be used in a particular known application, the native raster file format of this application if existing might be preferable.
The gdal defaults INTERLEAVE=PIXEL and TILED=NO work fine, but can surely be fine tuned. Only PROFILE might need adjustment to GeoTIFF or BASELINE, says gdal documentation.
This thread seems to be about ESRI compatibility, so ESRI .hdr labelled Raster should definitively work.
Maciej Sieczka wrote:
8. There are several compression methods? Does compression affect significantly reading/displaying an image?
From my limited experience with ESRI products, LZW dose not pose
problems and provides an optimal tradeoff between the render times and
file size. Deflate seems less supported and although compresses better
requires more CPU power to decompress.
LZW is pretty good for a raster with many different cell values (e.g. imagery, elevation, NDVI) whereas packbits is great for a raster with only few categories (e.g. land cover classification).
Again, for ESRI there is also ESRI .hdr labelled, otherwise for best allround compatibility I would recommend not to use compression.
ESRI file format support is listed here:
http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Technical_specifications_for_raster_dataset_formats
TFW=YES would only be needed if you export a raster for an
application that can not read GeoTIFF internal metadata.
Yet it never hurts to create a TFW just in case ;).
Actually I remember once some ESRI application (can't remember which one and what version) really wanted a TFW file for GEOTiff, so it sure doesn't hurt and can help.
Markus