Does anyone here work on Superslicer?

bot

@oliof no worries. The terminologies are used interchangeably in different contexts. It gets confusing.

Is there a standard PNG thumbnail size that you were referring to? I'm not aware of any standards. I forget what PrusaSlicer used by default for their mini printer. I think 64x64.

[edit: just checked. They generate two thumbnails: 16x16, 220x124]

dc42

@bot I have now extended the RRF M36 command and rr_fileinfo HTTP call to return info about what thumbnails are available in the GCode file being queried:

m36 "EscherLizardModified-petg-260-qoi.gcode"
{
    "err": 0,
    "size": 422665,
    "lastModified": "2022-01-04T16:51:58",
    "height": 5.15,
    "layerHeight": 0.3,
    "printTime": 997,
    "filament": [
        1498.3
    ],
    "thumbnails": [
        {
            "w": 32,
            "h": 32,
            "fmt": "qoi"
        },
        {
            "w": 220,
            "h": 220,
            "fmt": "qoi"
        }
    ],
    "generatedBy": "PrusaSlicer 2.4.0+n8 on 2022-01-04 at 16:51:59 UTC"
}

The next step is to add a new call to return the thumbnail data for a selected thumbnail.

For the PanelDue file info popup it looks like we will want a thumbnail about 200x200px. We'll know the exact size in a week or so. If we decide to display thumbnails in the file list too, then 32x32 will be about right for that.

If we extend thumbnail support to the 12864 display then we'll probably want 16x16 for the file list and 32x32 for a file info screen.

We've yet to determine whether the sizes we need for PanelDue will work well for DWC too.

bot

@dc42 be aware that the g-codes generated by my build have an added +n8 to the semver, which is actually accepted by proper semver parsing as no different than withoout the +n8 (for caompatibility within prusaslicer detecting profile versions),

I suggest we detect only up to any + symbol after the version number for the strings, otherwise this will not work if/when merged with stock PrusaSlicer. (Sorry if that's not what is happening in the code snippet you posted. I just figured it was worth mentioning that the generated by string is slightly changed in my build, but we should hope/expect these changes to land in stock prusaslicer)

dc42

@bot RRF doesn't use the semver for anything, so it doesn't matter. The "generatedBy" string reported by RRF is exactly as given in the comment read from the file, which in this case is the first line of the file:

; generated by PrusaSlicer 2.4.0+n8 on 2022-01-04 at 16:51:59 UTC

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).

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...
2022-02-03 14.57.25.jpg

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.