rasterio / rasterio-wheels

MIT License
11 stars 16 forks source link

Thoughts on using a newer version of libtiff in the wheels? #35

Closed snowman2 closed 4 years ago

snowman2 commented 4 years ago

https://github.com/rasterio/rasterio-wheels/blob/e034219ee5c3365d5537b4c56770e630e656c493/config.sh#L186

I am definitely ignorant on the background for the version choice of libtiff, so feel free to fill me in there. I had issues assisting someone install rasterio on an OSX machine and everything worked except that they were not being able to read in tiff files written with LZMA compression. I attempted a no-binary install on OSX using the brew version of GDAL without success. I eventually got it working with conda.. But, I am wondering if upgrading libtiff would resolve the issue (or there could be some other dependency I missed that is causing the issue)? I will try to do some more testing later, but I don't have an OSX machine, so hard to tell :man_shrugging:.

snowman2 commented 4 years ago

Hmmm, maybe related to #23?

snowman2 commented 4 years ago

I should note that I would be willing to take a stab at it if this is desired.

snowman2 commented 4 years ago

Looks like it is the same on Linux with the wheel.

Using conda-forge version of rasterio:

$ rio info left_fire_mask_lzma.tif 
{"bounds": [-38.03055763850527, -17.7023992620617, -30.161809373564015, 0.6521191626776859], "colorinterp": ["gray"], "compress": "lzma", "count": 1, "crs": "EPSG:4326", "descriptions": ["0"], "driver": "GTiff", "dtype": "uint8", "height": 2076, "indexes": [1], "interleave": "band", "lnglat": [-34.09618350603464, -8.525140049692007], "mask_flags": [["nodata"]], "nodata": 241.0, "res": [0.008841290185327255, 0.008841290185327257], "shape": [2076, 890], "tiled": false, "transform": [0.008841290185327255, 0.0, -38.03055763850527, 0.0, -0.008841290185327257, 0.6521191626776859, 0.0, 0.0, 1.0], "units": [null], "width": 890}

With wheel (1.1.2):

$ rio info left_fire_mask_lzma.tif 
WARNING:rasterio._env:CPLE_AppDefined in left_fire_mask_lzma.tif:LZMA compression support is not configured
Usage: rio info [OPTIONS] INPUT

Error: Invalid value for "INPUT": left_fire_mask_lzma.tif is not a valid input file
snowman2 commented 4 years ago

With the wheel:

>>> rds = rasterio.open("left_fire_mask_lzma.tif")
Traceback (most recent call last):
  File "rasterio/_base.pyx", line 216, in rasterio._base.DatasetBase.__init__
  File "rasterio/_shim.pyx", line 67, in rasterio._shim.open_dataset
  File "rasterio/_err.pyx", line 205, in rasterio._err.exc_wrap_pointer
rasterio._err.CPLE_AppDefinedError: Cannot open TIFF file due to missing codec.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
...
  File "rasterio/_base.pyx", line 218, in rasterio._base.DatasetBase.__init__
rasterio.errors.RasterioIOError: Cannot open TIFF file due to missing codec.
snowman2 commented 4 years ago

Looks like there is a config option for GDAL somewhere: https://lists.osgeo.org/pipermail/gdal-dev/2014-October/040196.html

Probably only GDAL LZMA-enabled 
> builds with internal libtiff (or with external libtiff 4.0.X built against 
> liblzma) will be able to deal with that.
sgillies commented 4 years ago

@snowman2 the libtiff distributed with GDAL is just fine. Even makes sure that the projects are well synchronized.

snowman2 commented 4 years ago

Fantastic - glad to hear that it is kept up-to-date. In the digging I did, I found what I was looking for with the --with-liblzma flag in #38. Thoughts on adding that?

sgillies commented 4 years ago

I'd rather not add it @snowman2. I don't know that it is commonly used. Drawing these kind of lines is so difficult because the GDAL project will not, but distributing and supporting a compiled package is different: there's a cost to every additional format driver or codec.

snowman2 commented 4 years ago

Okay, thanks for getting back on that. I will close the PR.