Does anyone here work on Superslicer?

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

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