MicroPython Access Of fmt2rgb888 Convert JPG To RGB

[PsuFan]

Can someone help me with getting this working, not well versed in the esp-idf c world. I'm sure its a simple fix. I allocated the destination bytearray in micropython and can call the function successfully but the buffer is getting de-allocated.

#include "img_converters.h"
#include "esp_jpg_decode.h"

static mp_obj_t rgb888(mp_obj_t src_obj, mp_obj_t len_obj, void *dest_obj) {
	uint8_t *src = MP_OBJ_TO_PTR(src_obj);
	int src_len = mp_obj_get_int(len_obj);
	//uint8_t * _rgb888 = (uint8_t *) m_malloc(3*480*320);
	
	if (fmt2rgb888(src, src_len, PIXFORMAT_JPEG, dest_obj)) {
		//return MP_OBJ_FROM_PTR(_rgb888);
		return mp_obj_new_bool(1);
	} else {
		return mp_obj_new_bool(0);
	}
}

f = open('land.jpg','rb')
jpg = f.read()
f.close()
from imageconv import rgb888
rgb = bytearray(3*480*320)
rgb888(jpg, len(jpg), rgb) # True
rgb
NameError: name 'rgb' isn't defined

[jonnor]

That is not the correct way to access a bytearray. Neither for src_obj nor for dest_obj :D See https://github.com/orgs/micropython/discussions/16834 for some ways of doing it. The array carries its own length with it, so you just need mp_obj_t src_obj, mp_obj_t dest_obj

As you are onto here, it is much better to let the function take parameter also with the destinationn array (instead of doing malloc inside). That way allocations can be reused by the caller. And creating such objects is more practical in Python anyway.
You need to check that the buffer is of suitable size though (in addition to types).

I also think there is code for this transformation in https://github.com/cnadler86/micropython-camera-API

[cnadler86]

There is, but I'm getting rid of it in the camera API, because there are now better decoders out there and it's better to have a good one in a separate module

[cnadler86]

Use this Decoder: https://github.com/cnadler86/mp_jpeg

Much faster and already in Micropython. I suggest to download the firmware from the latest workflow

[cnadler86]

Here the issue I know that might be pointing out to your finding: espressif/esp32-camera#676

[PsuFan]

I've imported to pc and put a bmp header on it. It not only appears to have RB flipped, it is also flipped vertically AND horizontally... I assume someone did this on purpose for screen output because I had to modify a bunch of my startup commands to stop this screen and color flipping in the first place. I guess now I have to figure out if its easier to program the other things I want to display on the screen in this jacked format or if I want to try and change the code in the firmware to stop this... I guess I could loop through the bytes too and take the performance hit. (rotate=180 still results in a horizontally flipped image with RB flipped)

[cnadler86]

This is wierd.
I didn't notice anything with rgb565. Only if I use the wrong endian the colors are inverted in the display.

[PsuFan]

The display default startup params usually initialize it upside down like that though. 0,0 is in the upper right portrait mode

[PsuFan]

UGH nevermind, please ignore me. Bitmap format must not be straight forward rgb,rgb,rgb. Looking at the output binary, it is in the correct order. My screens bit order must be all screwed up to load bmp properly. I dont need to draw bmp anymore so I will go back to stock and that will fix all my issues.

[jonnor]

Most cameras have the ability to flip vertical and/or horizontal (alone with rotation), typically configurable via som registers. Because cameras are mounted in all kinds of ways. That would be much more efficient than flipping back in the application.

[cnadler86]

That's right. 🙂

By the way: the decoder is possibly now the better approach for emlearn, or?

[jonnor]

Yes, having the decoder separate is super! Then one can use it to load JPGs from disk, for running validation on a known dataset, for example :)