Gradient Image - Quality distortion

Question

Hi,

There is some distortion in image quality when imported into embedded wizard studio and flashed the same in the target.

We are using IMXRT1050 with Embedded Wizard 9.2

 

Original Image from Photoshop

Distorted Image:

It has some colored lines

These are the multiple usecases tested with different color formats of Bitmaps and Framebuffer

Usecase 1:

Platform Package/FrameBuffer Color Format : RGBA8888

Bitmap Resource Color Format : RGBA8888

Output :

Embedded Wizard Studio : Without distortion

On the Target : With distortion(i.e. with some colored lines)

 

Usecase 2:

Platform Package/FrameBuffer Color Format : RGB565

Bitmap Resource Color Format : RGB565

Output :

Embedded Wizard Studio : Without distortion

On the Target : With distortion(i.e. with some colored lines)

 

Usecase 3:

Platform Package/FrameBuffer Color Format : RGB565

Bitmap Resource Color Format : RGBA8888

Output :

Embedded Wizard Studio : With distortion(i.e. with some colored lines)

On the Target : With distortion(i.e. with some colored lines)

 

Usecase 4:

Platform Package/FrameBuffer Color Format : RGBA8888

Bitmap Resource Color Format : RGB565

Output :

Embedded Wizard Studio : Without distortion

On the Target : With distortion(i.e. with some colored lines)

 

Why there is distortion of the image which has gradient (i.e. with some colored lines) when flashed on target?

 

Best Regards,

Preethi S,

Robert Bosch - India

Answer 1

Hello Preethi,

according to the schematics of the IMXRT1050-EVKB the display is only connected with RGB 565 - as a result, all colors are limited to RGB565 even though you have a framebuffer with RGB888.

In case you are using a RGB565 Platform Package and a RGB565 bitmap resource, the results should appear identical on the target as you see it in the Prototyper (as long as you have Opacity=255).

Is this the case? If not, can you please post a photo?

Best regards,

Manfred

Comments

Hi Manfred,

Thanks for the Hint.

1. In case you are using a RGB565 Platform Package and a RGB565 bitmap resource, the results should appear identical on the target as you see it in the Prototyper (as long as you have Opacity=255)

    - This point is true in our case. The image looks same both in Prototyper and Target.

But the above four usecases result are with Opacity change in Int32Effect.

i.e. When we change the opacity when using both Platform Package and Bitmap Resource Format as RGB565 , then the solid color lines appear which is so clearly visible in the Target .

The image (with solid color lines) is attached below

Anyway to avoid this issue during opacity change animation?

Best Regards,

Preethi S

---

Hello Preethi,

probably the problem is related to the fact that RGB565 uses different number of bits for red/blue and green channels. During the fade-in operation (when you modify the opacity value), the red, green, blue channels are multiplied by the opacity factor. The green channel having 6-bits can assume values which lie between value of the red/blue channels - these have only 5-bits. The range for green is two times bigger than the for red/blue.

Assuming you have a pixel for some gray color. In such case: the channels red and blue are e.g. 7. The corresponding value for the channel green = 14 because it has one bit more. During the animation the channel values change. If you fade-in the pixel with some white background, the pixel will be highlighted. The values for the channels increase. 

Since the chanels occupy different number of bits, the channels don't increase exactly in the same rate. The green channel has one bit more, so you will get as next color: red, blue = 7 and green =15. The resulting pixel will get a slightly green touch. With the next step, the channels red, blue assume 8 and green 16 which is again correct gray color.

I think, the unique possibility to workaround the problem is to prepare the bitmap with colors using 5 bits for the green channel. Alternatively you can try to dither the bitmap. This can be done either with a graphic editor or if you are using Embedded Wizard 9.20 with the attribute Dithering.

Best regards

Paul Banach

---

Hi Paul,

We tried with the following combinations

1. Bitmap and Framebuffer Color Format - RGB565

2. Bitmap and Framebuffer Color Format - RGBA8888

3. Bitmap Color Format - RGBA8888 and FrameBuffer Color Format - RGB565

In all these combinations again we tried with the two usecases

1. We kept the image static without any effect

2. We tried to change the opactiy value through Int32Effect

And the output for both usecases is the distorted image with the colored lines as mentioned in the previous discussion.

May be for the usecase 1 and 3 , the point which you mentioned may hold true, but regarding the usecase 2 both Bitmap and Framebuffer color format with RGBA8888, why the issue is there in this case also since all Red , Blue and Green has 8 bits each here?

Best Regards,

Preethi S

---

Hello Preethi,

as mentioned in Manfred's and my posts above, this ugly effect roots in the color limitation of RGB565. In your concrete case, your HW is using internally RGB565. Even if you use RGBA8888 Platform Package, the effect will not disappear. The simple answer: the color space of RGB565 is too small to cover the very fine gradient steps in your image. This is not a limitation of EmWi.

In order to not oversee any other error, I have just made some tests using the image from your original post. Similarly to your application case I display the image with animated opacity. Following are the results:

Usecase 1:
-----------

Platform Package/FrameBuffer Color Format : RGBA8888
Bitmap Resource Color Format              : RGBA8888

Embedded Wizard Studio         : Without distortion during entire animation
Expected results on the Target : With distortion because the resulting RGBA8888
                                 colors will be reduced to RGB565.

Usecase 2:
-----------

Platform Package/FrameBuffer Color Format : RGB565
Bitmap Resource Color Format              : RGB565

Embedded Wizard Studio         : With distortion because all colors are reduced
                                 to RGB565.
Expected results on the Target : The same distortion expected.

Usecase 3:
-----------

Platform Package/FrameBuffer Color Format : RGB565
Bitmap Resource Color Format              : RGBA8888

Embedded Wizard Studio         : With distortion because all resulting colors are
                                 reduced to RGB565.
Expected results on the Target : Same distortion expected.

Usecase 4:
-----------

Platform Package/FrameBuffer Color Format : RGBA8888
Bitmap Resource Color Format              : RGB565

Embedded Wizard Studio         : Without distortion
Expected results on the Target : With distortion because the resulting RGBA8888
                                 colors will be reduced to RGB565.

My observation coincides mainly with your results. The unique difference is the Usecase 2. Here my tests show visible distortion effects as it is expected due to the RGB565 limitation. The unique possibility to workaround the effects when using RGB565 limited HW would expect the image to be recalculated with additional dithering every time you show the image with new opacity value. With the additional dithering the ugly lines would be covered. Since dithering calculation is a CPU intensive task and the results are not always as expected, this function is not supported at the runtime of an EmWi application.

Such dithering is supported during the code generation only. With this, color rich pictures like your Photoshop image should look good even if reduced to RGB565 color format or even Index8. As soon as you blend such image with some background or you modulate its opacity, new colors arise. To avoid the ugly effects these new colors would require new dithering calculation - what is avoided due to high CPU load.

Thus, what can you do:

option 1: avoid the fine gradient steps in the image.

option 2: avoid the fade-out animation.

option 3: use HW incl. LCD supporting 888 color format together with the RGBA8888 or RGB888 Platform Package.

Although I have no workaround for you, I hope the answer helps to understand the backgrounds of this ugly effect.

Best regards

Paul Banach

---

Hi Paul,

One Clarification is that we are not using i.MXRTEVKB with RGB565 display. We are using our own board with display interface format RGB888.

There is an additional color conversion by eLCDIF module at the final stage.  It converts the final frame buffer (RGB565/RGB888 or whatever) to make it compatible with the connected display(configurable) which is RGB888 in our case.

Best Regards,

Preethi S

---

Hello Preethi,

in such case, if your HW does not perform any color reduction, the LCD does support 8-bit per color channel and you are using the RGB888 or RGBA8888 platform package, I would expect the system to work.

If this is not the case, please search in the build environment for the example ColorFormats. This example shows some gradients and is as such very useful to analyze whether the LCD is connected correctly and all 8-bits per color channel are used. Please run the example on your HW, take pictures from the display and post these here for us so we can analyze them.

Best regards

Paul Banach