Alpha images rendered correctly only to dark background

giusloq · December 4, 2018 at 12:28 PM

I have many alpha images. For example:

C

static GUI_CONST_STORAGE unsigned char acopen[] = {
  /* ABS: 005 Pixels @ 000,000*/ 0, 5, 0xFF, 0xF4, 0xC5, 0x51, 0x02, 
  /* RLE: 011 Pixels @ 005,000*/ 11, 0x00, 
  /* ABS: 009 Pixels @ 016,000*/ 0, 9, 0x15, 0x7A, 0xEE, 0x74, 0x04, 0x5D, 0xD3, 0xDA, 0x6B, 
  /* RLE: 010 Pixels @ 006,001*/ 10, 0x47, 
  /* ABS: 009 Pixels @ 016,001*/ 0, 9, 0x32, 0x00, 0x7B, 0x0D, 0x00, 0x00, 0x01, 0x4C, 0xC4, 
  /* RLE: 011 Pixels @ 006,002*/ 11, 0xFF, 
  /* ABS: 002 Pixels @ 017,002*/ 0, 2, 0x32, 0x16, 
  /* RLE: 006 Pixels @ 000,003*/ 6, 0x00, 
  /* ABS: 003 Pixels @ 006,003*/ 0, 3, 0x3B, 0xB3, 0xFE, 
  /* RLE: 008 Pixels @ 009,003*/ 8, 0xFF, 
  /* RLE: 001 Pixels @ 017,003*/ 1, 0x47, 
  /* RLE: 009 Pixels @ 018,003*/ 9, 0x00, 
  /* ABS: 002 Pixels @ 008,004*/ 0, 2, 0x2C, 0xA4, 
  /* RLE: 007 Pixels @ 010,004*/ 7, 0xFF, 
  /* RLE: 001 Pixels @ 017,004*/ 1, 0x47, 
  /* RLE: 011 Pixels @ 018,004*/ 11, 0x00, 
  /* RLE: 001 Pixels @ 010,005*/ 1, 0x9E, 
  /* RLE: 006 Pixels @ 011,005*/ 6, 0xFF, 
  /* RLE: 001 Pixels @ 017,005*/ 1, 0x47, 
  /* RLE: 011 Pixels @ 018,005*/ 11, 0x00, 
  /* ABS: 002 Pixels @ 010,006*/ 0, 2, 0x0F, 0xFD, 
  /* RLE: 005 Pixels @ 012,006*/ 5, 0xFF, 
  /* RLE: 001 Pixels @ 017,006*/ 1, 0x47, 
  /* RLE: 012 Pixels @ 018,006*/ 12, 0x00, 
  /* RLE: 001 Pixels @ 011,007*/ 1, 0xD4, 
  /* RLE: 005 Pixels @ 012,007*/ 5, 0xFF, 
  /* RLE: 001 Pixels @ 017,007*/ 1, 0x47, 
  /* RLE: 012 Pixels @ 018,007*/ 12, 0x00, 
  /* RLE: 001 Pixels @ 011,008*/ 1, 0xB8, 
  /* RLE: 005 Pixels @ 012,008*/ 5, 0xFF, 
  /* RLE: 001 Pixels @ 017,008*/ 1, 0x47, 
  /* RLE: 012 Pixels @ 018,008*/ 12, 0x00, 
  /* RLE: 001 Pixels @ 011,009*/ 1, 0xB7, 
  /* RLE: 005 Pixels @ 012,009*/ 5, 0xFF, 
  /* RLE: 001 Pixels @ 017,009*/ 1, 0x47, 
  /* RLE: 012 Pixels @ 018,009*/ 12, 0x00, 
  /* RLE: 001 Pixels @ 011,010*/ 1, 0xB7, 
  /* RLE: 005 Pixels @ 012,010*/ 5, 0xFF, 
  /* RLE: 001 Pixels @ 017,010*/ 1, 0x47, 
  /* RLE: 012 Pixels @ 018,010*/ 12, 0x00, 
  /* RLE: 001 Pixels @ 011,011*/ 1, 0xB7, 
  /* RLE: 005 Pixels @ 012,011*/ 5, 0xFF, 
  /* RLE: 001 Pixels @ 017,011*/ 1, 0x47, 
  /* RLE: 012 Pixels @ 018,011*/ 12, 0x00, 
  /* RLE: 001 Pixels @ 011,012*/ 1, 0xB7, 
  /* RLE: 005 Pixels @ 012,012*/ 5, 0xFF, 
  /* RLE: 001 Pixels @ 017,012*/ 1, 0x47, 
  /* RLE: 009 Pixels @ 018,012*/ 9, 0x00, 
  /* ABS: 004 Pixels @ 008,013*/ 0, 4, 0x4E, 0x00, 0x00, 0xB7, 
  /* RLE: 005 Pixels @ 012,013*/ 5, 0xFF, 
  /* RLE: 001 Pixels @ 017,013*/ 1, 0x47, 
  /* RLE: 008 Pixels @ 018,013*/ 8, 0x00, 
  /* ABS: 005 Pixels @ 007,014*/ 0, 5, 0x44, 0xFF, 0x3A, 0x00, 0xB7, 
  /* RLE: 005 Pixels @ 012,014*/ 5, 0xFF, 
  /* RLE: 001 Pixels @ 017,014*/ 1, 0x47, 
  /* RLE: 008 Pixels @ 018,014*/ 8, 0x00, 
  /* ABS: 005 Pixels @ 007,015*/ 0, 5, 0x3D, 0xFF, 0x4A, 0x00, 0xB7, 
  /* RLE: 005 Pixels @ 012,015*/ 5, 0xFF, 
  /* RLE: 001 Pixels @ 017,015*/ 1, 0x47, 
  /* RLE: 009 Pixels @ 018,015*/ 9, 0x00, 
  /* ABS: 004 Pixels @ 008,016*/ 0, 4, 0x5F, 0x03, 0x00, 0xB7, 
  /* RLE: 005 Pixels @ 012,016*/ 5, 0xFF, 
  /* RLE: 001 Pixels @ 017,016*/ 1, 0x47, 
  /* RLE: 012 Pixels @ 018,016*/ 12, 0x00, 
  /* RLE: 001 Pixels @ 011,017*/ 1, 0xB7, 
  /* RLE: 005 Pixels @ 012,017*/ 5, 0xFF, 
  /* RLE: 001 Pixels @ 017,017*/ 1, 0x47, 
  /* RLE: 012 Pixels @ 018,017*/ 12, 0x00, 
  /* RLE: 001 Pixels @ 011,018*/ 1, 0xB7, 
  /* RLE: 005 Pixels @ 012,018*/ 5, 0xFF, 
  /* ABS: 003 Pixels @ 017,018*/ 0, 3, 0x47, 0x00, 0x24, 
  /* RLE: 010 Pixels @ 001,019*/ 10, 0x00, 
  /* ABS: 009 Pixels @ 011,019*/ 0, 9, 0xB7, 0xEA, 0xE7, 0xE7, 0xE7, 0xD2, 0x19, 0x36, 0x65, 
  /* RLE: 010 Pixels @ 001,020*/ 10, 0x00, 
  /* ABS: 002 Pixels @ 011,020*/ 0, 2, 0xB7, 0x17, 
  /* RLE: 004 Pixels @ 013,020*/ 4, 0x00, 
  /* ABS: 004 Pixels @ 017,020*/ 0, 4, 0x01, 0xA7, 0xEA, 0x1E, 
  /* RLE: 009 Pixels @ 002,021*/ 9, 0x00, 
  /* ABS: 012 Pixels @ 011,021*/ 0, 12, 0xB7, 0x6E, 0x5F, 0x5F, 0x5F, 0x75, 0xD8, 0xFF, 0xFF, 0xE0, 0x68, 0x08, 
  /* RLE: 007 Pixels @ 004,022*/ 7, 0x00, 
  /* RLE: 001 Pixels @ 011,022*/ 1, 0xB7, 
  /* RLE: 010 Pixels @ 012,022*/ 10, 0xFF, 
  /* ABS: 003 Pixels @ 003,023*/ 0, 3, 0xE8, 0x7A, 0x10, 
  /* RLE: 005 Pixels @ 006,023*/ 5, 0x00, 
  /* RLE: 001 Pixels @ 011,023*/ 1, 0xB7, 
  /* RLE: 012 Pixels @ 012,023*/ 12, 0xFF, 
  /* ABS: 007 Pixels @ 005,024*/ 0, 7, 0xF2, 0x8C, 0x1B, 0x00, 0x00, 0x00, 0xC7, 
  /* RLE: 014 Pixels @ 012,024*/ 14, 0xFF, 
  /* ABS: 005 Pixels @ 007,025*/ 0, 5, 0xF9, 0x9E, 0x2F, 0x3E, 0xFE, 
  /* RLE: 007 Pixels @ 012,025*/ 7, 0xFF, 




  0};  /* 275 bytes for 494 pixels */


GUI_CONST_STORAGE GUI_BITMAP bmopen = {
  19, /* XSize */
  26, /* YSize */
  19, /* BytesPerLine */
  GUI_COMPRESS_RLE8, /* BitsPerPixel */
  (unsigned char *)acopen,  /* Pointer to picture data */
  NULL,  /* Pointer to palette */
  GUI_DRAW_RLEALPHA
};

Display More

Every pixel is descripted as a single byte that represents the "quantity" of the image respect the background. Of course, the content of those images is only the shape.

I draw alpha images with GUI_SetColor(), that selects the color of the shape, and GUI_DrawBitmap() that really draws the bitmap on the screen. It works very well during the simulation at the PC, and it seems working well on the embedded target when the background is dark (black) or blue (GUI_BLUE). When the background is light (GUI_RED or GUI_GREEN) the alpha blending doesn't work well. The shape isn't smooth. I don't know if it is correct, I think the real color used are calculated if the background was always black.

My driver is GUIDRV_FLEXCOLOR_F66709. Here it is the initialization.

C

#define XSIZE_PHYS 320
#define YSIZE_PHYS 240
#define NUM_VSCREENS 1


void LCD_X_Config(void) {
	GUI_DEVICE * pDevice;
	GUI_PORT_API PortAPI;
	CONFIG_FLEXCOLOR cfgFlexColor = { 0 };


	pDevice = GUI_DEVICE_CreateAndLink(GUIDRV_FLEXCOLOR, COLOR_CONVERSION, 0, 0);
	if (DISPLAY_ORIENTATION & GUI_SWAP_XY) {
		LCD_SetSizeEx(0, YSIZE_PHYS, XSIZE_PHYS);
		if (NUM_VSCREENS > 0)
			LCD_SetVSizeEx(0, YSIZE_PHYS * NUM_VSCREENS, XSIZE_PHYS);
	} else {
		LCD_SetSizeEx(0, XSIZE_PHYS, YSIZE_PHYS);
		if (NUM_VSCREENS > 0)
			LCD_SetVSizeEx(0, XSIZE_PHYS, YSIZE_PHYS * NUM_VSCREENS);
	}


	cfgFlexColor.FirstCOM = 0;
	cfgFlexColor.FirstSEG = 0;
	cfgFlexColor.NumDummyReads = 1;		// Sembra sia necessario per l'ILI9341
	cfgFlexColor.Orientation = DISPLAY_ORIENTATION;
	cfgFlexColor.RegEntryMode = 0; /* Gli altri bit per il registro che contiene l'orientation */
	GUIDRV_FlexColor_Config(pDevice, &cfgFlexColor);
//	GUIDRV_FlexColor_SetReadFunc();


	PortAPI.pfWrite16_A0 = LCD_X_8080_16_Write00_16;
	PortAPI.pfWrite16_A1 = LCD_X_8080_16_Write01_16;
	PortAPI.pfWriteM16_A1 = LCD_X_8080_16_WriteM01_16;
	PortAPI.pfReadM16_A1 = LCD_X_8080_16_ReadM01_16;
	GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI,
			GUIDRV_FLEXCOLOR_F66709,
			GUIDRV_FLEXCOLOR_M16C0B16);
}

Display More

So I don't use cache (and I can't use cache for RAM restrictions). So I think emWin is forced to read back the color of pixels during drawing of an alpha image. One cause of my problem could be a wrong read back. For example, the behaviour I observed can be explined if the driver reads back always zero (black colors). So the alpha drawing works (or appears good) when the background is black or dark.

How could I check if this is correct? I know ILI9341 supports read back.

Thomas W. · December 4, 2018 at 1:20 PM

Hi,

I use the ILI9341 as well and had similar problems with the read function. I use the EDIT widget with the blinking cursor functionality. Therefore emWin reads back the color for the blinking functionality.
It is important that you use the correct parameters for the read function GUIDRV_FlexColor_SetReadFunc66709_B16(). There are several different parameters. For me I have to pass GUIDRV_FLEXCOLOR_READ_FUNC_III as second parameter. (s. manual)

It is also important to call the GUIDRV_FlexColor_SetReadFunc66709_B16() function befor calling the GUIDRV_FlexColor_SetFunc() function.

here is my code:

C

void LCD_X_Config(void) 
{
  GUI_DEVICE * pDevice;
  GUI_PORT_API PortAPI = {0}; 
  CONFIG_FLEXCOLOR Config = {0};
  
  #if (NUM_BUFFERS > 1)
    GUI_MULTIBUF_Config(NUM_BUFFERS);
  #endif
  //
  // Set display driver and color conversion for 1st layer
  //
  pDevice = GUI_DEVICE_CreateAndLink(DISPLAY_DRIVER, COLOR_CONVERSION, 0, 0);
  //
  // Common display driver configuration
  //
  if (LCD_GetSwapXY()) 
  {
    LCD_SetSizeEx (0, YSIZE_PHYS, XSIZE_PHYS);
    LCD_SetVSizeEx(0, YSIZE_PHYS * NUM_VSCREENS, XSIZE_PHYS);
  }
  else
  {
    LCD_SetSizeEx (0, XSIZE_PHYS, YSIZE_PHYS);
    LCD_SetVSizeEx(0, XSIZE_PHYS, YSIZE_PHYS * NUM_VSCREENS);
  }
  //
  // Configuration of GUIDRV_FLEX_COLOR
  //
  //
  // Set controller and operation mode
  //
  PortAPI.pfWrite16_A0  = LCD_X_Write0_16;
  PortAPI.pfWrite16_A1  = LCD_X_Write1_16;
  PortAPI.pfWriteM16_A1 = LCD_X_WriteM1_16;
  PortAPI.pfReadM16_A1  = LCD_X_ReadM1_16;
  PortAPI.pfRead16_A1   = LCD_X_Read1_16;  
  GUIDRV_FlexColor_SetReadFunc66709_B16(pDevice, GUIDRV_FLEXCOLOR_READ_FUNC_III);
  GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI, GUIDRV_FLEXCOLOR_F66709, GUIDRV_FLEXCOLOR_M16C0B16);
  //
  // Orientation and offset of SEG/COM lines
  //
  Config.Orientation   = DISPLAY_ORIENTATION;
  Config.RegEntryMode  = 0;
  GUIDRV_FlexColor_Config(pDevice, &Config);
}

Display More

giusloq · December 4, 2018 at 5:26 PM

I didn't call GUIDRV_FlexColor_SetReadFunc66709_B16(), so I think the driver was using GUIDRV_FLEXCOLOR_READ_FUNC_I (the default function).

When I tried to set GUIDRV_FLEXCOLOR_READ_FUNC_III, the program crashes with a HardFault. The call stack says that _ReadRect_16bpp_B16_III() calls guimem() that failed.
Do you know why?

Could you share the source code of LCD_X_ReadM1_16 and LCD_X_Read1_16?

Thomas W. · December 5, 2018 at 7:31 AM

Good morning,

here we go:

C

/** 
  @verbatim 
  According to the address line pin we have to calculate the data address.
  For line A16 the address is calculated like this:
  RAM base address = 0X60000000 + 2^16 * 2 = 0X60000000 + 0X20000 = 0X60020000 
  This address is the data address.
  Example code:
  #define Bank1_LCD_C ((uint32_t) 0x60000000) // Disp Reg ADDR 
  #define Bank1_LCD_D ((uint32_t) 0x60020000) // Disp Data ADDR for A16
  @endverbatim 
*/


/* LCD /CS is NE1 - Bank 1 of NOR/SRAM Bank 1 */
#define LCD_BASE   (0x60000000UL) /* see memory map */


#define LCD_REG16  (*((volatile uint16_t *)(LCD_BASE  ))) 
#define LCD_DAT16  (*((volatile uint16_t *)(LCD_BASE+0x20000U)))


/**
* @brief This function reads multiple data half words from the TFT.
*        The command/data pin is kept high during read operation.
* @param Data Pointer to the data which is read from the TFT.
* @param NumItems Number of data half words which were read. 
* @return None
*/
void LCD_X_ReadM1_16(uint16_t * Data, int NumItems) 
{
  for (; NumItems; NumItems--) 
  {
    *Data++ = LCD_DAT16;
  }  
}




/**
* @brief This function reades data from the TFT. The command/data pin is 
*        kept high during read operation.
* @return Read TFT data
*/
uint16_t LCD_X_Read1_16(void) 
{
  return (LCD_DAT16);
}

Display More

I am on a STM32F2 and use the FMSC peripheral for the communication with the display. Have you reserved enough memory for emWin in GUIConf.c (Function GUI_ALLOC_AssignMemory();)?

giusloq · December 5, 2018 at 10:20 AM

I found the problem that caused the crash. I forgot to set PortAPI.pfRead16_A1 for GUIDRV_FlexColor_SetFunc(). Now it works.

Anyway I didin't understand. We configured ILI9341 to use the 16-bits interface in 16-bits per pixel (5-6-5). When the driver wants to set a pixel color, it issues a write command with a single 16-bits word where the color is packed in 5-6-5 format.
Why the ILI9341 responds with 2-bytes (18-bits 6-6-6 format) during read commands? Is it possible to configure the driver to responds in 5-6-5 format, avoiding one read command for every pixel? In this case we could use GUIDRV_FLEXCOLOR_READ_FUNC_III.

Thomas W. · December 12, 2018 at 8:06 AM

Hello,

to be honest, I tested the 3 different read function variants and the read function III was the only one which was working in my application. For the test I used a function where I can dump the screen content on a USB MSD with the aid of GUI_BMP_Serialize(). I took a lot of time in this issue, but I aborted the investigations after I got the correct behavior. Nevertheless this was a long time ago (2 years?) but today I took a deeper look into the ILI9341/emWin manuals and found the following:

If I take a look into the ILI9341 manual to the section "8080-II Series Parallel Interface" there are 2 data packets in the drawing for the read cycle.

emWin Manual:
Commands supported by LCD_SetDevFunc()
Further information about the LCD layer routines can be found under LCD layer routines
on page 1277.
Important note on reading back pixel data from the controller
Because of the plurality of the supported display controllers and their operation
modes the driver has not been tested with each interface of each supported controller.
The behavior of the controller when reading back pixel data often depends on
custom configuration and hardware details. Because of that it could happen, that the
driver has no appropriate reading function(s) available. In that case the above
explained function LCD_SetDevFunc() can be used to set application defined functions
for reading back pixel data.
The main problem for the driver here is not getting data from the driver. Getting the
color bits in the right order is the problem here. The custom defined functions need
to supply pixel index values. This index format needs to comply to the index format
determined by the color conversion routines configured for the driver device.
Because the data supplied by the hardware interface functions of the driver in most
cases does not have the right index format, the reading routines need to convert that
raw data into the required pixel index format determined by the driver device configuration.
For details about the hardware interface functions please also refer to
GUIDRV_FlexColor_SetFunc() and its parameter pHW_API.
For details about the pixel index format please also refer to
GUI_DEVICE_CreateAndLink() and its parameter pColorConvAPI and the chapter
Colors.
A sample configuration which shows how custom reading functions can be achieved is
available in the configuration file sample folder shipped with the driver.

Maybe you must define your own read back function in order to achieve single byte reads. But that is only an assumption...

regards Thomas

giusloq · December 12, 2018 at 2:00 PM

Quote from Thomas W.

Maybe you must define your own read back function in order to achieve single byte reads. But that is only an assumption...

I don't think so. The controller (ILI9341) replies with one dummy plus two data bytes. Both bytes have colors, so one-byte read can't work.

I was searching a command to configure the controller to reply with only one byte (encoded as 5-6-5), but it seems impossible. This behaviour can't be changed only by rewriting a new read back funtion on the host controller.

Alpha images rendered correctly only to dark background

Participate now!

Users Viewing This Thread