Does anyone here work on Superslicer?

[bot]

@dc42 Oh, I see thank you. Sorry for the confusion. What you posted is the response, giving the information about the thumbnails! Cool!

Also, while we can certainly ensure that QOI is generated for DWC, DWC can already use the PNG thumbnails, correct? It might be best to keep using the PNG thumbnails, and reserve the QOI thumbnails only for paneldue. That way, possibly, fewer added thumbnails need to be put into the gcode. It is up to you, though.

[bot]

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

To find the thumbnails I am looking for "; QOI thumbnail begin " and "; thumbnail begin" followed by the image size and data length values. Currently I assume the first one introduces a QOI thumbnail and the second one introduces a PNG thumbnail (which is of no use to the present PanelDue, but may be useful to DWC).

Yes. I added the QOI to the string for QOI thumbnails, while PNG thumbnails have the same string as before to not break any other software. If no "QOI" is present in that string, it's a PNG thumbnail.

[dc42]

@bot our plan is that DWC will support both PNG and QOI thumbnails, and PanelDue will support only QOI. If it turns out that PanelDue and DWC need the same size thumbnails then I suggest we generate just QOI. But if we need different sizes, then ideally we would want a way to specify for each thumbnail size which format to generate. Possibly in the .ini file line we could use 32x32 to mean PNG and 32q32 to mean QOI, or something like that.

[bot]

@dc42 That sounds good. Let me know what you decide and I will implement it.

In my opinion, upstream PrusaSlicer team will want as few changes as possible to the settings input. So, it might be a good idea to hardcode the image dimensions of the QOI thumbnail(s), and continue to allow the user to set PNG thumbnails as desired through the GUI/CLI settings.

The only downside to that, that I can see, is that if the user leaves the thumbnail field blank in the gui settings (meaning no thumbnails are requested), a QOI thumbnail would still be generated which might be against the user's wishes. (Or, conversely, if I don't code it correctly, it might generate no QOI thumbnail if no PNG dimensions are input by the user. Your suggestion of 32q32 may very well be the best way to approach this.)

I'm sorry that I'm kind of overthinking this and complicating the matter, but it might be a good time to finalize the behaviour so we don't have to think about it much again.

[one final edit: maybe it would be best to only generate qoi thumbnails with RRF selected. My idea of preserving the PNG thumbnails was only to benefit users of Octoprint, or the like... but are RRF users actually using octoprint? I see no reason to. Maybe we should just tear off the bandage straight-away and provide only QOI for RRF.]

[resam]

@bot @dc42 on the Cura side, I am in full control of the plugin and therefore the full slicer, so we have all the freedom and flexibility, but I would like us to try hard and keep feature parity with @bot 's work in PrusaSlicer (and others).

We could make a "thumbnail negotiation" between RRF and the slicer. The slicer could query any information from the printer and generate+assemble the perfect thumbnails (is PanelDue connected? which screen size is available? only DWC in PNG needed?) -- as compared to a static config in the Slicer that is unaware of what the printer is capable of.

[giostark]

OT/ team at work , such a nice reading /OT

[bot]

Just FYI for anyone interested, the Prusa Team seems to have taken over the development of this feature. They have already changed a couple things:

@dc42

The string to identify the thumbnail seems to have been changed to thumbnail_OQI

Also, there will now be an option in settings to select thumbnail format: PNG, JPG, and QOI. It won't be automatically selected for RRF (unless we intervene/request that change).

So, basically, it looks like this will make it into stock PrusaSlicer, but be aware of the possible changes.

https://github.com/prusa3d/PrusaSlicer/commit/87cff55856ae14096cd57f8e2542f1f1caef7167

9 bubnikv committed to prusa3d/PrusaSlicer

WIP: Implemented support for QOI G-code thumbnail format as requested
by the RepRapFirmware team due to their low RAM budget for decompression.
Bundled the QOI image compression library.

[dc42]

Coming soon to a PanelDue near you...

[medicusdkfz]

@dc42

Very cool! Then the investment in a 7-inch Due panel paid off after all...

[resam]

@dc42 quick check in to align:

• about image size and resolution: what did you settle with now?
• whats the expected header comment you want to parse? I think PrusaSlicer devs used a different format than our original proposal with @bot and my Cura plugin?
  • ; thumbnail_QOI begin 32x32 1234 vs.
  • ; QOI thumbnail begin 32x32 1234

[dc42]

@resam I think PrusaSlicer uses

thumbnail_QOI begin

so we'll look for that.

[resam]

@dc42 https://github.com/Duet3D/DuetSoftwareFramework/blob/75a1a4083062c6fbe0a5801685ab3371ede0b8b8/src/DuetControlServer/Files/ImageProcessing/PrusaSlicerImageParser.cs#L74 and https://github.com/Duet3D/RepRapFirmware/blob/5adb96401f7d8f6e79658ff8211a18785a73cb36/src/Storage/FileInfoParser.cpp#L977 tell two different stories for 3.4-rc1...

[dc42]

@resam thanks, we'll change DSF to use the new string too.

[dc42]

@resam is the Cura plugin for QOI thumbnail images available yet? If it is then I will mention it in 3.4.0rc1 release announcement.

[resam]

@dc42 could you test this generated file - to make sure it works, before I submit the plugin to Ultimaker for review: debug.gcode

I still don't know which image resolutions you want, so right now it contains:

• 64x64
• 128x128
• 160x160
• 256x256

Ultimaker Marketplace Review usually takes a few days, but you can alway install the plugin in manually with these instructions https://github.com/Kriechi/Cura-DuetRRFPlugin/#manual-installation
You can add that to the release announcement now.

[chrishamm]

@resam there's a problem with it, the start comment should be

; thumbnail_QOI begin

instead of

; thumbnail_OQI begin

and the end comment should read

; thumbnail end

instead of

; thumbnail_OQI end

Then it should work as expected.

[resam]

@chrishamm lol - yeah, good idea of mine to ask for a sanity check Thanks for catching that typo!

I'll ask again about resolutions: what do you want, or what can you/DCW/RRF/DSF handle? I read that PanelDue can do a max. of 160x160.

[dc42]

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

yeah, good idea of mine to ask for a sanity check Thanks for catching that typo!

Actually that typo was made by the devs of PrusaSlicer; but they later corrected it.

I don't have a latest build of PrusasSlicer, so I don't know whether they use thumbnail_end or thumbnail_QOI end.

[resam]

@dc42 indeed! https://github.com/prusa3d/PrusaSlicer/commit/086662b6a1c7d7a14e35a90e6d46445f6871ac24 fixes it - so I probably copy-pasted it.

The end tag is the same tag as the begin, so thumbail_QOI. See https://github.com/prusa3d/PrusaSlicer/commit/87cff55856ae14096cd57f8e2542f1f1caef7167#diff-e09699df9f3fa4c292ba50b9f88dffe95b2d2d5c0a58d9d81441f9da5031c97bR49

0 bubnikv committed to prusa3d/PrusaSlicer

Fixed typo in thumbnail_QOI tag.

9 bubnikv committed to prusa3d/PrusaSlicer

WIP: Implemented support for QOI G-code thumbnail format as requested
by the RepRapFirmware team due to their low RAM budget for decompression.
Bundled the QOI image compression library.

[dc42]

@resam thanks for that. We'll need to change RRF and probably DSF then.