Feature request: smaller generated image source files (e.g. image_EXAMPLE_IMAGE.cpp)

[unsigned_char_array]

Currently image source files take up a lot of drive space.

My image folder TouchGFX\generated\images\src is 44.5MiB on my drive.

TouchGFX projects can take up a lot of drive space as is (https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/gfxdesigner-option-to-auto-delete-touchgfx-folder-upon-exit/m-p/724758#M39655). So these files just add to it.

You could use build scripts or cmake to add data from binary files to temporary source files. But this can be quite a hassle to make it platform independent. But that would save a lot of drive space as the binary files take up less space than source files with hex constants. (Example to use OBJCOPY)

There are ways to shrink the source files. One way is to use uint64_t hex constants instead of uint8_t hex constants to reduce overhead.
Before:

LOCATION_PRAGMA("ExtFlashSection")
KEEP extern const unsigned char image_test_image[] LOCATION_ATTRIBUTE("ExtFlashSection") = { // a x b RGB565 pixels.
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 
0x0C, 0x0D, 0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 
0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F, ...
};

After:

header file:

template <typename... T>
constexpr std::array<uint8_t, sizeof...(T)*8> u64_array_to_u8_array(T&&... t) 
{
    std::array<uint8_t, sizeof...(T)*8> out{};
    std::array<int64_t, sizeof...(T)> in = {t...};

    for (size_t i = 0; i < sizeof...(T)*8; ++ i) {
        out[i] = uint64_t(in[i/8]) >> ((7-i%8)*8);//big endian
    }
    return out;
}

smaller source file:

LOCATION_PRAGMA("ExtFlashSection")
KEEP extern const unsigned char image_test_image[] LOCATION_ATTRIBUTE("ExtFlashSection") =  // a x b RGB565 pixels.
u64_array_to_u8_array(
    0x0001020304050607,0x08090A0B0C0D0E0F,
    0x1011121314151617,0x18191A1B1C1D1E1F, ...
);

Large files can easily be 50% smaller on drives this way. Especially with wider lines and without whitespace.
I don't know how this affects compression of source files.

Using base64 would work too, but that would require c++17 or c++20 and by default TouchGFX uses c++14. Also it won't compress as well in zip or in git. Here is an example of base64: https://stackoverflow.com/a/79042473/15307950

[MM..1]

Seems you completely missunderstand, i say 8-64 change nothink (yes some space saves) , but normal inteligent way is dont use source files here at all. Builder need create it in memory only on build time = zero disk space...

And AI i mean for TouchGFX builder , not for your gui. Plus AI with model as today used, need better name , for me brute force I is more adequate.

[unsigned_char_array]

---

@MM..1 wrote:

Seems you completely missunderstand, i say 8-64 change nothink (yes some space saves) , but normal inteligent way is dont use source files here at all. Builder need create it in memory only on build time = zero disk space...

---

I agree. I actually proposed that in my start post. But the challenge is that it needs to be implemented in STM32CubeIDE, Makefile and in Visual Studio as those are the three tools used for building. My solution would require the generating of the source file to be only slightly modified and only 1 header file included. I proposed multiple solutions since there are multiple ways of doing it.

---

@MM..1 wrote:

And AI i mean for TouchGFX builder , not for your gui. Plus AI with model as today used, need better name , for me brute force I is more adequate.

---

What is "TouchGFX builder"? Do you mean "TouchGFX Designer"? And what features would this add?

[MM..1]

This add very simple, but real AI, feature : You add image to assets -> AI analyze image and report you for example when TGFX store it to code as PNG you get .... or when is converted by AI to SVG you get .... and you choice.

And Designer have load to target with build, then have too builder part and this use gcc, but why not simply preprocessing dont create ram disk and place here image cpp files  = no space on HDD usw.

We live in 2024, but compilers and IDE AI is simmilar to TurboC 1994.

[Tesla DeLorean]

Probably not immediately, but I'm pointing it out, like Nostradamus, as not being an "unforeseen" issue when it ultimately bites someone.

The path might take us to a place where a build/simulation platform might not be the same as the target, and frequently when encryption and signing are involved, ordering does matter.

What I'd like to see is ST, as a matter of policy with auto-generated code, is to be sparing with white-space, and be efficient. Determine what intermediate formats should exist and be persistent or temporal.

That tools within the chain be more effective/consistent about the forms they can import, export and edit, so that content doesn't have to be held in multiple forms.