Use only 32-bit ARGB or RGB565 formats

[TerryFogg]

Description

The code has been modified to only use ARGB or RGR565 format.

Code was also modified to the RotateImage method to properly rotate images with a transparent background.
This was not in place, although it was already in place for stretch image.

Motivation and Context

Problems with colours. This eliminates some confusion with the formats in memory.

• Resolves GRAPHICS - Color problems. Change native code to eliminate the RGB/BGR issues Home#1378.

How Has This Been Tested?

The modifed code was tested on

STM32769I_Discovery board
ESP32 Wrover Kit v4.1
ESP32 Wrover Kit 4.1 with Generic SPI class and C# class of ili9341 from the Managed Drivers.
All three tests showed the same resulting colours.
See the following testing notes below

Testing notes

A selection of 9 ARGB colours were selected to test operation

During native debugging, examination of the memory buffer of the Bitmap showed that it was correctly in the RGB565 format stored as little endian.

Many references to native color format are in the code and this native format is the RGB565 format.
There are assumptions in the code that a pixel is 2 bytes, this can be seen in the image manipulation routines which operate on memory copy of bytes assuming 16-bit pixels.

JPEG test was created using Paint.net to set 9 pixels to the ARGB colours then saved to disk and re-read. The values re-read from the disk are "compressed" so are slightly different. The expected values were found using the eye-dropper tool of paint.net to get the hex colour values.

Bitmaps saved in the resource file are all converted to RGB565 format before being embedded into the assembly and deployed to flash. (This is by design)

The graphics code supports reading in bitmaps of 32-bit, 24-bit and 8-bit indexed, usually from file. For this test the bitmaps are included as a C# byte arrays to eliminate the need to have a file system.

Restoring RGB565 to ARGB

Restored results are inexact values due to the loss of 3 bits red, 2 bits green and 3 bits blue. The restoration code uses an algorithm originally from .NetMF to approximate the original ARGB colour.

Gif values should be the same as SetPixel, GetPixel, unlike Jpeg GIF uses lossless compression.

// |-------------------|---------------|----------------|---------------|--------------| 
// |     Colours       | 32-bit ARGB   |   Set Pixel    |  Get Pixel    |      JPEG    |
// |                   |  Source       | 16-bit RGB565  | Restored ARGB | Restored RGB |
// |-------------------|---------------|----------------|---------------|--------------|
// | Color.DarkRed     |  0xFF8B0000   |    0x8800      |  0xFF8F0000   |   0x8F0000   |
// | Color.Red         |  0xFFFF0000   |    0xF800      |  0xFFFF0000   |   0xFE0000   |
// | Color.LightPink   |  0xFFFFB6C1   |    0xFDB8      |  0xFFFFB7C0   |   0xFFB6C1   |
// | Color.LightGreen  |  0xFF90EE90   |    0x9772      |  0xFF90EF90   |   0x90EE90   |
// | Color.Green       |  0xFF008000   |    0x0400      |  0xFF008000   |   0x008001   |
// | Color.DarkGreen   |  0xFF006400   |    0x0320      |  0xFF006700   |   0x006401   |
// | Color.LightBlue   |  0xFFADD8E6   |    0xAEDC      |  0xFFAFD8E0   |   0xAFD9E6   |
// | Color.Blue        |  0xFF0000FF   |    0x001F      |  0xFF0000FF   |   0x0000FE   |
// | Color.DarkBlue);  |  0xFF00008B   |    0x0011      |  0xFF00008F   |   0x01008C   |
// |-------------------|---------------|----------------|---------------|--------------|

Screenshots

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue with code or algorithm)
• New feature (non-breaking change which adds functionality to code)
• Breaking change (fix or feature that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dev Containers (changes related with Dev Containers, has no impact on code or features)
• Dependencies (update dependencies and changes associated, has no impact on code or features)
• Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist

• My code follows the code style of this project (only if there are changes in source code).
• My changes require an update to the documentation (there are changes that require the docs website to be updated).
• I have updated the documentation accordingly (the changes require an update on the docs in this repo).
• I have read the CONTRIBUTING document.
• I have tested everything local that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dev Containers (changes related with Dev Containers, has no impact on code or features)
• Dependencies (update dependencies and changes associated, has no impact on code or features)
• Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist

• My code follows the code style of this project (only if there are changes in source code).
• My changes require an update to the documentation (there are changes that require the docs website to be updated).
• I have updated the documentation accordingly (the changes require an update on the docs in this repo).
• I have read the CONTRIBUTING document.
• I have tested everything locally and all new and existing tests passed (only if there are changes in source code).

[josesimoes]

@TerryFogg LGTM! As usual, very detailed PR comment with a detailed explanation.
Thank you for your very professional work. 💯 😃

[josesimoes]

Let me ask @Ellerbach to have another pair of eyes on this because he's very familiar with this code. 😉

[TerryFogg]

I need to look at the samples. The basic primitives works as expected, but I see there is another for managed drivers that converts the new System.Drawing colors to BGR before using, as I would expect as the original nanoFramework colors I loaded were already converted to BGR.
But this can be done quickly when its in main

[josesimoes]

@CoryCharlton care to take a look at this please? Possible impact on nanoframework/nanoFramework.Graphics#133.

[TerryFogg]

These changes don't change the native calls, so, it should not be an issue unless there is use of BGR color formats being used

[Ellerbach]

It looks ok all up. I'm sure Terry tested it. And if it works with the primitives properly and the bitmap, it works for everything. Thanks!

[CoryCharlton]

I don't see any conflicts with my PR.