Task #13146 (closed)
Opened 9 years ago
Closed 8 years ago
Bug: color encoding in OME-XML does not match client behavior
Reported by: | mtbcarroll | Owned by: | jburel |
---|---|---|---|
Priority: | critical | Milestone: | Rendering |
Component: | Client | Version: | OMERO-5.2.0 |
Keywords: | n.a. | Cc: | ux@…, pkorir@…, rleigh, sbesson |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | n.a. |
Sprint: | n.a. |
Description
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!)
Change History (11)
comment:1 Changed 9 years ago by rkferguson
comment:2 Changed 9 years ago by 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.
comment:3 Changed 9 years ago by jburel
- Milestone changed from Unscheduled to OMERO-5.2.3
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
comment:4 Changed 9 years ago by 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.
comment:5 Changed 8 years ago by jburel
- Milestone changed from OMERO-5.2.3 to Rendering
comment:6 Changed 8 years ago by jamoore
- Priority changed from major to critical
comment:7 Changed 8 years ago by jamoore
- Cc sbesson added
comment:8 Changed 8 years ago by 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.
comment:9 Changed 8 years ago by 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;
comment:10 Changed 8 years ago by 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!
comment:11 Changed 8 years ago by jburel
- Resolution set to fixed
- Status changed from new to closed
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
@mtbcarroll - this also holds true when setting transparency through the UI.