Does anyone here work on Superslicer?

bot

@resam The image data is 4 channel, yes. The PNG contains full transparency in part of it.

When I write a test QOI image from a thumbnail, the image is perfectly vieable in https://github.com/Tom94/tev

So, the problem doesn't seem to be the pixels. It seems to be the base64 encoding?

But also the last test might have been ruined by me trying to generate QOI only if RRF is selected.

bot

I have verified that everything works as intended, albeit the thumbnail is upside down! lol. Not sure why that is.

The branch has been updated to trigger QOI format only if RRF is selected as gcode flavor. Also, the thumbnail comment will indicate if it is QOI (but will remain unchanged if outputting PNG)

https://github.com/n8bot/PrusaSlicer/tree/n8-240-qoitest

; generated by PrusaSlicer 2.4.0+n8 on 2022-01-02 at 09:00:33 UTC


;
; QOI thumbnail begin 128x128 3024
; cW9pZgAAAIAAAACABAAAx/8UFBQg/42Njd//oaGh//9QUFB/AP3mJSQY/ygoKEAA0QwlJP+NjY3fDA
; Du/xkNByCeaf8AAAAA7gz/eXl5vyQlANX/FBQUIBjAJQDs/0ooFWD/xmw5//+SUCrf/1MuGH8A7CUk
; GP8oKChAANcMJST/jY2N3wwA6B3/lFErvzLA/qdcMMD/aDkenwDpDP95eXm/JAwA2yUkGCUA5v8xGw
; 5AMsIGwQH/PyISYADm/ygoKEAkwCUA3f8UFBQg/3l5eb8kJQDk/2M2HH8ywwbD/1MuGH8A5CUk/42N
; jd//FBQUIADfDCUkGP8oKChAAOAdMzLEBsQB/xULBiD/AAAAAOAM/42Njd8kJQDjDBjAJQDeMDLGBs
; UBPADeJSQY/ygoKEAA5QwlJP+NjY3fDADaHTMyxwbH/31FJL//FQsGIP8AAAAA2gz/eXl5vyT/ZWVl
; n/8AAAAA6f88PDxg/6Ghof8YJQDY/zEbDkAyyQbI/5JQKt//Uy4YfwDY/zw8PGD/oaGh/xj/KCgoQA
; Dr/xQUFCD/eXl5vyT/ZWVln/8AAAAA1jAyygbKPADV/xQUFCD/eXl5vyQMAO7/FBQUICUk/42Njd//
; PDw8YADSHf+tXjLfMssGywH/FQsGIP8AAAAA0v8oKChA/6Ghof/AJQDxDP+NjY3fJCUA0DAyzQbMAT
; wA0CUkGP8oKChAAPMMJST/jY2N3wwAzB0zMs4GzgH/FQsGIP8AAAAAzAz/eXl5vyQlAPf/KCgoQP+N
; jY3fwCUAyhky0AbPATwAyiUkGP8oKChAAPn/FBQUICUk/3l5eb//FBQUIADGHTMy0QbRPADHDP95eX
; m/JAwA/SUk/42Njd8lAMT/MRsOQBAy0gbSAf8qFwxAAMT/KCgoQCTAJQD9wf8UFBQg/42Njd8kJQDC
; MDLUBtMB/1MuGH8AwiUkGAwA/cMMJSQYDB0zMtUG1QH/FQsGIAwYJCX/AAAAAP3HDBj+m3lmMtcG1g
; H/pH5o/xj/KCgoQAD9yB0zMtgG2P99RSS//xULBiD/AAAAAP3H/zEbDkAy2gbZ/5JQKt//Uy4YfwD9
; xTAy2wbbPAD9wh0QMtwG3AH/FQsGIP8AAAAA/TAy3gbdATwA+h0zMt8G3wH/FQsGIP8AAAAA9/8xGw
; 5AMuEG4AH/Uy4YfwD1/3xDJJ8y4gbiPADyHRAy4wbjAQUA7zAy5QbkATwA7B0zMuYG5gH/FQsGIP8A
; AAAA6Rky6AbnATwA5h0zMukG6f99RSS//xULBiD/AAAAAOP/MRsOQDLrBur/klAq3/8/IhJgAOEwMu
; wG7P9TLhh/AN4dMzLtBu0B/xULBiD/AAAAANswMu8G7gE8ANgdMzLwBvD/fUUkv/8VCwYg/wAAAADW
; MzLxBvEBANYzMvEG8QEA1jMy8QbxAQDWMzLxBvEBANYzMvEG8QEA1jMy8QbxAQDWMzLxBvEBANYzMv
; EG8QEA1jMy8QbxAQDWMzLxBvEBANYzMvEG8QEA1jMy8QbxAQDWMzLxBvEBANYzMvEG8QEA1jMy8Qbx
; AQDWMzLwopeYHAbwAQDWMzLufqOXoZjAGwbvAQDWMzLtoZijlzXCnWn+sGEzBu0BANYzMuwMNcUJGw
; bsAQDWMzLqOiM1yAn+rF8xBuoBANYzMukMNcsJGwbpAQDWMzLnOiM1zps6KwbnAQDWMzLmBDXRCRsG
; 5gEA1jMy5Qw11BsG5QEA1jMy4zotNdYJKwbjAQDWMzLiDDXZCRsG4gEA1jMy4DojNdwJKwbgAQDWMz
; LfBDXfCRsG3wEA1jMy3qOXNeKVDQbeAQDWMzLcOi015AkPBtwBANYzMtsMNecJGwbbAQDWMzLZOiM1
; 6gkrBtkBANYzMtgMNe0JGwbYAQDWMzLWOiM18CkrBtYBANYzMtUENfMJ/rVkNAbVAQDV/xQUFCD/qW
; U/3zLUopc19hsG1P+RWTjf/xQUFCAA0xgk/r15UzLSOiM1+AkrBtL+pW1M/42Njd8lANElJBgzMtGi
; lzX7CRsG0Q0YJCUAzv8UFBQgGCQlADMyzzojNf3AKSsGzwEMJSQY/ygoKEAAyyUk/42Njd//KCgoQA
; DAMzLOBDX9wwkbBs4BAMAM/42Njd/AJQDIDP95eXm/JP9lZWWf/wAAAADCMzLNopc1/cYbBs0BAMH/
; FBQUICUkGAwAxf88PDxg/6Ghof8Y/ygoKEAAwzMyyzotNf3ICQ8GywEAwyUk/42Njd8lAMIM/3l5eb
; 8kDADFMzLKopc1/csJGwbKAQDE/xQUFCD/eXl5vyT/ZWVln/8AAAAAwP8oKChAJMAlAMYzMsg6IzX9
; zgkrBsgBAMX/FBQUICUk/42Njd//KCgoQCT/jY2N3/8oKChAAMczMseilzX90QkbBscBAMf/FBQUIP
; +NjY3fJCUAyTMyxTojNf3UmCsGxgH/AAAAAMgMJQDKMzLEBDX91wkPBsQBANYzMsOilzX92QkbBsMB
; ANYzMsE6IzX93AkrBsEBANYzMsAMNf3fCRsGwAEA1jM6IzX94ikrAQDW/5ZSK781/eUJ/3dBIp8A1v
; 8aDgcg/2Y4Hn81/eT/mlUtvwDZETX94hEA2yX/s2M03zX93gn/MxwPQADdJRE1/dwRAOElCTX92AkO
; AOMlETX91icA5xE1/dQRAOklJzX90AklAOslETX9zhEA7yUJNf3KCQ4A8SURNf3I/4BHJZ8A9f9NKh
; ZgNf3FCQ4A9yUnNf3CJwD7ETX9wBEA/SUJNfoJDgD9wSURNfgRAP3FDgk19AkOAP3HJRE18icA/csR
; NfARAP3NJQk17AklAP3PJRE16hEA/dMlCTXmCQ4A/dUlETXkJwD92RE14QkzAP3bJSc13iclAP3dJR
; E13BEA/eElCTXYCQ4A/eMlETXWOwD95w4JNdIJDgD96SURNdAnAP3tETXOEQD97yUJNcoJDgD98SUR
; NcgRAP31JQk1xAkOAP33JRE1wicA/fsRNcARAP39JcAA/f39wwAAAAAAAAAB
; thumbnail end

results in

bot

as @resam pointed out to me, PrusaSlicer itself has to flip its pixels while encoding to PNG. I tried reversing the vector of pixels using std::reverse but that is not working.

So... for now the thumbnails are upside down! Lol. Sorry dc42.

@dc42 Here is a build of PrusaSlicer-n8 2.4.0 with the QOI image format enabled for RRF firmware, and upside-down thumbnail generation.

I've created an issue with QOI GH repo to ask/mention the idea of a flip image function on encode, so we can easily get our thumbnails the right way around!

Link to Win64 binary release: https://github.com/n8bot/PrusaSlicer/releases/download/version_2.4.0-release1-n8/PrusaSlicer-n8-2.4.0-QOIforRRFtest1-Win64.zip

dc42

@bot wow that was quick, I didn't expect anything so soon! Thanks!

Are the pixels encoded in the file top-to-bottom, or bottom-to-top? And within each row are they left-to-right?

bot

@dc42 According to the spec, they are encoded

/*
Images are encoded row by row, left to right, top to bottom. The decoder and
encoder start with {r: 0, g: 0, b: 0, a: 255} as the previous pixel value. An
image is complete when all pixels specified by width * height have been covered.

Pixels are encoded as
 - a run of the previous pixel
 - an index into an array of previously seen pixels
 - a difference to the previous pixel value in r,g,b
 - full r,g,b or r,g,b,a values
*/

It surprised me how fast it was, too! The library was basically a drop-in replacement with the PNG library.

I'm experimenting with ways to flip the pixels vertically before they are encoded to QOI, but it's proving difficult because of some weird pointer stuff. I suppose they appear upside down because of the way PrusaSlicer collects the pixel data into vectors. The PNG miniz library has a bool flag on the encode function to flip the pixels vertically.

[Edit: I was able to reverse the vector of pixels, which does flip the image vertically but it also seems to invert the colour or swap the channels around incorrectly. Further experimentation required.]

bot

Ok, I'm done!

Image is now flipped vertically, and the colours render correctly:

https://github.com/n8bot/PrusaSlicer/commit/821cbee27ce0a04d4dd86a9ce01a4fa271167236

Updated Win64 binaries: https://github.com/n8bot/PrusaSlicer/releases/download/version_2.4.0-release1-n8/PrusaSlicer-n8-2.4.0-QOIforRRFtest2-Win64.zip

Here are some web-based tools for testing:

Covnert Base64 to binary or hex: https://cryptii.com/pipes/base64-to-binary

Copy and Paste Hex data and save as file: https://hexed.it/

Drag and Drop saved QOI image viewer: https://floooh.github.io/qoiview/qoiview.html

0

n8bot committed to n8bot/PrusaSlicer

Flip vertically

resam

@dc42 now that we have shown this is feasible, a few more questions:

one image in a fixed resolution, or multiple: 32x32 + 64x64 + 128x128, ...?
square or same aspect ratios as the PanelDue: 1.6666 and 1.7647?
what about DWC? use the same embedded QOI, or upload a dedicated PNG next to the gcode file?

From the wiki I got these for PanelDue: 480×272 (4.3" displays) or 800×480 pixels (5" and 7" displays).

dc42

@resam @bot I suggest that for DWC we use QOI again. We may wish to support PNG in DWC too, however the headers for PNG and QOI encoding will allow DWC to identify which decoder to use.

I'll liaise with @chrishamm on what default thumbnail resolutions would suit both RRF and DWC. I presume you can pick up the required resolutions form the .ini file as is the case for PNG thumbnails. Maybe we should add an option to the Superslicer .ini file to specify the thumbnail image format?

bot

@dc42 Correct, the thumbnail resolutions are taken from the ini file, which is generated by the GUI.

If multiple resolutions are input, multiple thumbnails will be output to the gcode file. I assume the files do not need to conform to any aspect ratio, but I've only tested square power-of-2 sizes in width and height (just our of habit, I guess).

It would be possible to allow the user to select the format, but I know for sure that PrusaSlicer upstream will be reluctant to include changes to the GUI settings. Quietly choosing a new format for RRF will be more inline with their wishes, I imagine.

For SuperSlicer, @merill will decide what to do.

I have uploaded a universal macOS release that should work on intel and M1 macs alike, to broaden your potential testing base for this. Found here: https://github.com/n8bot/PrusaSlicer/releases/download/version_2.4.0-release1-n8/PrusaSlicer-n8-2.4.0-release1-macOS.dmg

Let me know if you'd like any changes.

bot

Discussing a few things with merill, I realize that we may want to simply output both PNG and QOI format when RRF is selected. Octoprint or other external services might still expect a PNG thumbnail. Outputting both should not break anything for anybody else, but provide the QOI for paneldue. I might output the QOI after the PNG in order to not mess with the expected location in the file of the thumbnail.

Any thoughts?

oliof

@bot that sounds nice and clean to me. The biggest risk is that other software picks up the QOI instead of PNG, but if that breaks them, well, they need to fix it anyways.

bot

@oliof yeah. I think that identifying the thumbnail as a "QOI thumbnail" at the beginning of the comment might be enough to stop any software from thinking it is a PNG thumbnail (if they use that string to detect the thumbnail)

But, also, placing it after all the PNG icons should at least give them the chance to gather the PNGs, too, and maybe error out on the QOI and hopefully retain the PNG.

oliof

yeah unless they're lazy and pick the last image comment block because obviously (-:

bot

@oliof lol that may very well actually be the case.

oliof

Only one way to find out (-:

resam

@bot let's make sure we keep in sync what SuperSlicer/PrusaSlicer and the Cura plugin are doing.

As long we are consistent, things work (or break) all in the same way.

bot

@resam Agreed!

dc42

@bot said in Does anyone here work on Superslicer?:

But, also, placing it after all the PNG icons should at least give them the chance to gather the PNGs, too, and maybe error out on the QOI and hopefully retain the PNG.

I would prefer it to be before the PNG image. For performance reasons, RRF only scans the first 20000 characters of the GCode file, and it may be that a large .PNG image would push the QOI image much later than that. If a user selects RRF when slicing, it's unlikely that they will be printing the resulting file on a machine that isn't running RRF.

bot

@dc42 sounds good to me. For now, I won't make any changes because it only outputs QOI. But in the near future, when we all settle on the agreed output, I'll make sure the QOI comes first if we also output PNG. And, at the point where we all are happy with how it works I'll submit the PR to Prusa for version 2.5.0.

Exerqtor

@bot Still in talks with merill about getting it into SS as soon as you have it working? Or are the plans to wait until it eventually gets onto PS stable?