Problem with E1 colors in RGB565

Bug reports
1

I have Firmware version v3.5.4 running and did a straight forward color conversion from rgb888 to rgb565 colors for a remote script.

Here are the arrays:

ABLETON_PALETTE = [
    "#fe9aaa", "#ffa529", "#cc9927", "#f7f47c", "#bffb00", "#1aff2f", "#25ffa8", "#5cffe8", "#8bc5ff", "#5480e4", "#92a7ff", "#d86ce4", "#e553a0", "#ffffff",
    "#ff3636", "#f66c03", "#99724b", "#fff034", "#87ff67", "#3dc300", "#00bfaf", "#19e9ff", "#10a4ee", "#007dc0", "#886ce4", "#b677c6", "#ff39d4", "#d0d0d0",
    "#e2675a", "#ffa374", "#d3ad71", "#edffae", "#d2e498", "#bad074", "#9bc48d", "#d4fde1", "#cdf1f8", "#b9c1e3", "#cdbbe4", "#ae98e5", "#e5dce1", "#a9a9a9",
    "#c6928b", "#b78256", "#d3ad71", "#bfba69", "#a6be00", "#7db04d", "#88c2ba", "#9bb3c4", "#85a5c2", "#8393cc", "#a595b5", "#bf9fbe", "#bc7196", "#7b7b7b",
    "#af3333", "#a95131", "#724f41", "#dbc300", "#85961f", "#539f31", "#0a9c8e", "#236384", "#1a2f96", "#2f52a2", "#624bad", "#a34bad", "#cc2e6e", "#3c3c3c",
]

ABLETON_PALETTE_RGB565 = [
    "F4D4", "FD04", "C4A4", "F78F", "BFC0", "1FE5", "27F4", "5FFC", "861F", "53FB", "8D3F", "D35B", "DA93", "FFFF",
    "F9A6", "EB40", "9389", "FF66", "87EC", "3E00", "05F5", "1F3F", "0D1C", "03D7", "835B", "B3B8", "F9D9", "CE79",
    "DB2A", "FD0E", "CD4D", "E7F5", "CF12", "B66E", "9611", "CFDB", "C77E", "B5FB", "C5DB", "ACBB", "DEDB", "A534",
    "C490", "B40A", "CD4D", "BDAC", "A5C0", "7D69", "85F6", "9597", "8517", "7C98", "A496", "BCF7", "B372", "73CE",
    "A986", "A285", "6A67", "D600", "84A3", "54E5", "0CD1", "2310", "1972", "2A93", "5A55", "9A55", "C16D", "39C7"
]

I tested all colors via RGB565 color picker for LCD and they should be very near to ableton screen colors. But on my E1 (mk1) they are not very exact. For example fff034 (yellow) gets translated to FF66 but on my display it is a clear cyan. That should not happen and seems to be a bug.

Can someone confirm or does have similar problems?

2

Colours on mine hardly ever match what I set in the editor

3

Ok perhaps the devs can say something to this problem? Could there be a bug in the correct color conversion?

4

It is not an issue of the conversion from 888 to 565. It is caused by gamma curves of the individual RGB channels on the LCD panel. To be honest It was not a real priority to work on that for a long time. With the firmware 4.0 and the launch of the Mini we added support for adjusting the gamma curves, Mini already uses that and I feel the colours look much better there (even though there is a room for improvement). I wanted to enable the feature on the mk2 and later possibly on the mk1, but it due to the fact that several models of the LCD panel were used over the time, the mk1/mk2 will require some sort of settings where user will be able to adjust it for their specic LCD panel. When enabled in the same way as on Mini, ie. curves set by us and using predefined values, different revisions of mk1/mk2 display colours differently and it looks worse than the current defaults.

1 Like
5

Would it be possible to integrate some kind of manual calibration routine?

1 Like
6

yes, that is what I am considering. I think it is the only feasible way due to different LCDs used there.

EDIT: but still, do not expect iphone like colors on the mk1 and earlier revisions of mk2. The LCD is simply not capable of that. Later mk2s feature an IPS LCDs - which are a bit better. And things got improved on the Mini because we stopped using pre-build LCD boards and we assemble them by ourselves instead. It allowed us to use better LCD panels without raising the costs.

1 Like
7

I’d like it if the colours on my mk2 were a bit more vivid and closer to what I choose, but as long as they are different from eachother for visual feedback that’s the main thing.

3 Likes
8

for me it is quite important to have at least an approximate similarity to the colors of my tracks in ableton. right now most of them are a type of green :slight_smile:

1 Like