soft-matter / pims

Python Image Sequence: Load video and sequential images in many formats with a simple, consistent interface.
http://soft-matter.github.io/pims/
Other
258 stars 67 forks source link

pims.TiffStack doesn't fetch the right content/values #141

Closed forevertheuni closed 9 years ago

forevertheuni commented 9 years ago

Hello all, Thanks for pims

So. I am having a problem with pims. When I open a TiffStack the values of the pixels of an image do not correspond to the correct values: Here's a bit of code to test it (PIL and libtiff work ok, meaning the same values as acquired by the microscope software and ImageJ): Sample file can be dled here: https://drive.google.com/file/d/0B9-erPeWaEjGdy10bFMteHdNXzQ/view?usp=sharing

Help would be much appreciated since I already wrote a bunch of functions relying on pims.

import numpy as np
import libtiff
import pims
from PIL import Image
file = 'TRIMcapture_MG132_06_R3D_D3D_3.tif'
pic = Image.open(file)
pic.size
print np.array(pic.getdata()).reshape(512,512)
print "These are the correct values"

pic2 = libtiff.TIFF.open(file).read_image()
print pic2

print "Same value, good values"
pic_pims = pims.TiffStack(file)
print pic_pims
print pic_pims[0]
print pic_pims[1]
print pic_pims[2]
print pic_pims[3]
print "not the good tif values"

And here is the output!

$ python pimsproblem.py 
[[692 691 695 ..., 703 701 696]
 [699 698 702 ..., 711 708 704]
 [705 703 707 ..., 716 713 709]
 ..., 
 [682 682 686 ..., 693 690 686]
 [680 679 683 ..., 690 688 684]
 [684 683 687 ..., 695 692 688]]
These are the correct values
[[692 691 695 ..., 703 701 696]
 [699 698 702 ..., 711 708 704]
 [705 703 707 ..., 716 713 709]
 ..., 
 [682 682 686 ..., 693 690 686]
 [680 679 683 ..., 690 688 684]
 [684 683 687 ..., 695 692 688]]
Same value, good values
<Frames>
Source: TRIMcapture_MG132_06_R3D_D3D_3.tif
Length: 34 frames
Frame Shape: 512 x 512
Pixel Datatype: uint16
[[46082 45826 46850 ..., 48898 48386 47106]
 [47874 47618 48642 ..., 50946 50178 49154]
 [49410 48898 49922 ..., 52226 51458 50434]
 ..., 
 [43522 43522 44546 ..., 46338 45570 44546]
 [43010 42754 43778 ..., 45570 45058 44034]
 [44034 43778 44802 ..., 46850 46082 45058]]
[[ 5890  5378  5890 ...,  9730  8450  7170]
 [ 7426  6914  7426 ..., 11522 10242  8706]
 [ 8706  8194  8706 ..., 12802 11522 10242]
 ..., 
 [ 6146  5634  6658 ...,  9474  8450  7426]
 [ 4098  3842  4610 ...,  7938  6658  5378]
 [ 4354  3842  4610 ...,  8194  6914  5634]]
[[12802 11522 11778 ..., 17922 16130 14338]
 [14594 13314 13314 ..., 19714 17922 16130]
 [15874 14850 14850 ..., 20994 19458 17666]
 ..., 
 [12802 11778 12034 ..., 17666 16130 14338]
 [10754  9730  9986 ..., 15874 14338 12546]
 [11010  9986 10242 ..., 16130 14594 12802]]
[[16130 14850 15106 ..., 21762 19970 17922]
 [17922 16642 16898 ..., 23298 21506 19714]
 [19202 18178 18434 ..., 24578 22786 20994]
 ..., 
 [16130 14850 14850 ..., 21762 19970 17922]
 [14082 13058 12802 ..., 19714 18178 16130]
 [14338 13314 13314 ..., 20226 18434 16386]]
not the good tif values
forevertheuni commented 9 years ago

I also get good values with: pic2 = libtiff.TiffFile(file).get_tiff_array() pic2[0],etc,etc,etc

tacaswell commented 9 years ago

What should the bit depth be on your images?

tacaswell commented 9 years ago

Something funny is going on, I can not reproduce your problem:

In [7]: fname = '/home/tcaswell/Downloads/TRIMcapture_MG132_06_R3D_D3D_3.tif'

In [8]: pic_pims = pims.TiffStack(fname)

In [9]: pic_pims[0]
Out[9]: 
Frame([[696, 704, 709, ..., 686, 684, 688],
       [701, 708, 713, ..., 690, 688, 692],
       [703, 711, 716, ..., 693, 690, 695],
       ..., 
       [695, 702, 707, ..., 686, 683, 687],
       [691, 698, 703, ..., 682, 679, 683],
       [692, 699, 705, ..., 682, 680, 684]], dtype=uint16)

Which version of TiffStack are you using (pims.TiffStack.__name__)?

tacaswell commented 9 years ago

ok, I can reproduce this now.

In [4]: pic_pims = pims.TiffStack(fname)

In [5]: pic_pims[0]
Out[5]: 
Frame([[46082, 45826, 46850, ..., 48898, 48386, 47106],
       [47874, 47618, 48642, ..., 50946, 50178, 49154],
       [49410, 48898, 49922, ..., 52226, 51458, 50434],
       ..., 
       [43522, 43522, 44546, ..., 46338, 45570, 44546],
       [43010, 42754, 43778, ..., 45570, 45058, 44034],
       [44034, 43778, 44802, ..., 46850, 46082, 45058]], dtype=uint16)

In [6]: pic_pims = pims.TiffStack_tifffile(fname)

In [7]: pic_pims[0]
Out[7]: 
Frame([[696, 704, 709, ..., 686, 684, 688],
       [701, 708, 713, ..., 690, 688, 692],
       [703, 711, 716, ..., 693, 690, 695],
       ..., 
       [695, 702, 707, ..., 686, 683, 687],
       [691, 698, 703, ..., 682, 679, 683],
       [692, 699, 705, ..., 682, 680, 684]], dtype=uint16)

In [8]: pic_pims = pims.TiffStack_pil(fname)

In [9]: pic_pims[0]
Out[9]: 
Frame([[696, 704, 709, ..., 686, 684, 688],
       [701, 708, 713, ..., 690, 688, 692],
       [703, 711, 716, ..., 693, 690, 695],
       ..., 
       [695, 702, 707, ..., 686, 683, 687],
       [691, 698, 703, ..., 682, 679, 683],
       [692, 699, 705, ..., 682, 680, 684]], dtype=uint16)

In [10]: 

For now, just use one of the other TiffStack implementations.

forevertheuni commented 9 years ago

16bits.

Oh!! cool easy change in the code to for those things :) :+1: x 1e06 for the quick help!!

forevertheuni commented 9 years ago

In [3]: pims.TiffStack.name Out[3]: 'TiffStack_libtiff'

tacaswell commented 9 years ago

I wonder what we are doing wrong internally as libtiff by it s self is getting you the right data..

On Tue, Mar 10, 2015, 14:59 forevertheuni notifications@github.com wrote:

In [3]: pims.TiffStack.name Out[3]: 'TiffStack_libtiff'

— Reply to this email directly or view it on GitHub https://github.com/soft-matter/pims/issues/141#issuecomment-78123305.

caspervdw commented 9 years ago

Possibly it is the byteswap in pims tiffstack.py line 222. After inspecting the source of Tiff.read_image it appears that ReadEncodedStrip underlies this function. According to https://bitmiracle.github.io/libtiff.net/html/2ee23e7c-3bdf-3dcf-c22e-909bf9a5cd01.htm this does the byteswapping for you, probably it is swapped one time to much right now.

I cant test today, maybe you can remove byteswap in line 222 and check?

tacaswell commented 9 years ago

@forevertheuni This should be fixed now. If you are willing can you checkout the master version and make sure that this has fixed the issue for you?