Using CLI to generate gcode files does not create embedded thumbnails

[jwkicklighter]

Version

Version 2.4.0+arm64

Operating system type + version

• MacOS 11.2.3
• Mac Mini (M1, 2020)

3D printer brand / version + firmware version (if known)

Original Prusa i3 MK3S+ (firmware version not applicable to problem)

Behavior

1. Modify the MK3S profile to include thumbnail support
2. Generate a gcode file
3. Inspect the gcode file, there will be a thumbnail section
4. Export the config that was just used
5. With the CLI, use the config that was just exported to slice the same file
6. Inspect the gcode file, there will not be a thumbnail section

Project File (.3MF) where problem occurs

This is repeatable across any 3MF/STL that I have tried.

[neophyl]

Doesn’t it use the gui to create the embedded thumbnail ? If it’s not running the gui then ….

[jwkicklighter]

@neophyl honestly I have no idea how it works at the technical level. I didn't think that the UI was used because the thumbnail is always from the same perspective/zoom regardless of the UI view. But if that's the case, it seems like a headless renderer could be started up to generate the image data.

At a minimum, this should be documented as not being supported. I'm hoping that it can actually be enabled, though.

[jwkicklighter]

After further investigating, the CLI help actually says that this option is supported when using --help--fff:

--thumbnails        Picture sizes to be stored into a .gcode and .sl1 / .sl1s files, in the
                    following format: "XxY, XxY, ..." (default: )

I have tried to supply the thumbnail config as an argument to the CLI rather than just in the config .ini file, but it also does not work. Perhaps notable, the comment at the bottom of the generated .gcode file does show the thumbnails option as I have it configured:

; thumbnails = 16x16,220x124

I also tried using the --single-instance flag while already having a GUI window open, but this did nothing.

[bubnikv]

The command line slicer does NOT support thumbnails. The thumbnails are generated by the same OpenGL context that the 3D scene is rendered with. There is no OpenGL context available as of now in command line slicer, thus there are no thumbnails. We should remove the --thumbnails option from CLI, it is generated automatically. út 8. 2. 2022 v 18:17 odesílatel Jordan Kicklighter < ***@***.***> napsal:

…

After further investigating, the CLI help actually says that this option is supported when using --help--fff: --thumbnails Picture sizes to be stored into a .gcode and .sl1 / .sl1s files, in the following format: "XxY, XxY, ..." (default: ) I have tried to supply the thumbnail config as an argument to the CLI rather than just in the config .ini file, but it also does not work. Perhaps notable, the comment at the bottom of the generated .gcode file *does* show the thumbnails option as I have it configured: ; thumbnails = 16x16,220x124 — Reply to this email directly, view it on GitHub <#7878 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMPSI4D42XMBZSOO7KXGPDU2FF4LANCNFSM5NSZLPJA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jwkicklighter]

@bubnikv Would there be any way to use an already-running GUI process to render the thumbnail when using the CLI? For my needs, I'm using the CLI for automation purposes (not having to manually slice hundreds of files) so a speed decrease would not matter. I think it would be reasonable that someone wanting to generate thumbnails would expect it to take longer to process each file.

[bubnikv]

It is doable, but it does not fit the current architecture. It would require quite a lot of code and we have higher priority tasks. čt 10. 2. 2022 v 20:02 odesílatel Jordan Kicklighter < ***@***.***> napsal:

…

@bubnikv <https://github.com/bubnikv> Would there be any way to use an already-running GUI process to render the thumbnail when using the CLI? For my needs, I'm using the CLI for automation purposes (not having to manually slice hundreds of files) so a speed decrease would not matter. I think it would be reasonable that someone wanting to generate thumbnails would expect it to take longer to process each file. — Reply to this email directly, view it on GitHub <#7878 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMPSIYZQHWJ3PJEIVYGBSDU2QDV5ANCNFSM5NSZLPJA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[jwkicklighter]

@bubnikv Understandable, thank you for the info

[Torrax]

I also think this would be an awesome addition. Maybe to mark as a feature request to look at some point in the future if time permits?

[TomasHubelbauer]

I'm looking for the same thing but not for GCode but for the 3MF. The GUI export does include Metadata/thumbnail.png in the 3MF, the CLI export doesn't. CLI command I used is in #8492.

[jkavalik]

What about implementing some simple software rasterizer instead, so OpenGL is not needed at all? It could do useful low-res thumbnails well enough. I was checking some possibilities and found https://github.com/aslze/minirender as an example.

[demonlibra]

I hope the author will continue to develop the functionality of the project minirender.
Also I using project stl-thumb.

[jimb15122]

Suggestion: since the thumbnail is just a folder with a few png's in it, how about adding a CLI option to specify a LAYER to use as the thumbnail. eg: --thumbnail-layer=125. I could care less about the 3d perspective. I just need to verify that I opened the right file before starting the print. The doc for this option could also explain that normal thumbnails are not supported.

[jimb15122]

UvTools version 3.8.2 provides a workaround for the missing thumbnails. You can set the thumbnail to any specified layer or to the heatmap (avg pixel shade of all layers), or to a specified image file. This is available from both the GUI and CLI versions.

e.g. to set the thumbnail to layer 50, use:
UvToolsCmd.exe set-thumbnail my.sl1 50

See UvTools issue # 599 for details.

[jkavalik]

That sounds nice for SLA printers but won't work for FDM gcode files afaik.

[wolfallein]

I also think that a thumbnail in the CLI version is very useful, I hope it can be integrated in the future.

I didn't know it relies on a screenshot from the GUI.

[nat-a-cyborg]

What would be awesome is if we could pass our own thumbnail image. I'd honestly do this instead of the automatic thumbnails. I'll post back here if I implement this.

[martinbilek]

We have implemented high quality gcode preview generator in Karmen3D. You can see some previews for example here:
https://karmen.tech/en/groups/fragariacz-inqp39rw

Gcode preview images are generated from multiple angles for every uploaded gcode.

[Maxime-JULLIEN]

It could be cool to allow the cli to generate thumbnails. It's really important.