Display preview images from Prusaslicer gcode

[gdachs]

It is nice that OctoDash displays preview images from .ufp files, but I prefer Prusaslicer. Prusaslicer from version 2.2 up generates preview images for the Prusa Mini. But if you change with a text editor the line thumbnails = to thumbnails = 16x16,220x124 in the printer settings file, then you get the same images in the gcode file for every printer. I just tested it. It looks like the images are uuencoded.
Would it be possible to show this images just like the ones from the .ufp files?

[UnchartedBull]

If there is an URL to access those images these can be embedded in OctoDash for sure. I don't have any experience with PrusaSlicer, so I can't really test that. If you want to open a PR for that, here is the one that was done for UFP: https://github.com/UnchartedBull/OctoDash/pull/464/files. If you go with the same path as described there it should work.

[thegarbz]

I may see if I can help you with this. This new plugin was published today: https://plugins.octoprint.org/plugins/prusaslicerthumbnails/?utm_medium=announcements&utm_source=octoprint&utm_content=1.4.0 which means Octopi does have thumbnails available from Prusaslicer somewhere.

[thegarbz]

@UnchartedBull Looking at the pull request you linked to the data file appears to be directly identified by .upf.gcode. PrusaSlicer doesn't have such a unique standard way of identifying an image. So what's the best way forward in this project? Do you specifically add instructions for all gcode files to have a certain name e.g. .prusa.gcode? Then you could just add the following:
thumbnail: data.path.endsWith('.prusa.gcode') ? this.configService.getURL('plugin/prusaslicerthumbnails/thumbnail/').replace('/api/', '/') + data.path.replace('.gcode', '.png') : undefined,

That is if I understand what your code is doing correctly (n00b here, sorry).

But then you'd also need to update the manual to include instructions on naming the file. A better way may be to look in the gcode for "; thumbnail begin" lines. But I'm out of my depth there.

[UnchartedBull]

Yes currently the plugin just checks, whether the file ends with .ufp.gcode, which makes this quite easy and fast.

It isn't really feasible to check the gcode, since the Pi would need to download each GCode file and check it, which will make loading files even slower and will really stress that little poor CPU.

So there are now two options:

1. Go with the .prusa.gcode approach (I don't know if there is an option to do this automatically with Prusa). Definitely not ideal though, but it will work. The code snippet you posted should work, although there also needs to be the check against .ufp.gcode. This also implies that the plugin actually offers the image via an API.
2. Talk to the plugin owner and figure out a way with him to integrate a flag or something, that will be sent in the default files list from OctoPrint (probably the cleaner approach).

Which way would you prefer?

[thegarbz]

@UnchartedBull Prefer? None. I'm not a programmer, so whatever is easiest for you and works would be the ultimate goal :-)

One thing I did think of, could you parse the directory where the thumbnails are? You obviously have access to it since you need to display it, but your UI could (and this applies to the Ultimaker files too):

1. File accessed is is foo.gcode
2. If plugin/prusaslicerthumbnails/thumbnail/foo.png exists, set thumbnail to that
3. elseif plugin/UltimakerFormatPackage/thumbnail/foo.png exists, set thumbnail to that
4. else set thumbnail to none.

This method would be filename independent and sort of plugin independent as you could just search the directories and load the matching file if you find one, as you know what you're looking for you don't need to parse them all.

I'm not sure if this works with the ufp plugin, but it would definitely work with how prusaslicerthumbnails works since it parses and extracts the thumbnail from the gcode file on first upload.

[thegarbz]

This may get even easier. PrusaSlicerThumbnails now has support for Ultimaker thumbnails as well according to the release:
https://github.com/jneilliii/OctoPrint-PrusaSlicerThumbnails/releases

So one plugin looks like it extracts and handles thumbnails from both gcode files, and does so in the same way.

The pseudocode would now literally be:

1. File accessed is is foo.gcode
2. If plugin/prusaslicerthumbnails/thumbnail/foo.png exists, set thumbnail to that
   3. elseif plugin/UltimakerFormatPackage/thumbnail/foo.png exists, set thumbnail to that
3. else set thumbnail to none.

[UnchartedBull]

That is great. Maybe @jneilliii can chime in here. I think you're the original PR creator (and creator of the plugins). Would there be any downside in dropping the UFPFormatter and only relying on the PrusaSlicer Thumbnails?

[jneilliii]

@UnchartedBull, both plugins now store the url for the thumbnail in a thumbnail field inside the metadata. That field gets returned by the api file details, but I'm not sure it gets returned by the current job api so you could only use it in the file listing, but not the current printing state view.

[UnchartedBull]

The Job Service actually uses the File API to get the thumbnail, so that is already implemented :) I might switch that around soonish. Thanks for the quick response!

[jneilliii]

Here's a screenshot of showing the field returned by the files api. The property is thumbnail for both plugins now.

[jneilliii]

I just submitted a PR that should support the latest versions of both plugins.