Colour metadata from PFF

[wmoore]

At least some formats store colours for channels, either user-assigned or based on acquisition.

Several users have requested that we read this data and use it to set initial rendering settings on import.

E.g. From Martin's e-mail:
One constant issue is still assignment of the colours to the channels. Using the colours assigne by the user at acquisition is NOT OPTIONAL, using the 'natural colours' creates constant problems for the following reasons:

• whenever two channels have the same detection range (with different excitation), the channels are shown with the same colour on the screen and hence indistinguishable
• whenever a detection range is in the far-red or infrared range, the channel is not shown at all (consequent, but pointless)

and Forum
​https://www.openmicroscopy.org.uk/community/viewtopic.php?f=4&t=538&p=1757&sid=5c00043d8961c3c59fe9a319058cbf13#p1757

Waiting on reply to forum above regarding format.
I'll look at where this info is stored in lif files and other confocal formats.

[wmoore]

From Martin's e-mail:
One constant issue is still assignment of the colours to the channels. Using the colours assigne by the user at acquisition is NOT OPTIONAL, using the 'natural colours' creates constant problems for the following reasons:

• whenever two channels have the same detection range (with different excitation), the channels are shown with the same colour on the screen and hence indistinguishable
• whenever a detection range is in the far-red or infrared range, the channel is not shown at all (consequent, but pointless)

[wmoore]

For lif and lei files, the colors we want appear to be under

<Image>
 <ImageDescription>
  <Channels>
   <ChannelDescription LUTName="Blue">
   <ChannelDescription LUTName="Green">
   <ChannelDescription LUTName="Gray">
   <ChannelDescription LUTName="Red">
   <ChannelDescription LUTName="Magenta">

with the number of ChannelDescription elements matching the number of active channels in the correct order. The only colors I have seen so far are the ones above (checked lifs from Martin, Chris, Fabrice, leis from Joel, Martin)

[wmoore]

For LSM files, I can see these values in the Bio-Formats original metadata:
(channels appear red, blue, green)

Recording/Tracks/Track 1/Data Channels/Data Channel 1/ - Color	255
Recording/Tracks/Track 1/Data Channels/Data Channel 2/ - Color	16711680
Recording/Tracks/Track 1/Data Channels/Data Channel 3/ - Color	65280

[wmoore]

In Leica-liff/fabrice/Rosier.lif[Series005] there is a block (below) for each channel. Each block has the same list of colours for detector (I guess strictly we should take the 'active' channel colour from each).

<Data><Image><Attachment><HardwareSetting><LDM_Block_Sequential>
<LDM_Block_Sequential_List>
 <ATLConfocalSettingDefinition>
  <DetectorList>
    <Detector Channel="1" IsActive="1" Gain="1068.64652475776" Offset="-68.54" Type="PMT 1" OffsetShow="-69" GainShow="1069" ActiveShow="Active" Band="(406nm - 479nm)" LutName="Blue" />
    <Detector Channel="2" IsActive="0" Gain="994.277866788739" Offset="-2.84666666666666" Type="PMT 2" OffsetShow="-3" GainShow="994" ActiveShow="Inactive" Band="(511nm - 564nm)" LutName="Green" />
    <Detector Channel="3" IsActive="0" Gain="901.40764476997" Offset="-13.1266666666667" Type="PMT 3" OffsetShow="-13" GainShow="901" ActiveShow="Inactive" Band="(616nm - 669nm)" LutName="Red" />
    <Detector Channel="4" IsActive="0" Gain="773.422598611429" Offset="-2.34" Type="PMT 4" OffsetShow="-2" GainShow="773" ActiveShow="Inactive" Band="(721nm - 774nm)" LutName="Magenta" />
    <Detector Channel="100" IsActive="0" Gain="414.396887159533" Offset="0" Type="Transmission" OffsetShow="0" GainShow="414" ActiveShow="Inactive" Band="" LutName="Gray" />
  </DetectorList>

[wmoore]

Pushing to future - Not time for 4.3.
Melissa - this is probably a story with multiple parts, but I'm guessing the next step is to read some color info and store this in the 'color' attribute of each channel

<xsd:attribute name="Color" use="optional" type="xsd:int" default="-2147483648">
A color used render this channel - encoded as RGBA
The default value "-2147483648" is #FFFFFFFF so solid white (it is a signed 32 bit value)

Does this make sense?

[mlinkert]

Replying to wmoore:

Pushing to future - Not time for 4.3.
Melissa - this is probably a story with multiple parts, but I'm guessing the next step is to read some color info and store this in the 'color' attribute of each channel

<xsd:attribute name="Color" use="optional" type="xsd:int" default="-2147483648">
A color used render this channel - encoded as RGBA
The default value "-2147483648" is #FFFFFFFF so solid white (it is a signed 32 bit value)

Does this make sense?

Makes sense. We already do this for one format (MIAS), so it should not be so difficult to do it for other formats as well.

[wmoore]

Also need to review the color selection based on wavelength:

E.g. lei/joel/sequental scan 2/

• Currently cut-off red->green is 560.
• We have two channels with emission filters: 553-618 and 665-800
• We pick wavelength as cut-in + 15 (ignore emission).
• Both these channels are therefore colored Red.

Although the above example could be fixed by adjusting the "+15" increment to cut-in or by moving the green->red boundary, this could easily "break" another format / example.

Color selection algorithm could be improved to order channels by wavelength - Preferentially color Blue -> Green -> Red, instead of color 2 channels same color.

[wmoore]

2 more useful examples of multiple channels getting same color. Both these have 3 red channels!

from_skyking/leica-lif/sefan/

• 3D_Prionium_thick_stack.lif
• exp02.lif

[mlinkert]

One more example of color metadata being lost is in data/imaris/james/. The channels should be:

  Channel 1 (far red) = 100% blue
  Channel 2 (red) = 100% red
  Channel 3 (green) = 100% green
  Channel 4 (DAPI) = white

[jburel]

Moved from sprint 2011-12-13 (4)

[Melissa Linkert <melissa@…>]

(In [bbe6af25b8f297f944f1bcc3ef7c7fc3417f9c90/bioformats.git]) Populate Channel.Color for Leica LEI files

See #3651

[mlinkert]

The Channel.Color attribute is now populated for Leica LIF, Leica LEI, Zeiss LSM, and Imaris HDF files. I've filed a new ticket (#7709) based on comment #7 that covers re-evaluating the strategy for assigning colors to channels within OMERO, so closing this ticket.

[Melissa Linkert <melissa@…>]

(In [bbe6af25b8f297f944f1bcc3ef7c7fc3417f9c90/bioformats.git]) Populate Channel.Color for Leica LEI files

See #3651

[wmoore]

It seems like bio-formats is using a different notation for colours than OMERO.
Bio-formats is using ARGB and OMERO uses RGBA!

E.g. fabrice/Rosier.liff Fluo exo/Image007
Expected colours (from PFF viewer) are:

• Blue
• Green
• White
• Red
• Purple

Bio-formats reads:

<Channel Color="255" ExcitationWavelength="405" ID="Channel:0:0" Name="Leica/DAPI" PinholeSize="67.9634142508981" SamplesPerPixel="1">
<Channel Color="65280" ExcitationWavelength="488" ID="Channel:0:1" Name="Leica/FITC" PinholeSize="67.9634142508981" SamplesPerPixel="1">
<Channel Color="16777215" ID="Channel:0:2" Name="" PinholeSize="67.9634142508981" SamplesPerPixel="1">
<Channel Color="16711680" ExcitationWavelength="561" ID="Channel:0:3" Name="Leica/TRITC" PinholeSize="67.9634142508981" SamplesPerPixel="1">
<Channel Color="16711935" ExcitationWavelength="633" ID="Channel:0:4" Name="Leica/Cy5" PinholeSize="67.9634142508981" SamplesPerPixel="1">

But this ends up in OMERO DB as

  id  | pixels_index | alpha | red | green | blue 
------+--------------+-------+-----+-------+------
 1451 |            0 |   255 |   0 |     0 |    0    (black)
 1452 |            1 |   255 |   0 |     0 |  255    (blue)
 1453 |            2 |   255 | 255 |   255 |  255    (white)
 1454 |            3 |   255 |   0 |   255 |    0    (green)
 1455 |            4 |   255 |   0 |   255 |    0    (green)

Andrew sent me a useful conversion sheet which shows the problem:

Old-RGBA	Hex-Old-RGBA    New-ARGB		
0	        00000000	0		
255	        000000FF	255		
65280	        0000FF00	65280		
65535	        0000FFFF	65535		    Blue
16711680	00FF0000	16711680		
16711935	00FF00FF	16711935		Green
16776960	00FFFF00	16776960		
16777215	00FFFFFF	16777215		
2147483646	7FFFFFFE	2147483646		
2147483647	7FFFFFFF	2147483647		
2147483648	80000000	-2147483648		
2147483649	80000001	-2147483647		
2147483650	80000002	-2147483646		
2164260862	80FFFFFE	-2130706434		
2164260863	80FFFFFF	-2130706433		
2164260864	81000000	-2130706432		
2164260865	81000001	-2130706431		
2181038079	81FFFFFF	-2113929217		
4278190080	FF000000	-16777216		
4278190335	FF0000FF	-16776961		Red
4278255360	FF00FF00	-16711936		
4278255615	FF00FFFF	-16711681		
4294901760	FFFF0000	-65536		
4294902015	FFFF00FF	-65281		
4294967040	FFFFFF00	-256		
4294967294	FFFFFFFE	-2		
4294967295	FFFFFFFF	-1

[mlinkert]

Thanks Will - should be sorted with this commit:

​https://github.com/melissalinkert/bioformats/commit/87340b56f83721cc174a4b9bed5389f615a67b47

(on my 'sprint7-bug-fixes' branch)

[wmoore]

PFF colours working!

[wmoore]

Working now! ​http://trac.openmicroscopy.org.uk/ome/attachment/ticket/3651/Screen%20shot%202012-01-25%20at%2017.10.37.png
Also working for LSM.
Closing...

[cxallan]

Melissa / Will: Regarding 87340b56f83721cc174a4b9bed5389f615a67b47 on your sprint7-bug-fixes branch that translation is really something that our metadata store implementation should be doing (and is in fact doing for other colours). Bio-Formats should be spitting out schema valid encoded colours.

[mlinkert]

Chris: is it worth then doing something like adding a 'Color' class to ome.xml.model.primitives and then changing the signature of setChannelColor(...) to setChannelColor(Color, int, int)? That way the readers could do something like this:

Color foo = new Color(red, green, blue);
store.setChannelColor(foo, 0, 0);

...and the conversion into an appropriately packed int happens internally.

[cxallan]

That's a great idea actually. Readers should not really be expected to have to deal with that kind of crap across the board and having it in ome.xml.model.primitives lets us export the same logic everywhere so it's kind of a win-win. We might have to get Andrew, adding him to the CC line, to adjust the schema a little bit to ensure XsdFu is picking things up that code generating that way but that should be easy enough.