I have problems loading a 4 channel image

[RosalioReyes]

Hello. I'm using readlif, and it looks like a wonderful library. However since I started uploading 4 channel images I have had problems. The problem is that when I do the maximum projection, the image does not match the one obtained by ImageJ. I am using the library as follows:

img_0 = new.get_image(0) z_list = np.array([np.array(i) for i in img_0.get_iter_z(t=0, c=0)])

Notice that I am converting the output to a Numpy array. The maximum projection is done as follows:

max_projection = z_list.max(axis = 0)

It does not matter which channel I select (0,1,2,3), when I do the maximum projection, it does not correspond to the one thrown by ImageJ. I clarify that this does not happen if the image has less than 4 channels.

I would greatly appreciate a suggestion.

Best regards, Rosalio.

[DirkRemmers]

Hey @RosalioReyes,

It seems like this might be related to issue #19, where if you use a 4 channel image, it will confuse the z-stacks and the channels while reading in the pictures. Could you take a look and see if that is the case? There is an example in #19.

[RosalioReyes]

Hi @DirkRemmers,

Thank you very much for your prompt response. Indeed, the problem is in the way the libary read the stacks. I really like readlif. For now the quick solution I gave to the problem was to gather all the channels in an array, and then separate "the true channels". I did the following:

file = LifFile(r"path \ image.lif")

img0 = file.get_image(0)

c1 = np.array( [ np.array(i) for i in img0.get_iter_z(t = 0, c = 0) ] ) c2 = np.array( [ np.array(i) for i in img0.get_iter_z(t = 0, c = 1) ] ) c3 = np.array( [ np.array(i) for i in img0.get_iter_z(t = 0, c = 2) ] ) c4 = np.array( [ np.array(i) for i in img0.get_iter_z(t = 0, c = 3) ] )

all_channels = np.vstack( (c1,c2,c3,c4) )

realChannel_1 = [] for i in range(0, len(all_channels), 4 ): realChannel_1.append(all_channels[i])

realChannel_2 = [] for i in range(1, len(all_channels), 4 ): realChannel_2.append(all_channels[i])

realChannel_3 = [] for i in range(2, len(all_channels), 4 ): realChannel_2.append(all_channels[i])

realChannel_4 = [] for i in range(3, len(all_channels), 4 ): realChannel_4.append(all_channels[i])

But I continue with doubts about why the error only appears when the image has 4 channels, and not when it has 3. That is, when the image has 3 channels, the library detects very well the stacks corresponding to each channel.

I think my solution is not pretty, but it is solving things for the moment.

Best, Rosalío.

[phigjm]

Had the same issue.

My solution was:

def get_frame(imgContainer, z,c):
    i= imgContainer.channels*z+c
    z = i%imgContainer.nz
    c = i//imgContainer.nz
    return imgContainer.get_frame(z=z,t=0, c=c)

get_frame(im0,2,0)

good to know that this is only a 4 Chanel problem.

[phigjm]

I just checked: and I have the same issue with 8 channel recordings. But my code suggestion also works for 8 Channels. (in casme someone runs in the same Problems)

[RosalioReyes]

Dear @phigjm, I did not work in those time with images with more than 4 channels, but I supposed that the problems is general.

Thanks a lot by your suggestion.

[phigjm]

I now as well believe the problem is general. I tried out 3 -8 channels so far and always had the same issue. I am thinking about making a pull request with this solution build in. But I am not sure where the problem came from and if we are only a special case that can be detected via a tag or anything. I know ImageJ Handels the images correctly. Maybe we can ask Leica directly about that.

[AlanWu886]

Hi all,

Unfortunately, I have the same issue while trying to convert with 6 channels and multiple z planes. I tried to change channel_as_second_dim = bytes_inc_channel >cytes_inc_z in reader.py into channel_as_second_dim = bytes_inc_channel < cytes_inc_z to make it work with the right order...

It seems the author wanted to tell whether channel is the second dimension by compare the "byte jump" ("BytesInc" attribute of channels) to the "BytesInc" of z dimension. In my humble opinion, I feel it is more reasonable to tell by checking the value of "BytesInc" of z dimension. In my case, both the x and y axis size are 1024 pixels with 16 bits depth. With "BytesInc" of z dimension being 12582912 (1024 1024 2 * 6) I feel channel should not be the second dimension...

         <dimensions>
          <dimensiondescription bitinc="0" bytesinc="2" dimid="1" length="9.226190e-05" numberofelements="1024" 
              origin="1.376765e-20" unit="m">
          </dimensiondescription>
          <dimensiondescription bitinc="0" bytesinc="2048" dimid="2" length="9.226190e-05" numberofelements="1024" 
              origin="1.376765e-20" unit="m">
          </dimensiondescription>
          <dimensiondescription bitinc="0" bytesinc="12582912" dimid="3" length="1.799585e-06" numberofelements="7" 
              origin="-6.220585e-06" unit="m">
          </dimensiondescription>
         </dimensions>

Does anyone know to get to the Nick or other contributors? I really want to know if my thinking is right...

Thanks a lot! Alan

[RosalioReyes]

Hi @AlanWu886 @DirkRemmers can read you from here.

Best, R.

[DirkRemmers]

Hey @RosalioReyes and @AlanWu886,

Thanks for all the work you have been doing! I fully agree that the proposed solution would be a good one to implement after extensive testing of course. Make sure to also test the more "simple" lif files with only 1 or 2 channels, and some without any z-stacks.

I also haven't heard anything from @nimne recently, so I think he might be very busy. Therefore I think the best way to tackle this is to make a working version yourself, followed by submitting a pull request.

Hopefully this way, Nick will have the time to accept the pull request without having to put in too much effort and time.

Thanks again for your great help!

Cheers, Dirk

[AlanWu886]

Hey @RosalioReyes and @AlanWu886,

Thanks for all the work you have been doing! I fully agree that the proposed solution would be a good one to implement after extensive testing of course. Make sure to also test the more "simple" lif files with only 1 or 2 channels, and some without any z-stacks.

I also haven't heard anything from @nimne recently, so I think he might be very busy. Therefore I think the best way to tackle this is to make a working version yourself, followed by submitting a pull request.

Hopefully this way, Nick will have the time to accept the pull request without having to put in too much effort and time.

Thanks again for your great help!

Cheers, Dirk

Sure, I will try to fix that and have a more extensive test before I make the pull request.

Alan