Color box overwrites alpha channel of unaltered color

[hoshi]

If you try to cancel the color box (clicking OK, Cancel or close the window with X) when editing an RGBA value, it always overwrites the alpha channel with a value of full transparency 0xFF.

typedef struct { 
    UBYTE   blue;
    UBYTE   green;
    UBYTE   red; 
    UBYTE   alpha; 
} RGBA <edit=color,
        read=Str("#%02X%02X%02X%02X", red, green, blue, alpha),
        write=SScanf(value, "#%02X%02X%02X%02X", red, green, blue, alpha)>;

RGBA color1;

You have to alter the color in the color box to any (or the same) value, in order to preserve the alpha channel value. It does not happen to an RGB color, as there is no alpha channel. Does this get fixed?

[sweetscape]

Yes, we’ve confirmed there is a problem with the alpha channel when cancelling the dialog. Can you check if this update fixes the issue: http://download.sweetscape.com/010EditorWin64Installer16.0.4c.exe

Graeme
SweetScape Software

[hoshi]

Cancelling and closing the window with X works now as expected, but it still changes the alpha channel value to 0xFF when you just press OK and don’t alter anything. Is this expected?

Btw, will there be any RGB64 color support? I mean it’s difficult because there is no HTML color code for colors with more than 8-bit per channel. I guess RGBA64 will look like #RRRRGGGGBBBBAAAA in HTML color code, and RGBA48 will look like #RRRGGGBBBAAA. But I guess there is currently no standard for this.

[sweetscape]

Can you check if this update fixes the alpha issue:http://download.sweetscape.com/010EditorWin64Installer16.0.4e.exe

We are using the built-in color dialog from Qt and I believe all the sliders only support 8-bit colors. You could convert down to 8-bits per channel to use the color picker but that would obviously lose the precision. We’d probably have to write our own custom color picker to support RGA64 so we’d probably only look at it if there is a lot of interest.

Graeme
SweetScape Software

[hoshi]

Pressing OK now in the color box seems to work well now. But there is an odd behaviour in the color box when the alpha channel value is between 0x00-0x79, or between 0x7A-0xFF. When below 0x7A, it returns no data and so simply doesn’t touch any data when the color/alpha is unchanged and you just press OK. When above 0x79, it returns a value and so writes back all channels (R,G,B and A) to data, even though the color/alpha values are unchanged and you just press OK. Strange.

Yes, for ARGB64 I currently scale the values down to 8-bit (HTML color code). So this isn’t really a problem. If it is supported at some point then it’s fine .

[sweetscape]

I’m not quite sure what you are seeing here. Can you provide an example that shows the problem?

Graeme
SweetScape Software

[hoshi]

You can use this test-template to verify. On editing in the color box, it will show the return value of the color box:

typedef struct { 
    UBYTE   blue;
    UBYTE   green;
    UBYTE   red; 
    UBYTE   alpha; 
} RGBA <edit=color,
        read=Str("#%02X%02X%02X%02X", red, green, blue, alpha),
        write=Printf("%s\n",value)>;

RGBA color1;

And with the example data 0x33 0x22 0x11 0x79, editing the color in the color box and just pressing OK without changing anything, a return value is not given by the color box (as it should be):

[hoshi]

And with the example data 0x33 0x22 0x11 0x7A, editing the color in the color box and just pressing OK without changing anything, it WILL return a value. Which corresponds to data change when using the normal writeback routine: