Does anyone here work on Superslicer?

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

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