Exporting data as .tiff

I am trying to export a subset of data as a .tiff file, but when i go to >export data>GEOTIFF the file is always written as a .tif file.
the same thing happens if i selecy >export.>GEOTIFF/BIGTIFF
How do I write a .tiff file that i can read into python?
I have looked all over this forum and can’t find an answer!

you can easily read img files (inside the .data folder of the BEAM DIMAP folder) into python.

Regardless, there should be no difference between a .tif and a .tiff file (at least I have never experienced problems with eithe of them).

Thanks, I’ll try using rasterio.
However, it doesnt answer my question. I’ve just tried to export a file asgoeTIFF, and SNAP has writen the file with the following file name to my computer : subsets/subset_0_of_S2A_MSIL2A_20200919T113321_N0214_R080_T30UVD_20200919T142636_ndvi.tiff.tif
I have files with the extension .tiff which i can open using Image.open("**") and then convert into a numpy array to read the pixel values, i have written code to do this on a range of .tiff files.
Why does SNAP not want to write a .tiff file anymore?

Summary:

TIF and TIFF are the same exact thing
TIF is used in legacy file systems that use the 8.3 naming convention while TIFF is used in newer file systems that allow long filenames.

Source: http://www.differencebetween.net/technology/protocols-formats/difference-between-tif-and-tiff/

1 Like

@mengdahl They are very obviously not the same thing.
I use the latest version of Spyder to do my python coding, files with the extension .tif will not open using Image.open.
Files with the extension .tiff will open.
I will repeat my question.
Why does SNAP export files with the extension .tif when geoTIFF or geoTIFF/big TIFF is selected?

Do you have GDAL? What do you get if you run gdalinfo on those files?

.tif and .tiff are identical, but it’s not impossible that SNAP might get confused and pick a different format if you try to set the extension manually.

Why does SNAP export files with the extension .tif when geoTIFF or geoTIFF/big TIFF is selected?

Because tif is the most used extension for TIFF files, just like jpg is used for JPEGs (you rarely see a .jpeg). Assuming the file is written correctly, there’s no point in considering changing that. Some other user will surely complain that SNAP is not using tif anymore.


Until definite proof, "why is SNAP using the tif extension instead of tiff" is the wrong question to ask. Instead, you should say “I saved a file with SNAP by doing these steps, you can find it here, I’m trying to load it in Python using this library and I get this error”.

2 Likes

I saved a file with SNAP as shown here:


the resulting file will,not open with Image.open as shown in line 15. (Line 14 shows a file with the extension .tiff opening correctly)

Can you compress (with ZIP) and upload the file somewhere? You can use https://nas.dend.ro/browse/upload if you can’t use one of the free file transfer sites (note that on this one it’s hard to tell when the transfer has finished).

If it’s syntax-related you can rename the .tif:s into .tiff:s. Does gdalinfo recognise the format?

Just from curiosity, have you tried to rename the *.tiff.tif into simple *.tiff (since .tiff is what you need) ?

If that’s pillow, it seems to read at least some GetTIFFs with the .tif extension just fine (albeit it warns about them being too large).

@lnicola I uploaded the file to the link you sent, after i had renamed it to have a .tiff extension
@mengdahl I’m afraid I dont know how to run gdalinfo, I very rarely use command line, not very good with it!
@oana_hogoiu i renamed a couple of the files, and they dont work with Image.open :slight_smile:

I uploaded the file to the link you sent, after i had renamed it to have a .tiff extension

Thank you. The file is valid, but has an uncommon format, and pillow can’t open it:

>>> img = Image.open("Downloads/subset_0_of_S2A_MSIL2A_20200919T113321_N0214_R080_T30UVD_20200919T142636_ndvi.tiff")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/site-packages/PIL/Image.py", line 2958, in open
    raise UnidentifiedImageError(
PIL.UnidentifiedImageError: cannot identify image file 'Downloads/subset_0_of_S2A_MSIL2A_20200919T113321_N0214_R080_T30UVD_20200919T142636_ndvi.tiff'

>>> from osgeo import gdal
>>> gdal.Open("Downloads/subset_0_of_S2A_MSIL2A_20200919T113321_N0214_R080_T30UVD_20200919T142636_ndvi.tiff")
Warning 1: TIFFReadDirectory:Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples.
<osgeo.gdal.Dataset; proxy of <Swig Object of type 'GDALDatasetShadow *' at 0x7fb0a36d3330> >

As you can see, GDAL can read it just fine, while PIL/pillow can’t.

gdalinfo output:

Warning 1: TIFFReadDirectory:Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples.
Driver: GTiff/GeoTIFF
Files: subset_0_of_S2A_MSIL2A_20200919T113321_N0214_R080_T30UVD_20200919T142636_ndvi.tiff
Size is 510, 552
Coordinate System is:
PROJCRS["WGS 84 / UTM zone 30N",
    BASEGEOGCRS["WGS 84",
        DATUM["World Geodetic System 1984",
            ELLIPSOID["WGS 84",6378137,298.257223563,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4326]],
    CONVERSION["UTM zone 30N",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",-3,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",0.9996,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["(E)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["(N)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["unknown"],
        AREA["World - N hemisphere - 6°W to 0°W - by country"],
        BBOX[0,-6,84,0]],
    ID["EPSG",32630]]
Data axis to CRS axis mapping: 1,2
Origin = (437460.000000000000000,5832360.000000000000000)
Pixel Size = (10.000000000000000,-10.000000000000000)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_RESOLUTIONUNIT=1 (unitless)
  TIFFTAG_XRESOLUTION=1
  TIFFTAG_YRESOLUTION=1
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (  437460.000, 5832360.000) (  3d55'27.08"W, 52d38'15.40"N)
Lower Left  (  437460.000, 5826840.000) (  3d55'23.32"W, 52d35'16.78"N)
Upper Right (  442560.000, 5832360.000) (  3d50'55.80"W, 52d38'17.43"N)
Lower Right (  442560.000, 5826840.000) (  3d50'52.34"W, 52d35'18.80"N)
Center      (  440010.000, 5829600.000) (  3d53' 9.64"W, 52d36'47.13"N)
Band 1 Block=512x512 Type=Float64, ColorInterp=Gray
Band 2 Block=512x512 Type=Float64, ColorInterp=Undefined

The problem is that the file floating-point pixel values, which pillow doesn’t support. Here is another file:

>>> img = Image.open("SEN4CAP_L2A_PRD_S1_W201829_T30SWJ_DESC_VV_COHE_10m.tif")
>>> 
# works
$ gdal_translate -ot Float64 SEN4CAP_L2A_PRD_S1_W201829_T30SWJ_DESC_VV_COHE_10m.tif x.tif
Input file size is 10980, 10980
0...10...20...30...40...50...60...70...80...90...100 - done.
>>> img = Image.open("x.tif")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/site-packages/PIL/Image.py", line 2958, in open
    raise UnidentifiedImageError(
PIL.UnidentifiedImageError: cannot identify image file 'x.tif'

You should consider using GDAL (or something easier like rasterio), it’s used by pretty much everyone who needs to read geospatial data.

1 Like

Thanks, I’ve been looking at rasterio this afternoon, hadn’t heard of it until today!
It certainly looks like it could be useul for extracting pixel values.
Now i just have to find enough images without 97% cloud cover (which is difficuly for Wales!!)