Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Rudolph]

The attached .zip has two .png files:
app_blocking_BAD.png
arrow_WORKS.png

And as the names imply, the one works, the other does not.
Why is that and what can I do to convert these .png into files that are compatible with EAB?


The icons are from Google: https://fonts.google.com/icons
There also is a Github repository: https://github.com/google/material-design-icons

What I am doing is to convert a bunch of icons to ASTC 8x8, load these into a BT817 and display them from RAM_G.
While arrow_WORKS.png works just fine as well as the other icons I received the same way, app_blocking_BAD.png and a lot of other icons I received differently just are displayed with a mono-chrom square although EAB claims the .png is valid and compatibel.
I loaded the files into paint.net and saw no fundamental difference, these are white symbols with alpha channel.
Saving app_blocking_BAD.png with paint.net made no difference, saving an "optimized" version with EAB made no difference.

Ok, how did I get these.
The file arrow_WORKS.png is from a set of icons that I manually downloaded from the web page like this:
https://fonts.google.com/icons?selected=Material+Symbols+Outlined:home:FILL@0;wght@400;GRAD@0;opsz@20&icon.size=16&icon.color=%23FFFFFF

But well, there are a lot of icons.

The Github repository: https://github.com/google/material-design-icons is a major pain as well, first the way the files are organized:
https://github.com/google/material-design-icons/tree/master/src/alert/add_alert/materialiconsoutlined/24px.svg
https://github.com/google/material-design-icons/tree/master/png/communication/call_made/materialiconsoutlined/48dp/1x/outline_call_made_black_48dp.png

A co-worker was intrigued and came up with a script that extracts the .svg, scales them with white color and alpha and saves them all in one folder.
The result are two folders so far with over 2000 icons each, one 64x64, the other 48x48.

I randomly selected 50 from the 64x64 for a test, converted these to ASTC 8x8 and only got colored squares on the display as a result.

[Rudolph]

Ok, things got even stranger.

I wrote a python script that merges all the .raw files in the current folder into a _iconlibrary.astc file.
This works fine as the icons I am using have 64 x 64 pixel and I am compressing these with ASTC 8x8 which results in 1024 bytes per icon,
so each icon is aligned to 1024.
And the _iconlibrary.py generates a header file like this:
#define ICON_APP_BLOCKINGX 0xf0000UL
#define ICON_APP_BLOCKING_20DP 0xf0400UL
#define ICON_APP_BLOCKING 0xf0800UL
#define ICON_ARROW 0xf0c00UL

There is just an index that starts at a fixed number and gets increased by 1024 with each new file merged.
Now I can just include the header and reference the icon address in RAM_G by name.
And so far I reserved space for 55 icons.

Not very flexible and a number of conditions, but it does the job.

I compress the _iconlibrary.astc with EAB to _iconlibrary.zopfli, convert it to a .c file and put that in my source-code,
then I use CMD_INFLATE to put the data into RAM_G.
So the _iconlibrary.zopfli can not really be corrupt or the code on my display would fail completely.
And most of the icons in this set work, only a couple do not work.

app_blocking.png - does not work
app_blockingX.png - does not work, for this I opened app_blocking.png in paint.net and saved it again
app_blocking_20dp.png - works, downloaded with the web-interface

Now here is where it gets weird, I created an ESE project with _iconlibrary.astc at the same address and
the two icons that are not shown on the display work just fine with ESE.
So the pixels are there but somehow ESE can show them while my BT817 can not?

Maybe it is the compression? Well, the icons I downloaded directly are all fine.

What is going on and how do I fix this?

[BRT Community]

Hi Rudolph,
We're just trying it out here too and will update you with our results and we'll also look into why it happens,
Best Regards, BRT Community

[Rudolph]

I tried some more things.
It looks like the Alpha channel is set to white in the icons that do not work and black in the icons that do work.
But I have not found a tool yet that actually confirms this.

In binary these files that are displayed practially the same with ESE for example look totally different:
app_blocking_20dp_64x64_COMPRESSED_RGBA_ASTC_8x8_KHR.astc
13 AB A1 5C 08 08 01 40 00 00 40 00 00 01 00 00
FC FD FF FF FF FF FF FF 00 00 00 00 00 00 00 00
44 8D 48 08 04 C0 88 59 03 07 07 03 01 00 00 00
44 CD 16 28 47 07 08 20 FF FF FF FF 7F 7F 00 00
0A 08 0F E1 FF 1F EA 1F 00 00 00 00 FF FF 0F 00

app_blocking_20dp_64x64_COMPRESSED_RGBA_ASTC_8x8_KHR.astc
13 AB A1 5C 08 08 01 40 00 00 40 00 00 01 00 00
FC FD FF FF FF FF FF FF FF FF FF FF FF FF 00 00
24 8D 25 28 08 E0 0B E1 0B 83 C1 60 00 00 00 00
14 85 FE FF 03 FE 71 7F 7F 7F 7F 7F BD 05 00 00
1A 80 FF FF FF FF FF FF 01 FE 01 84 CF E7 17 00

Btw, I found this: http://www.richwhitehouse.com/index.php?content=inc_projects.php&showproject=91
Neosis can display .ASTC files, among man other formats.

And when I use the "Cycle blend" option it goes thru two transparent views and one view that has the alpha as solid color.
The icons that do not work are shown with white background, so all white, the icons that do work are shown with black background.

With this I just used IrfanView to batch-convert all the .png icons.
The option that does seem to do the trick is "Use main window color for transparency" combined with "Save transparent Color" and "Save Transparency as Alpha channel".

So I put a bunch of icons again thru EAB, rebuilt _iconlibrary.astc, zopfli compressed it, converted to to .c, put it in,
built the software and displayed the result on the BT817.
And now the icons are working. 

There may have been a loss in quality due to the conversion, at least it looks like the anti-aliasing could be better.
But maybe now we can find where it went wrong with the original conversion from .svg and re-do it.

So if I am correct and the color of the alpha-channel is set to white instead of black, this is probably something that the
PNG/JPEG Validator in EAB should point out and something to fix for the "Generated Optimized File" option.

I could not find an option to do that in the used "optipng" though.
What I found is that the version used is 0.7.7 and the optipng homepage states:
"You are strongly encouraged to upgrade to the latest version." - and lists security sensitive issues with the previous versions

[Rudolph]

I tried something different, I used an online converter to convert .png to .rgba and this is the result:

Original:
FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 40 FF FF FF EF FF FF FF 9F FF FF FF 00 FF FF FF 00
FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF BF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF BF FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00

Fixed:
00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF 40 FF FF FF EF FF FF FF 9F 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF BF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF BF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

So, in the original file all pixels are set to white and the transparent pixels have Alpha set to zero.
And in the one that works with the BT817, all transparent pixels are set to black.

Why is this not a bug in the render engine of the BT817?
The mean part in this is that Paint.net for example displays the images without any difference, the fully transparen pixels do not seem to have a color.

[BRT Community]

Hello Rudolph,

Thank you for your work in investigating this issue, we have run some EAB conversions on the PNG files and are seeing similar results.
Currently we are discussing this issue with the R&D teams and hope to have an update soon.

Best Regards,
BRT community

[Rudolph]

To clarify, I am not really considering this a bug, I was more fishing for the answer "this is not a bug because..."
Well, maybe it is in that the color of fully transparent pixels should not be used for any kind of transformation.
But when searching for what color fully transparent pixels are supposed to have, I found no definitive answer,
I did find at least one recommendation to set them to black in order to avoid issues with layer composition.
However, it is rather inconveniant to find out what the issue actually is, apart from converting it to RGBA I still could not tell what color the fully transparent pixels do have, so I would apreciate it if EAB would at least warn about this.

I had a lengthy discussion with my co-worker who batch-converted the icons from .svg for me.
He is a gfx-designer from the team that puts out our companies style-guide for UI development and he was using some Adobe software for the conversion.
And he could not tell me either what color the fully transparent pixels have in the images he provided.
But if some Adobe software produces .png like this, you can bet that I won't be the last with this issue.