InCellReader - XY position extraction

[dsudar]

Hi BF team,

With the new SPW spatial viewing in 5.3.x I noticed that there's a bug in the extraction of the XY locations in the InCellReader. I've uploaded 2 .xdce files that demonstrate the issue. There are 2 issues at play:
1) the index skips the first <offset_point> line so XY locations are only assigned to n-1 of the total number of locations/fields (easiest seen using my SMMART_Test_Plate_Template_SM3001_1_1.xdce file)
2) the extracted index is not correctly assigned to the appropriate field when the indexes are not in sequential order (see my LI9V01612_96ECM_1.xdce file). Instead it assumes sequential order after skipping the first <offset_point> entry.

I think the issue is with the chunk of code at line 1062 of InCellReader.java:

Code: Select all

      else if (qName.equals("offset_point")) {
        String x = attributes.getValue("x");
        String y = attributes.getValue("y");
        Integer index = DataTools.parseInteger(attributes.getValue("index"));
        if (null == index) {
          index = offsetPointCounter++;
        }

        posX.put(index, new Length(Double.valueOf(x), UNITS.REFERENCEFRAME));
        posY.put(index, new Length(Double.valueOf(y), UNITS.REFERENCEFRAME));

        addGlobalMetaList("X position for position", x);
        addGlobalMetaList("Y position for position", y);
      }


but I don't understand the code well enough to be able to provide a fix and PR.

Cheers,
- Damir

[rleigh]

Dear Damir,

Would it be possible to describe exactly what you are seeing and what you expected for the XY locations? A screenshot would help if you have one. I'm also not sure exactly what you're referring to by "appropriate field"; a pointer would be much appreciated.

I've looked at the XML content of SMMART_Test_Plate_Template_SM3001_1_1.xdce and it appears to match the OME-XML metadata for the most part. The border wells are unused, starting at B2 and ending at O23. There are four fields in each well, and these are using offsets from the well centre of (±832.8,±832.8) (all 4 combinations). This matches the OffsetFromWellCenter values (though it has lost the unit).

We do seem to ignore the PlatePosition_um value for the plate-relative position and reuse the well offsets instead. This could likely be set on Plane as we do for FocusPosition. I'm not sure if this is related to your problem though.

This is looking at the OME-XML metadata from "showinf -nopix -omexml". It's possible that OMERO is doing something in addition.


Kind regards,
Roger

[dsudar]

Hi Roger,

Thanks. The issue I'm seeing is with the locations of the 4 samples in the well as interpreted by OMERO so indeed the issue may be downstream from the Reader itself. For the plate with the .xdce file you were looking at, the well locations show up as in the enclosed picture.

As you can see in the overview graphic it is missing one of the locations within the well AND the first image in the sequence (the one I've selected) is the lower right point in the well while in the .xdce file (and indeed in the output from showinf as you pointed out), this should be the point with coordinates (-832.8, 832.8) i.e the lower left point.

This same issue also happens with the other .xdce file I uploaded. However, in that file (as it comes out of the INCell 6000 HCS system) the well locations are not in acquisition order (which was typewriter style) but in some kind of random order and the the Reader (or downstream code) doesn't appear to honor the index order when displaying in the well overview graphic. Indeed, showinf DOES show the sample locations in the correct order so your thought about the issue being downstream somewhere in OMERO does seem to be on point.

Thanks,
- Damir

[dsudar]

Hi Roger,

Hold everything ..... I just figured out that the issue was already fixed in one of the BF updates between 5.1.10 and 5.5.3. I had uploaded all those image sets before using OMERO 5.2.8 and was (silly me) just expecting miracles. I just re-imported a few of those same InCell plates and all is fine with them now. Apologies for the false alarm.

Thanks for putting me on the right path.
Cheers,
- Damir

[mtbc]

Dear Damir,

Thank you for letting us know. At least we now see what was going on!

Cheers,
Mark