How to Scale/Rotate image from flash memory?

Anda · December 30, 2019, 11:55am

Hi

I store the image resources in SPI FLASH, and then I want to achieve image scaling and rotation.
From the source code, I can do this in the form of a code file(e.g. test_img.c),
and IMG_SRC_TYPE is LV_IMG_SRC_VARIABLE.

So I wonder if there is a better way to achieve this?

Thanks in advance!

Best regards.

embeddedt · December 30, 2019, 4:16pm

If you are using C files created using the image converter, and your SPI flash is directly addressable, I suggest modifying this line and adding a section attribute to place the bitmap data into SPI flash. This is the easiest solution but it only works if SPI flash can be addressed the same way as normal flash/RAM.

If flash is not directly addressable, you would have to:

Manually store the bitmap data in SPI flash using whatever tool you have available.
When you want to display an image, read the bitmap data from SPI flash into RAM.
Fabricate this structure and set the data member to point to wherever the bitmap data is in RAM.

Anda · December 31, 2019, 2:22am

Thanks for your reply. I know how to read data directly from FLASH to RAM, but many pictures are larger in size and there is no larger RAM space to store the complete picture content, so I wonder if it can be processed in parts.

embeddedt · December 31, 2019, 2:01pm

As far as I know, built-in images have to be read in their entirety into some type of addressable memory before it can be drawn.

I’m thinking about it some more. I don’t think anyone has ever tried this before, but you should be able to (ab)use the image decoder interface to force LittlevGL to read line by line from the image. https://docs.littlevgl.com/en/html/overview/image.html#_CPPv428lv_img_decoder_read_line_f_t

The image decoder is designed to handle external image formats like PNG or JPEG, but it should also work with a built-in image. As you can see in the source code, it will only allocate a line-sized buffer in RAM when drawing in line-by-line mode.

There will definitely be a performance penalty to doing it this way because the image can only be flushed one line at a time, but it should cost you less RAM.

kisvegabor · January 2, 2020, 9:00am

Unfortunately, zoom and rotate requires the whole image. The reason: imagine that lvgl draws x=10, y=20 pixel of the image. The image is rotated and zoom, so for (10;20) e.g. (87,33) should be drawn. But if only y = 20 line is available lvgl can’t get (87, 33).

A corner case is when rotate = 90° so the line becomes columns. When lvgl draws the pixels of a line (x, x+1, x+2, …) different lines will be required for each pixel (y, y+1, y+2).

Anda · January 2, 2020, 9:16am

Thansk for your reply.
I know that we can use lv_img_decoder_read_line to get the graphic content of SPI FLASH, but this method cannot be directly applied to image scaling and rotation.

Anda · January 2, 2020, 9:19am

Yes, I think so too, I’m seeing if there is a better way to deal with this, or can do this, read a part from SPI FLASH into RAM, and then do the calculation processing.

kisvegabor · January 4, 2020, 10:57pm

The problem is that is that it works the opposite way: NOT read a (random) part, transform it and draw it where required, but to draw an area, get the required image, transform it, and draw it to the current area to draw.

To make it possible a 3rd option should be added here:

github.com

littlevgl/lvgl/blob/dev-7.0/src/lv_draw/lv_img_buf.c#L472-L475


pxi = 0; /*unused*/
px_size = 0;    /*unused*/
dsc->res.color = lv_img_buf_get_px_color(&dsc->tmp.img_dsc, xs_int, ys_int, dsc->cfg.color);
dsc->res.opa = lv_img_buf_get_px_alpha(&dsc->tmp.img_dsc, xs_int, ys_int);

Besides native (RGB) and fully buffered non-native images, there could be an option to get the required pixels on demand. However, I’m afraid it’d be very slow especially for large images.

Anda · January 6, 2020, 3:37am

Thank you very much for your explanation, I understand this more.

For rorating the image using point-by-point reading(from SPI FLASH), we can imagine that it’d very slow, this method is not used in general.

Because rotating an image requires processing pixels with random coords, so this is not conducive to process in parts.

For scaling the image, I think the image content can to be loaded relatively easy, and this is conducive to process in parts.

That’s my point. I also look forward to your point.

kisvegabor · January 11, 2020, 11:15am

Hmm, it would be really much easier for scaling because rows remain rows.
So someone needs to immerse in how/where to tell which rows to get for the scaled image.
It should be somewhere here:

github.com

littlevgl/lvgl/blob/00ba66534dd900ed2e57fedfbfbfbe8f7b000439/src/lv_draw/lv_draw_img.c#L274-L310


lv_area_t mask_com; /*Common area of mask and coords*/
bool union_ok;
union_ok = lv_area_intersect(&mask_com, mask, coords);
if(union_ok == false) {
    return LV_RES_OK; /*Out of mask. There is nothing to draw so the image is drawn
                         successfully.*/
}


lv_coord_t width = lv_area_get_width(&mask_com);


uint8_t  * buf = lv_mem_buf_get(lv_area_get_width(&mask_com) * LV_IMG_PX_SIZE_ALPHA_BYTE);  /*+1 because of the possible alpha byte*/


lv_area_t line;
lv_area_copy(&line, &mask_com);
lv_area_set_height(&line, 1);
lv_coord_t x = mask_com.x1 - coords->x1;
lv_coord_t y = mask_com.y1 - coords->y1;
lv_coord_t row;
lv_res_t read_res;
for(row = mask_com.y1; row <= mask_com.y2; row++) {

This file has been truncated. show original

If you are interested in dealing with it, please open an issue in GitHub to discuss it in more detail.

Anda · January 13, 2020, 6:45am

I think we can try this method and it should work.

jakkra · July 20, 2024, 10:07pm

Hi, just checking in if this is still not possible. And what the current suggested approach is.
Is it to store the image in filesystem, but in the c array way and cast this data to a lv_image_dsc_t?
How do I know when I can again free up this RAM? A deleted event on the image?