Does anyone here work on Superslicer?

[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?

[bot]

@exerqtor I know merill is very pre-occupied with merging 2.4.0 into SuSi, so I will not continue bugging him until we at least get the behaviour sorted.

@resam and I were talking about it, and we realized that the thumbnail dimensions should probably be fixed for RRF, so that a user doesn't accidentally set a size that can not be displayed well on the various sizes of paneldue. So, I suppose, we should hard-code the approriate number of resolutions to encode the QOI thumbnails.

@dc42 any thoughts as to the sepcific width and height dimensions needed for the various paneldue sizes? Multiple thumbnail sizes can be embedded into a single g-code file, so we could output multiple sizes for the different screen sizes. But this brings us closer to the possibility of surpassing that 2000 character limit.

So, instead, maybe we should choose one single thumbnail size that will work for all paneldue sizes, and only embed that qoi thumbnail.

If we choose to embed multiple sizes of QOI thumbnails for the different paneldue sizes, we could move the thumbnails to the very beginning of the g-code file to get as many of those 2000 characters as we can. But that might push some other useful information past 2000 characters, so we should be careful.

[oliof]

what's the standard PNG resolution? maybe just match that.

[bot]

@oliof I'm not sure what you mean. I'm not talking about the pixels per inch of screen space (usually 72 dpi). I'm talking about like 128x128 pixels, or 256x256 or whatever. Those specific number of pixels will need to be suitable to be displayed on the various sizes of paneldue.

PS currently allows the user to generate any arbitrary number of thumbnails, at any arbitrary dimension. This might not lead to desirable results for the paneldue. So, I'm suggesting that for the QOI thumbnails, we hard-code the dimensions.

Or, we could provide very strong suggestions to the user in documentation, and in user/print profiles.

[oliof]

@bot sorry, I meant the size of the PNG preview image.

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