search

BodenmillerGroup / steinbock

A toolkit for processing multiplexed tissue images
https://bodenmillergroup.github.io/steinbock
MIT License
49 stars 14 forks source link

automatically detect uint type in io.py #131

Closed jinyancool closed 2 years ago

jinyancool commented 2 years ago

Hello, In the io.py, I saw follow code: mask_dtype = np.dtype(os.environ.get("STEINBOCK_MASK_DTYPE", "uint16"))

This let me cannot process uint32 images. When I change the code to uint32, it works. mask_dtype = np.dtype(os.environ.get("STEINBOCK_MASK_DTYPE", "uint32"))

Is it possible automatically detect uint type in io.py? No need to do it manually.

mjseignon commented 2 years ago

I am also running 32-bit tiffs and was getting truncated masks and did not realize that it was because of the 16-bit dtype requirement. Is it possible to get 32-bit masks as an automatic output?

jwindhager commented 2 years ago

Currently traveling, will reply early next week

jwindhager commented 2 years ago

Hi @jinyancool and @mjseignon, thanks for reaching out!

Indeed, per the specification, only 16-bit masks are supported at this moment. As you correctly point out, @mjseignon, this may be problematic for large masks containing more than 2^16 - 1 = 65535 cells. In such situations, you can run the steinbock Docker container with -e STEINBOCK_MASK_DTYPE=uint32, for example as shown in https://github.com/BodenmillerGroup/steinbock/issues/132. However, please note that this is considered a "hack" and not sufficiently tested at this point (although I do not expect major problems with this).

Hope this helps, please do not hesitate to reopen the issue if anything is unclear!

mjseignon commented 2 years ago

Hi @jwindhager, thank you for the suggestion, I'm assuming calling this flag with uint32 is the same as the the np.float32 added in the latest commits,imagej=mask.dtype in (np.uint8, np.uint16, np.float32) .

jwindhager commented 2 years ago

Hi @mjseignon

I'm assuming calling this flag with uint32 is the same as the the np.float32 added in the latest commits,imagej=mask.dtype in (np.uint8, np.uint16, np.float32)

No. Specifying -e STEINBOCK_MASK_DTYPE=uint32 instructs steinbock to always read/write masks as 32 bit unsigned integer (uint32) images (the documented & tested default is uint16). This is not directly related to the latest commits.

What you are referring to is a bugfix to avoid saving images in ImageJ TIFF format when the data type is not supported (the ImageJ TIFF format only supports uint8, uint16 and float32, see here). For example, masks that are written as uint32 (e.g., when specifying -e STEINBOCK_MASK_DTYPE=uint32) won't be written in ImageJ TIFF format.