Fix channel as second dim problem

[acorbat]

Following on Issue #44, I believe that the problem is that the hacky way of guessing whether Channels is the second dimension or not is summing over all the bytes of every channel, instead of looking only for the maximum. BytesInc is already accumulating the Bytes of each channel, and we should only compare the maximum with the one from the channels.

I do not have lots of images to test if this modification breaks the behaviour with other images, but it does fix the problem with my images.

[AlanWu886]

Hi @acorbat,

Thanks for fix!
I feel your fix definitely make way more sense than mine posted in issue #44.

Do you think would it be more precise to do this?

                 if 3 in dims_dict.keys() and len(dims) > 2:
                    channels = item.findall("./Data/Image/ImageDescription/"
                                            "Channels/ChannelDescription")

                    channel_bytes_inc_list = [int(c.attrib["BytesInc"]) for c in channels]
                    channel_max = max(channel_bytes_inc_list)
                    max_index = channel_bytes_inc_list.index(channel_max)
                    channel_max += int(dims_dict[1]*dims_dict[2] * int(channels[max_index].attrib["Resolution"]) / 8)
                    
                    bytes_inc_channel = channel_max
                    cytes_inc_z = int(dims[2].attrib["BytesInc"])

                    channel_as_second_dim = bytes_inc_channel > cytes_inc_z

                else:
                    channel_as_second_dim = False

As you say the BytesInc is accumulating, but the number does not include the byte increase of that channel itself.
Thus, I feel it would be more precise to also include the byte increase of the channel with max byte increase by:
channel_max += int(dims_dict[1]*dims_dict[2] * int(channels[max_index].attrib["Resolution"]) / 8)

Please let me not your thoughts!

Sincerely yours,
Alan

[acorbat]

Hi,

I'm wondering about the right way... I don't have an image to test this right now. I am wondering if cytes_inc_z is also the first byte. Can these be the same in any case? Are they the same when channel is NOT the second dimension? I'm sorry I can't check this right now.

On the other hand, I was wondering if you can get the step size in bytes from channel_bytes_inc_list[0] or channel_bytes_inc_list[1] as the first element might be the step size as well and you already have it.

Best,
Agustin

[AlanWu886]

Hi Agustin,

Sorry for the late response. Just want to share my thoughts regarding the this issue.

Hi,

I'm wondering about the right way... I don't have an image to test this right now. I am wondering if cytes_inc_z is also the first byte. Can these be the same in any case? Are they the same when channel is NOT the second dimension? I'm sorry I can't check this right now.

I am not quite sure what you mean here, but I really would like to learn about this more from you if possible.
In my humble opinion, I feel the author is trying to figure out what is the image stack like from code:

    def get_frame(self, z=0, t=0, c=0, m=0):
        """
        Gets the specified frame (z, t, c, m) from image.

        Args:
            z (int): z position
            t (int): time point
            c (int): channel
            m (int): mosaic image

        Returns:
            Pillow Image object
        """
        if self.display_dims != (1, 2):
            raise ValueError("Atypical imaging experiment, please use "
                             "get_plane() instead of get_frame()")

        t = int(t)
        c = int(c)
        z = int(z)
        m = int(m)
        if z >= self.nz:
            raise ValueError("Requested Z frame doesn't exist.")
        elif t >= self.nt:
            raise ValueError("Requested T frame doesn't exist.")
        elif c >= self.channels:
            raise ValueError("Requested channel doesn't exist.")
        elif m >= self.n_mosaic:
            raise ValueError("Requested mosaic image doesn't exist.")

        total_items = self.channels * self.nz * self.nt * self.n_mosaic

        t_offset = self.channels * self.nz
        t_requested = t_offset * t

        # Hack-y fix for channel as the second dim
        if self.channel_as_second_dim:
            z_requested = z
            c_offset = self.nz
            c_requested = c * c_offset
        else:
            z_offset = self.channels
            z_requested = z_offset * z
            c_requested = c

        m_offset = self.channels * self.nz * self.nt
        m_requested = m_offset * m

        item_requested = t_requested + z_requested + c_requested + m_requested
        if item_requested > total_items:
            raise ValueError("The requested item is after the end of the image")

        return self._get_item(item_requested)

Not quite sure where the evidence comes from, but It seems he is confident the stack order is either "CZTM" or "ZCTM" with t_offset = self.channels * self.nz and m_offset = self.channels * self.nz * self.nt (while "offset" here probably means the "jump of frames" in the stack), suggesting T is the third dimension and M is the last one.

On the other hand, I was wondering if you can get the step size in bytes from channel_bytes_inc_list[0] or channel_bytes_inc_list[1] as the first element might be the step size as well and you already have it.

I totally agree with your approach on this with the premise that all the channels have the same byte jump with the same size and byte depth.
Sadly, I am not an expert on microscope so I choose to be defensive here by picking the maximum then adding the byte jump of the channel with the maximum.

Best,
Alan

[acorbat]

Hi Alan,

Regarding channel order, I understood the same thing you did. Apparently Leica used either "MTCZYX" or "MTZCYX" as dimension order (going from slowest to fastest dimension). Previously I run into this problem that C and Z dimensions were swapped so I could not read them correctly. I am not sure if dimension order is inside the metadata, but the "hack-y" solution was to look for the start byte position in the metadata and find which one is highest, we can see whether C or Z is the second dimension.

For the last point, I agree with you that the safe choice is to calculate the Byte step as you suggest. I was proposing a lazy way as it should always be the same size.

Cheers,
Agus

[acorbat]

Hi Alan,

was this PR ok? Should we revisit it?

Cheers,
Agus

[AlanWu886]

Hi Agus,

It looks perfect to me! I think we just need to wait for Nick to grant the request now!

Thanks!
Alan

[keithchev]

@acorbat thanks for working on this! I wanted to let you know that Nick has recently transferred ownership of this repo to Arcadia Science, since we have the bandwidth to maintain this package. We're working on going through the open PRs and issues and hope to get this PR reviewed and merged in the next week or so! Thanks again, and let me know if you have any questions.

[imagejan]

Hi @keithchev, any news on this pull request?

We're currently opening lif files using bioio with bioio-bioformats, but would like to avoid the overhead of starting Java via scyjava and jgo when we can use bioio-lif with readlif directly. But the issue with interleaved channels and slices is keeping us away from that simpler option.

[keithchev]

@imagejan so sorry for the late reply! Would you be willing to share an example of a LIF file that cannot be read with readlif without the change made in this PR? This would help us to write tests to cover this issue and potentially develop a more robust solution in the future. Thanks so much!

In the meantime, we'll get this PR reviewed and merged asap. (It's passing the existing tests, but I'd like to try to understand the change made here myself before merging it.)

[acorbat]

Hi @keithchev !

Thank you for pushing this forward. The images I was working with were not mine. I can privately share one of them with you. I'm getting in touch with the person who acquired the images to see if there is one that can be publicly shared.

[imagejan]

I'll try to get a sharable minimum sample file acquired and will follow up here.

Edit:
Here's an example file: 20250130_4Channels_5planes.zip (feel free to add the .lif file contained in this zip to your tests if its helpful)

(Thanks to @Lplantard for acquiring the file!)

Try the following:

from pathlib import Path
from readlif.reader import LifFile

path = Path("20250130_4Channels_5planes.lif")
img = LifFile(path)
image = img.get_image()

# Should be set to False, but currently opens as True
assert not image.channel_as_second_dim

I can confirm that the current PR loads the image with channel_as_second_dim set to True, and in consequence, channels and slices are not mixed up.

[keithchev]

@imagejan thanks for sharing that file! This is super helpful. I think I understand this PR now. For the sake of expediency, let's merge this as-is now, and add tests in a later PR.

Thanks so much for your patience!