dxchange icon indicating copy to clipboard operation
dxchange copied to clipboard

uint32 save_tiff_stack

Open ravescovi opened this issue 8 years ago • 5 comments

Hey,

I am trying to use save_tiff_stack into a dtype='uint32' and the saved tiff's are corrupted (it is trying to save 64bit of information). When i do a cast im = im.astype('uint8') or ('uint16') it works great.

ravescovi avatar May 25 '16 19:05 ravescovi

May I ask why do you need 64-bit information ? are these float-64? Our raw data are 16 bit at most so there is no more 'information' storing it in a 64-bit. Also what are you going to use as a viewer for this images?

decarlof avatar May 25 '16 20:05 decarlof

I am using dxchange to save tiff_stacks that i acquire from neurotomodata. Some of this datasets com as uint32 and when i try to save then it generates 64bit corrupted images. So, the answer is i do not want to use or save 64 bit but this is what's happening. The datasets with 8 and 16bits are doing ok.

So far the solution was to do a cast to 16bit before i run save_tiff_stack and use the flag dtype='uint32' to save the data.

ravescovi avatar May 25 '16 21:05 ravescovi

Ah I see, it look like a bug, I will look into it.

decarlof avatar May 25 '16 21:05 decarlof

can you share the exact call to the tiff_stacks writer? If you do not specify the type the original is used.

def as_dtype(arr, dtype):
    if not arr.dtype == dtype:
        arr = np.array(arr, dtype=dtype)
    return arr

decarlof avatar May 25 '16 21:05 decarlof

I just checked, and saving a random numpy array with dxchange.write_tiff_stack(..., dtype='uint32') seems to work on my machine.

@ravescovi Is this still a bug? Maybe a newer version of tifffile fixed the problem upstream...

dmpelt avatar Jan 13 '17 20:01 dmpelt