1

So when I try to use imread on a TIFF-file, it raises this error.

The TIFF-file in question is a TIFF I created and modified in another script. I initially created it like this: temp = np.full([max_y, max_x], np.nan). Then I looped the cells and changed the cell values. Afterwards I used cv2.imwrite to write it to a file.

However the original script where I create and modify the TIFF-file also opens it after writing the file so no clue why it opens then, and not in this new script. The only change I've made since then is copying the file.

I can also open the file in QGIS so no clue what the problem is.

EDIT: this is the picture https://drive.google.com/file/d/1CjAGegeA9RUmTtgd_8xgrRPqOLx8NdMa/view?usp=sharing

The relevant part of the code you can find here: https://codeshare.io/5oYNDo. The error occurs in line 32.

EDIT 2: With the help of Mark I've got it transformed to a 32-bit image: https://drive.google.com/file/d/1xDyqeEzMrB-84ms9BB7YztbT-_kfJpeG/view?usp=sharing. However plt.imread still didn't work. So now I am using img_arr = np.asarray(Image.open(img)). However this results in a strange bug: the array is full of NaN's but when I hover over a picture I do get the cell value. (https://i.stack.imgur.com/oWrBt.jpg) Because of the array full of NaN's vmin and vmax are not working properly, that's why the whole picture is yellow. If I remove the vmin and vmax it's visualized as it should. But the array full of NaN's will result in problems further in the script so this has to be solved first.

Jan-Pieter
  • 137
  • 2
  • 10
  • 1
    Kindly share the *"unhappy"* TIFF (or the code that created it), and the code that fails to read it along with the error messages... else it is very difficult to even guess what's wrong. – Mark Setchell Mar 12 '20 at 19:06
  • @MarkSetchell I've added both to the question – Jan-Pieter Mar 12 '20 at 19:57
  • I'm confused now:-) You seem to be saying the `NaN`s are now causing issues, but at the start you say you filled the array with `Nan`s yourself. I'm wondering why you don't fill the array with something else instead? – Mark Setchell Mar 13 '20 at 16:19
  • I'm sorry, I found the problem: I had to use np.nanpercentile instead of np.percentile in my vmin and vmax. That's why I thought the whole image was NaN, while there were cell values visible in the image. Thank you for all your help Mark, without you I wouldn't have been able to solve it! – Jan-Pieter Mar 13 '20 at 19:19

1 Answers1

1

Your image is a 64-bit floating point TIFF. You can see that with:

tiffinfo v3l1_24-34.tiff

Or with ImageMagick:

magick identify -verbose v3l1_24-34.tiff

PIL doesn't like such things, so you either need to either create it as 32-bit:

temp = np.full(..., dtype=np.float32)

or, if you need 64-bit, maybe read it with tifffile:

import tifffile
...
im = tiffffile.imread('v3l1_24-34.tiff')

If you have some pre-existing BigTIFF files you want to make into 32-bit classic TIFF files, you can try the following commands:

# Use an ImageMagick version with Q16 or higher and HDRI when you run "identify -version"
magick input.tif -define quantum:format=floating-point -depth 32 output.tif

# Or use "libvips" in the Terminal
vips im_vips2tiff input.tif output.tif

To check if a file is a BigTIFF or not, use exiftool and look for BTF like this:

exiftool bigtiff.tif 
ExifTool Version Number         : 11.11
File Name                       : bigtiff.tif
Directory                       : .
File Size                       : 1024 kB
File Modification Date/Time     : 2020:03:13 13:56:05+00:00
File Access Date/Time           : 2020:03:13 13:56:19+00:00
File Inode Change Date/Time     : 2020:03:13 13:56:11+00:00
File Permissions                : rw-r--r--
File Type                       : BTF           <--- HERE
...
...

Or use xxd like this and look for 3rd byte being 0x2b:

xxd bigtiff.tif | more
00000000: 4949 2b00 0800 0000 1000 1000 0000 0000  II+.............
...
...

whereas a ClassicTIFF shows up as 0x2a:

xxd classic.tiff | more
00000000: 4949 2a00 0800 1000 0000 803f 0000 803f  II*........?...?
Mark Setchell
  • 191,897
  • 31
  • 273
  • 432
  • Interesting, I didn't know that. Do you know why it did work in the original script? I'll try it out tomorrow morning! Thanks already for the help. – Jan-Pieter Mar 12 '20 at 22:05
  • I've just tried it out and you were right, this was indeed the problem. However I still don't know why I can open it in the original script. – Jan-Pieter Mar 13 '20 at 09:02
  • Using tifffile.imread, the image is read as an array of NaN's: https://imgur.com/a/fsobEEV – Jan-Pieter Mar 13 '20 at 09:11
  • You seem to mention an original script and another script and I am not certain which one you mean or which script you show in your question, or what has changed in between. I don't use `Matplotlib` much, but I believe it uses PIL/Pillow underneath which definitely doesn't like 64-bit floats - see link in my answer. Normally, I see best chances of success with `tifffile`, `libvips` or OpenCV. Saving as 32-bit float instead of a 64-bit float is likely to increase your chances of compatibility. – Mark Setchell Mar 13 '20 at 09:15
  • Okay from now on I'll save them as 32 bit. Is there any way I could convert these 64 bit images to 32 bit because it took a long time to create them? – Jan-Pieter Mar 13 '20 at 10:14
  • You should be able to use **ImageMagick** in the Terminal. If you have IM v6, use `convert input.tif output.tif` and check with `identify -verbose output.tif` If you have IM v7, use `magick input.tif output.tif` and check with `magick identify -verbose output.tif` – Mark Setchell Mar 13 '20 at 10:34
  • You can also check with `tiffdump image.tif` for version `0x2a` (Classic TIFF) or version `0x2b` (BigTIFF) Or with `exiftool image.tif` - look for filetype=BTF. – Mark Setchell Mar 13 '20 at 10:36
  • Or with `xxd image.tif` and look at the 3rd byte being `2a` or `2b` as above. – Mark Setchell Mar 13 '20 at 10:38
  • At the moment I'm trying to do it in ArcMap. If it doesn't work I'll try out your suggestions. Thanks! – Jan-Pieter Mar 13 '20 at 10:55
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/209567/discussion-between-jan-pieter-van-parys-and-mark-setchell). – Jan-Pieter Mar 13 '20 at 12:01