Channel names not updated

[dominikl]

When trying to set the rendering settings for idr0136 via yml file I noticed that the channel names don't get updated.
Looking at the code, the update method gets called with a name dictionary which is initialized with the current channel names but I can't see anywhere where it would be modified with the names in the rendering settings yml file (https://github.com/ome/omero-cli-render/blob/master/src/omero_cli_render.py#L758 )

[dominikl]

It seems to work for images and only fails for plates, resp. images part of plates. And I think the cause might be rather in omero-py than the render plugin.

[will-moore]

The other types (Screen, Plate, Project, Dataset etc) should be handled by

omero-cli-render/src/omero_cli_render.py

Line 691 in 2acb825

for img in self.render_images(self.gateway, args.object, batch=1):

which should return a series of Images, so that iids gets populated with all the Image IDs and the name change is applied to all.

But I don't know if this is broken or not?

[dominikl]

I'm pretty sure now the problem is somewhere in https://github.com/ome/omero-py/blob/75cb5f31b01dc7bc93fb4b21688e9c8b225693cd/src/omero/gateway/__init__.py#L3948 . But just can't get my environment setup to be able to debug into that.

Run a simple script

import omero.gateway

conn = omero.gateway.BlitzGateway(...)
conn.connect()

namedict = {1: "one", 2: "two", 3: "three"}
iids = [261965]  #  260968
updated = conn.setChannelNames("Image", iids, namedict)
print(updated)

conn.close()

With an "normal" image it works fine:

With an image from a plate it does something weird:

[dominikl]

I've added some more output for debugging. So the difference is, for a normal image there are three channels and three logical channels, but for some reason for the plate image there are only two logical channels with one being listed twice:

Set channel 0 (id=398021) one to one
Set channel 1 (id=398022) three to two
Set channel 2 (id=398022) two to three

[jburel]

is it the case for all images in a plate or only a specific plate? Sharing logical channels is allowed by the model

[dominikl]

Ok, then we have huge problem with idr0136. Because all images of each plate(!) only have one and the same logical channel. So all channels of all images of each plate will have the same channel name. @francesw

How can it ever make sense to share a logical channel?

And why didn't we have this problem before? @sbesson
Note: The plates are companion + tif.

The ids of the four (logical) channels of a plate 1 image: [17587953, 17587953, 17587953, 17587953]
Other image same well: [17587953, 17587953, 17587953, 17587953]
Other well: [17587953, 17587953, 17587953, 17587953]
Other plate: [17587987, 17587987, 17587987, 17587987]

[sbesson]

I have a suspicion of how this could happen. To be sure, could you paste a full example of an <Image> element (i.e. the metadata for a single well sample) from one of the companion files?

[dominikl]

  <Image ID="Image:1258" Name="11|20|26">
    <Pixels ID="Pixels:1258:1258" DimensionOrder="XYCZT" Type="uint16" SizeX="1080" SizeY="1080" SizeZ="1" SizeT="1" SizeC="4">
      <Channel ID="Channel:5032" SamplesPerPixel="1"/>
      <Channel ID="Channel:5033" SamplesPerPixel="1"/>
      <Channel ID="Channel:5034" SamplesPerPixel="1"/>
      <Channel ID="Channel:5035" SamplesPerPixel="1"/>
      <TiffData FirstC="0" FirstT="0" FirstZ="0" PlaneCount="1">
        <UUID FileName="Plate2-20190325/r11c20f26p01-ch1sk1fk1fl1.tiff">urn:uuid:fa308f4a-0796-4262-91c9-ddb4e39fe9a6</UUID>
      </TiffData>
      <TiffData FirstC="1" FirstT="0" FirstZ="0" PlaneCount="1">
        <UUID FileName="Plate2-20190325/r11c20f26p01-ch2sk1fk1fl1.tiff">urn:uuid:f18084e1-8312-41f4-89e6-f8ac3a108670</UUID>
      </TiffData>
      <TiffData FirstC="3" FirstT="0" FirstZ="0" PlaneCount="1">
        <UUID FileName="Plate2-20190325/r11c20f26p01-ch4sk1fk1fl1.tiff">urn:uuid:e40b7dd9-cb1f-43a9-81fb-f4f614c4cab4</UUID>
      </TiffData>
      <TiffData FirstC="2" FirstT="0" FirstZ="0" PlaneCount="1">
        <UUID FileName="Plate2-20190325/r11c20f26p01-ch3sk1fk1fl1.tiff">urn:uuid:e4455ade-f05d-4d4c-96d6-32442beee2c6</UUID>
      </TiffData>
      <Plane TheC="0" TheZ="0" TheT="0"/>
      <Plane TheC="1" TheZ="0" TheT="0"/>
      <Plane TheC="3" TheZ="0" TheT="0"/>
      <Plane TheC="2" TheZ="0" TheT="0"/>
    </Pixels>
  </Image>

I assume I'd have to give the channel a name in the companion.xml to force the creation of a logical channel per channel, right?

The images are created like that:

    for file in files:
        m = pat.match(file).groupdict()
        key = f"{m['wellrow']}|{m['wellcol']}|{m['field']}"
        if not key in images:
            images[key] = Image(key, img_x, img_y, size_z, size_c, size_t, order=order, type=pix_type)
            images[key].add_channel(samplesPerPixel=1)
            images[key].add_channel(samplesPerPixel=1)
            images[key].add_channel(samplesPerPixel=1)
            images[key].add_channel(samplesPerPixel=1)
        images[key].add_plane(c=int(m['channel'])-1, z=0)
        images[key].add_tiff(file, c=int(m['channel'])-1, z=0, t=0, planeCount=1)

[sbesson]

I assume I'd have to give the channel a name in the companion.xml to force the creation of a logical channel per channel, right?

That's correct. The sample above is absolutely valid from the perspective of the OME-TIFF specification. When importing HCS data, the OMERO importer logic tries to collapse a certain number of objects (light paths, channels) to avoid the explosion of DB entries. For channels, the server-side logic is in https://github.com/ome/omero-server/blob/763a2921b5bef201bc6c4cdd0cfe25f46b96074c/src/main/java/ome/formats/OMEROMetadataStore.java#L2192-L2233 and tries to identify logical channels with equivalent properties.

Adding a discriminant property for the channels e.g. a name should suffice to fix the issue.

[dominikl]

I wonder in how many submissions we have this problem now... probably all submissions for which I created the companion files :-(