We can move the PNGs to a single folder but the result images shall be stored in their own demo folder. So finally I would keep the PNGs and C together.

Would it be possible to make the converter script recursively traverse the demos and examples folders and convert all images starting with lv_demo_image_* or lv_example_image_*? It also not clear how to select the output color format. Maybe it can be indicated in the name as well. E.g.

lv_demo_image_..._argb8888.png; //convert to argb8888
lv_demo_image_..._rgb.png; //convert to LV_COLOR_FORMAT_NATIVE
lv_demo_image_..._argb.png; //convert to LV_COLOR_FORMAT_NATIVE_ALPHA

I need to mention that it will be a larger work to unify the names of all images but I can help with that.

We need some feedback on this issue.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

Not stale.

Needed by #5471

We need some feedback on this issue.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

Not stale.

We need some feedback on this issue.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

As there was no activity here for a while we close this issue. But don't worry, the conversation is still here and you can get back to it at any time.

So feel free to comment if you have remarks or ideas on this topic.

Can we reopen this issue? It has to be fixed.

It should be already added in #5608

OK, I see. This ticket is only about data_size field. I thought it will fix the stride too.
#4624 (comment)

E.G. all the images will need to be padded until stride is aligned to 64.

As they are right now upstream, all the assets (C array files) can not be processed by the GPU.

E.G. all the images will need to be padded until stride is aligned to 64.

It can be done in run time by calling image_decoder_open with args stride_align set.
See

bool lv_vg_lite_buffer_open_image(vg_lite_buffer_t * buffer, lv_image_decoder_dsc_t * decoder_dsc, const void * src,
                                  bool no_cache)
{
    LV_ASSERT_NULL(buffer);
    LV_ASSERT_NULL(decoder_dsc);
    LV_ASSERT_NULL(src);

    lv_image_decoder_args_t args;
    lv_memzero(&args, sizeof(lv_image_decoder_args_t));
    args.premultiply = !lv_vg_lite_support_blend_normal();
    args.stride_align = true;
    args.use_indexed = true;
    args.no_cache = no_cache;

Recomposing the image is inefficient.
You allocate another buffer where you copy the source image line by line and add the stride padding. It is resource consuming (CPU and memory).

My approach is that all image files (c array files) to be already aligned to a stride (we can chose 64 bytes to comply with any GPU) so that those images can be processed right away.
My suggestion is that all upstream demos/examples to use this kind of assets - c array files (aligned to stride 64 for all formats). We can do this by ourself and push the changes upstream overhere, just have to know what is the script who does the trick.

https://lvgl.io/tools/imageconverter_v9

Is it this one?
https://github.com/lvgl/lvgl/blob/master/scripts/LVGLImage.py

The clients are aware of the stride alignment requirements and they should pick images to satisfy this need.
@cristian-stoica @anaGrad

https://github.com/lvgl/lvgl/blob/master/scripts/LVGLImage.py

Yes, this is the script to generate images meet GPU, you need to specify the align parameter in command line.

My suggestion is that all upstream demos/examples to use this kind of assets

I haven't done this because for software renderer, alignment is not needed. For performance evaluation, we internally create real scene for them using correct aligned images.

We have as well internal images to test the GPU. But we want to have the possibility to run the benchmark out of the box. It should be doable.
We will create soon the PR with the new C array files updated.

#5925