Bug: color encoding in OME-XML does not match client behavior

[mtbcarroll]

http://www.openmicroscopy.org/Schemas/Documentation/Generated/OME-2015-01/ROI_xsd.html#Shape_FillColor describes a ROI shape fill color integer as,

The color of the fill - encoded as RGBA
The value "-1" is #FFFFFFFF so solid white (it is a signed 32 bit value)

In fact, when viewed via Insight or Web, the color seems to be encoded as ARGB (if big-endian) where, as A ranges from 01 to FF, the fill gets increasingly opaque, except that A=00 is solid, not transparent.

The special behavior of 00 is strange and the byte order should be reviewed. Whichever needs fixing, the clients' behavior should match the schema documentation.

(The example value given is possibly the least helpful!)

[rkferguson]

@mtbcarroll - this also holds true when setting transparency through the UI.

[rleigh]

Another point to consider is that Alpha has no place in a channel colour. Why is it here? It's a rendering setting independent of colour; depending on the renderer it might also not be alpha, e.g. volume opacity constant, intensity accumulation constant. We might want to consider dropping it. We might also want to switch to a saner colour representation, such as #RRGGBB hex or three floats; the current representation is poor both in terms of its usability, and also in its complexity--it's been a repeated source of bugs due to it being constructed or interpreted incorrectly, this being the latest instance.

[jburel]

Problem also noticed by Chris, a possible option will be for 5.2.x to create a script so user can update ARGB-> RGBA to match schema
Moving to 5.2.3 for consideration

[mtbcarroll]

rleigh: I can imagine that transparency might be useful for a shape's fill color, but perhaps we oughtn't have a fill color at all or the client should just assume a certain middling opacity for fills.

[mtbcarroll]

Also note discussion on ​https://trello.com/c/BWXXsqqR/21-omero-db-representation-of-the-transforms - perhaps in the longer term Color should become an explicit OMERO object with named properties, typically nullable as a value for this A=00 case.

[mtbcarroll]

Fixing the special behavior of A=00 means that the overall fix is not injective. Given that fix and converting ARGB to the model-specified RGBA,

CREATE OR REPLACE FUNCTION fix_color(color INTEGER) RETURNS INTEGER AS $$

DECLARE
    least_3_bytes CONSTANT INTEGER := (1 << 24) - 1;
    least_1_byte CONSTANT INTEGER := (1 << 8) - 1;
    rgb INTEGER;
    alpha INTEGER;

BEGIN
    rgb := color & least_3_bytes;
    alpha := color >> 24 & least_1_byte;
    IF alpha = 0 THEN
        alpha := least_1_byte;
    END IF;
    RETURN rgb << 8 | alpha;

END;$$ LANGUAGE plpgsql;

An inverse can be calculated via,

CREATE OR REPLACE FUNCTION unfix_color(color INTEGER) RETURNS INTEGER AS $$

DECLARE
    least_3_bytes CONSTANT INTEGER := (1 << 24) - 1;
    least_1_byte CONSTANT INTEGER := (1 << 8) - 1;
    rgb INTEGER;
    alpha INTEGER;

BEGIN
    rgb := color >> 8 & least_3_bytes;
    alpha := color & least_1_byte;
    RETURN alpha << 24 | rgb;

END;$$ LANGUAGE plpgsql;

[mtbcarroll]

omero=# CREATE OR REPLACE FUNCTION fix_color(color INTEGER) RETURNS INTEGER AS $$
omero$# 
omero$# DECLARE
omero$#     least_3_bytes CONSTANT INTEGER := (1 << 24) - 1;
omero$#     least_1_byte CONSTANT INTEGER := (1 << 8) - 1;
omero$#     rgb INTEGER;
omero$#     alpha INTEGER;
omero$# 
omero$# BEGIN
omero$#     rgb := color & least_3_bytes;
omero$#     alpha := color >> 24 & least_1_byte;
omero$#     IF alpha = 0 THEN
omero$#         alpha := least_1_byte;
omero$#     END IF;
omero$#     RETURN rgb << 8 | alpha;
omero$# 
omero$# END;$$ LANGUAGE plpgsql;
CREATE FUNCTION
omero=# select to_hex(fix_color(x'00FF0000' :: INTEGER)) as color;
  color   
----------
 ff0000ff
(1 row)

omero=# select to_hex(fix_color(x'FFFF0000' :: INTEGER)) as color;
  color   
----------
 ff0000ff
(1 row)

omero=# select to_hex(fix_color(x'80FF0000' :: INTEGER)) as color;
  color   
----------
 ff000080
(1 row)

jburel: This looks to me like it's doing the correct thing already with regard to ARGB to RGBA. Would be great to understand how you're getting magenta out of red!

[jburel]

I think it is because the script was run twice
I am preparing two separate scripts (upgrade/downgrade)
I have also tested "in Java" only the script and did not see any problems