CPython: JPEG images can't be scaled (LVGL TJPGD decodes tiles; MicroPython's jpegio can)

[bdbarnett]

On CPython, a JPEG in an lv.image can't be scaled. set_inner_align(lv.image.ALIGN.CONTAIN) draws a garbled partial crop, and set_scale() draws nothing. On MicroPython the same code scales correctly, because the decoder there is displayif's jpegio. So the same app renders differently on the two.

Repro: a 64×64 Spotify JPEG drawn three ways, with the same script on both interpreters.

img = lv.image(scr)
img.set_src(dsc)                               # dsc: lv.image_dsc_t, cf RAW, the JPEG bytes
img.set_size(40, 40); img.set_inner_align(lv.image.ALIGN.CONTAIN)   # or: img.set_scale(160)

	native 64 px	CONTAIN in 40 px	set_scale(160)
MicroPython (jpegio)	correct	correct	correct
CPython 9.5.45 (LVGL TJPGD)	correct	garbled partial crop	nothing drawn

Why

lv_conf.h keeps LV_USE_TJPGD 1 on CPython ("CPython has no jpegio, so LVGL's built-in decoder stays"). LVGL's lv_tjpgd.c decodes tile by tile, and LVGL can't apply a transform to an image that never exists as one whole decoded buffer. jpegio's LVGL decoder decodes the full image in its open step (w * h * 2, freed at close), so zoom and CONTAIN work on MicroPython.

How it showed up

A Spotify remote app draws list-row thumbnails from Spotify's smallest (64 px) image, scaled to 40 px. On MicroPython they look right. On CPython every thumbnail is a mangled crop, so for now the app turns thumbnails off when the decoder isn't jpegio.

Options

• Build jpegio's LVGL decoder (displayif src/jpegio/lvgl_decoder.c plus its TJpgDec) into the CPython extension in place of LVGL's TJPGD. That gives one decoder with the same behaviour on every target, which is what the lvgl-bindings#14 / displayif#23 note in lv_conf.h is aiming for.
• Or document on the CPython side that JPEG images can't be transformed, so apps know to pick a size that needs no scaling.

[bdbarnett]

I looked at this unattended. It needs one decision from you, so this is a write-up and not a PR.

Short version: The fix is to build jpegio's LVGL decoder into the CPython extension, as the issue's first option says. I prototyped it and the output is byte-identical to MicroPython's. No LVGL setting fixes it. The one open question is how lvgl-python gets displayif's decoder source. I recommend a pinned sync from displayif, the same pattern as LVGL_BINDINGS_COMMIT.

What I checked

I reproduced it on pydevices-lvgl 9.5.45. I drew a 64×64 JPEG (four coloured quadrants and a white disc) native, CONTAIN in 40 px, and set_scale(160), and compared each frame with Pillow's resize of the same image:

	native	CONTAIN 40	scale 160
MicroPython unix (jpegio)	err 0.4	err 2.9	err 2.9
CPython 9.5.45 (LVGL TJPGD)	err 0.4	err 78.9, unscaled top-left crop	err 78.9, same crop
CPython prototype (jpegio's decoder)	err 0.4	err 2.9	err 2.9

(err is the mean absolute difference per channel.) All three prototype frames are byte-identical to MicroPython's.

The cause is as the issue says. When a decoder only offers get_area, img_decode_and_draw in lvgl/src/draw/lv_draw_image.c takes its "Draw in smaller pieces" branch (line 362) and draws each tile untransformed. Only the "whole image is available" branch (line 358) can scale.

No LVGL setting helps. LV_USE_TJPGD has no full-frame mode, and LV_USE_LIBJPEG_TURBO would make every wheel (Windows, macOS, Pyodide) depend on libjpeg-turbo.

The prototype

I built this locally and didn't commit it:

• In lv_conf.h, LV_USE_TJPGD 0 under LV_CPYTHON_BUILD. PYCPARSER keeps 1.
• displayif's src/jpegio/lvgl_decoder.c and tjpgd/ added to setup.py's sources, unchanged.
• jpegio_lvgl_decoder_register() called right after lv_init() in py_lvgl_init.

The smoke test and lvgl-python's unit tests pass on it. The first build failed as expected: the generated code still wraps lv_tjpgd_init/lv_tjpgd_deinit.

What a real fix needs

1. lvgl-bindings. Turn TJPGD off for CPython in lv_conf.h. Add cpython to the four lv_tjpgd_* target_exceptions in binding/api_policy.json and to RUNTIME_SKIP_MODULE_FUNCS in binding/runtime_exports.py. Have the generated py_lvgl_init call a hook after lv_init(), for example lvpy_after_lv_init() in lvpy_runtime.h, so a consumer can register decoders. (MicroPython doesn't need this, because there jpegio's __init__ does the registering.)
2. lvgl-python. Implement the hook and compile the decoder into the extension. This is where the decision is.

The decision: where lvgl-python gets the decoder source

• A (recommended). A pinned sync from displayif. scripts/sync_from_displayif.sh --ref <sha> copies lvgl_decoder.{c,h} and tjpgd/ into src/jpegio/, and a DISPLAYIF_COMMIT file records the SHA, just as LVGL_BINDINGS_COMMIT does. setup.py refuses to build without the pin. There's one decoder with one owner, so the same image renders the same on every interpreter. That's what the lv_conf.h note about displayif#23 and lvgl-bindings#14 is aiming for. The cost is a second upstream in lvgl-python's release chain.
• B. Vendor it into lvgl-bindings, so lvgl-python keeps one sync source. That's simpler for lvgl-python, but the file then has two writers: displayif for MicroPython and lvgl-bindings for CPython. That's the drift the single-writer rule exists to prevent.
• C. lvgl-python writes its own full-frame decoder on LVGL's bundled TJpgDec (RGB888), and TJPGD stays on. There's no new dependency, but it's a second decoder whose behaviour can drift from jpegio's, and it still needs the hook from step 1.
• D. Document it only. On CPython, JPEG images can't be transformed.

Say which (A unless you prefer otherwise) and I'll do the lvgl-bindings PR and then the lvgl-python sync PR. The lvgl-python PR can only pin a merged bindings commit.

Found on the way and filed separately: on CPython, lv.image_dsc_t({"header": {...}}) segfaults (lvgl-bindings#21).