Prusa-Link-Web
Prusa-Link-Web copied to clipboard
Thumbnail generation not parsed by PrusaLink
Description of the bug
I am using PrusaSlicer 2.7.1 on the default mk4/IS printer profile and I am finding the thumbnails for the slices I generate are not being interpreted. By PrusaLink. I cannot be sure it was rendered on the printer's screen, I'll have to check on the next print. (PrusaConnect can parse the thumbnail correctly).
This is a single colour print, using the 'Generic PETG' profile output to a text gcode file.
I had a look through the gcode and compared a couple of files, one with thumbnails that render and one with thumbnails that do not render. The similarities are that thumbnails exist on both files. The differences are that the ones that work were generated by PrusaSlicer 2.7.0 and have one less tn format:
PrusaSlicer 2.7.0 - thumbnails render correctly:
$ cat Temperature-Tower_220-265_0.4n_0.2mm_PETG_MK4IS_1h39m.gcode | grep -i thumbnail
; thumbnail_QOI begin 16x16 644
; thumbnail_QOI end
; thumbnail_QOI begin 313x173 57800
; thumbnail_QOI end
; thumbnail_QOI begin 440x240 94000
; thumbnail_QOI end
; thumbnail begin 640x480 162688
; thumbnail end
; thumbnails = 16x16/QOI, 313x173/QOI, 440x240/QOI, 640x480/PNG
; thumbnails_format = PNG
PrusaSlicer 2.7.1 - thumbnails not rendering
$ cat Temp_Tower_PETG_0.4n_0.2mm_PETG_MK4IS_1h59m.gcode | grep -i thumbnail
; thumbnail_QOI begin 16x16 752
; thumbnail_QOI end
; thumbnail_QOI begin 313x173 57992
; thumbnail_QOI end
; thumbnail_QOI begin 440x240 94964
; thumbnail_QOI end
; thumbnail_QOI begin 480x240 101120
; thumbnail_QOI end
; thumbnail begin 640x480 165328
; thumbnail end
; thumbnails = 16x16/QOI, 313x173/QOI, 440x240/QOI, 480x240/QOI, 640x480/PNG
; thumbnails_format = PNG
Notice the latter has 5 thumbnail images in different resolutions, whereas the former (the one that works) has 4 - it is missing 480x240/QOI. But this does not appear to be the problem, because I removed this thumbnail from the gcode, changed the thumbnails =
line and re-uploaded to PrusaLink; It still does not render.
Project file & How to reproduce
- Slice a .stl file using the default prusa mk4 IS profile under prusaslicer 2.7.1
- use single colour filament, generic PETG filament profile, output to ASCII gcode file
- Import into printer's SD card
- View in prusaLink -> thumbnail does not render
Checklist of files included above
- [x] Project file
- [X] Screenshot
Version of PrusaSlicer
2.7.1+linux-x64-GTK3-202312121425
Operating system
Linux Debian 12
Printer model
Prusa mk4 IS
gcode file with thumbnail not rendering attached for reference
The generated thumbnails that don't render on PrusaLink do render on the printer's screen.
I'm seeing this same problem as well.
I have experienced that .bgcode is not affected.
I was just playing around with it myself, and if you move the PNG thumbnail from the last one in the list to the first, the image loads correctly in PrusaLink.
So when I change G-code thumbnails
from this:
16x16/QOI, 313x173/QOI, 440x240/QOI, 480x240/QOI, 640x480/PNG
(which is the PS default for my MK4)
to this:
640x480/PNG, 16x16/QOI, 313x173/QOI, 440x240/QOI, 480x240/QOI
the image loads.
I think the problem is actually in Prusa-Firmware-Buddy
, since its the printer that is returning nothing to the PrusaLink client.
Digging through the code, the problem starts here:
https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/89985d82a48a41cf16732a2fa85c4855dc9ef637/lib/WUI/nhttp/gcode_preview.cpp#L56
And then AFAICT depending on if you have a binary g-code or a regular g-code file a different code path is followed (PlainGcodeReader::stream_thumbnail_start
or PrusaPackGcodeReader::stream_thumbnail_start
). This would be why the behavior is different depending which format is used.
As to why it works when moving the PNG thumbnail to the front of the list; it looks like there is a limit to the number of lines searched for a PNG thumbnail here:
https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/89985d82a48a41cf16732a2fa85c4855dc9ef637/src/common/gcode/gcode_reader.cpp#L152
So I guess someone will need to determine what they feel is the best way to evaluate the regular g-code for thumbnails. If the Prusa devs are okay with just increasing MAX_SEARCH_LINES
I'd be happy to submit a PR for that.