Allow more formats of G-Code Thumbnails as Prusa Slicer #1894
Comments
|
I would like the QIDI thumbnail option. |
|
Would be very nice if we could get this format BIQU tumbnail supported as well. @effgarces maintains a python script (Biqu-Thumbnail-Generator) to achieve that. But unfortunately the resulting pics are only about 1/2 of the size compared to the thumbnails generated by the Cura plugin. Cura Plugin@effgarces python scriptThere has been a lot going on regarding this topic for the most part in SuperSlicer: Maybe someone could finally get this going by implementing it in the best slicer ever. 😊 |
|
@discip I'm assuming you have one of the BTT since you are requesting it. If you had a moment and wouldn't mind trying some g-code for me, that would be nice. I have an implementation thrown together, but the output is not identical (just seems like the coloring is different, but this could be because I am going directly from the raw RGBA values rather than RGBA >> PNG >> BTT format). This format also includes all sizes that the original BTT plugin does. |
|
@frasier2k I have also implemented the option to choose the format to save in as well as adding JPG and QOI formats. I am waiting to see if the BTT format works so I can merge them all together |
|
Hmm. That's no good. Looking at superslicer, there is an implementation in there. Have you tried that implantation recently? |
|
Good evening, sir,
I'm so happy that someone is finally taking care of this! THANK YOU SO VERY MUCH! 😃👍🎉
I'm willing to help where ever I can.
Unfortunately I only have these 2 TFTs. I'm excited to see how this will turn out in the end. Thank you! |
|
Also, after looking through the cura plugin a bit, it seems that what resizes the view of the picture is cura, not the plugin. |
thanks in advance |
|
update: Today I got the chance to test your code on my TFT28 and for some reason on that one it works. |
|
|
|
im also going to throw this here for reference - from BTT firmware repo |
|
My idea was to test if it will work when the actual object reaches up to the borders, like in the example I initially provided. |
|
One more thought about the size.
If so, is it possible to change the size for the preview? I'm pretty sure others would benefit from a bigger preview as well. 😁
|
|
ok. i am taking a different approach and looking into the source code of the tft itself and seeing how it converts the code and I found the function it uses. Now going to look into how it loads the image data. |
|
So just to confirm, if you take a gcode file with png and run it through the converter you provided, it does work right? In the code, I am seeing references to it looking for a header following the pattern "; bigtreetech thumbnail begin <>x<>" but the cura plugin does not seem to do that |
|
I am only using it within Orca as a post processor. |
|
that is fine. but it is working right? |
|
Yes it is, for both the MKS28 & TFT43. |
|
it seems as there is a certain memory offset that it seeks to if it does not find the header specified above. Im going to try and hack this together and see if I can get it working. also, now knowing that it is a memory offset, that also means that how newlines are created is important and should be identical |
|
Could you provide me with the |
|
yeah, it is the primitive cube in orca. just right click on the plate and select add |
|
You seem to be right about the offset, at least that is what I think, because depending on which resolution your TFT needs, which in turn is arranged the way you listed it above, it needs all the resolution prior to that to work. As mentioned above:
|
|
Color of the cube is 255, 128, 64 (r, g, b) And I also have another one to try: |
|
There is something really strange going on! |
|
Was this while trying the one I just sent? |
|
I just retested and it worked with your newly sent code. |
|
WOOOOOHOOOOOO! |
|
Cube_PLA_25m57s.zip |
|
Unfortunately this does for what ever reason not work! 😭 |
|
🤦 |
|
So I tried further and noticed, that If you slice the file with the post processor enabled and than replace the blocks of code representing the thumbnail with your code even with the 1st one you sent, it works! 🤷🏻♂️
Will do. |
|
I think I found the culprit: In the working gcode every line ends with this interesting shaped cirlce. While in the none working file every line ends with this reversed 'P'. |
|
it definitely has to do with the end of line characters. the problem is that when the slicer exports the gcode file, my line endings are converted back. Im going to attach a file that attempts to fool the firmware by providing spaces rather than the extra end of line character and hope that works. after looking at the firmware code again, this should work as all it is doing is reading 4 characters at a time. with each end of line character really being 2 characters each, it would make each line divisible by 4 characters rather than just having the one end of line character causing that remainder |
Yup! Beat me by a second lol. The P indicates a "\n" in the file while the square/circle indicates "\r\n" (which is what we want). hopefully it likes " \n" just as well 😜 |
|
Nope, that did not do the trick! Sigh |
|
But how is this achieved? |
|
Maybe the answer lies in this python script? |
|
This is the part of the code containing def overread(msize,gfile):
moutdata = ""
img = QImage()
img.loadFromData(base64topng(readPSTump(gfile),''))
img = img.scaled(msize.width(),msize.height(), Qt.IgnoreAspectRatio, Qt.SmoothTransformation)
moutdata += ";"+(hex(msize.width())[2:]).rjust(4,'0')+(hex(msize.height())[2:]).rjust(4,'0')+"\r\n"
pos = QSize(0,0)
for ypos in range(0,img.height()):
qrgb =";"
for xpos in range(0,img.width()):
data = img.pixel(xpos,ypos)
pos.setWidth(pos.width()+1)
dummy = (hex(((data & 0x00F80000) >> 8 ) | ((data & 0x0000FC00) >> 5 ) | ((data & 0x000000F8) >> 3 ))[2:]).rjust(4,'0')
if dummy == "0020" or dummy == "0841" or dummy == "0861":
dummy = "0000"
qrgb = qrgb + dummy
pos.setWidth(0)
pos.setHeight(pos.height()+1)
moutdata = moutdata + qrgb + "\r\n"
return moutdata
def overseek(gfile):
outdatar = ""
outdatar = outdatar + overread(QSize(70,70),gfile)
return outdatar
def do_convert(gfile):
env_slicer_pp_output_name = str(os.getenv('SLIC3R_PP_OUTPUT_NAME'))
final_name = os.path.splitext(env_slicer_pp_output_name)[0]+os.path.splitext(env_slicer_pp_output_name)[1]
with open(gfile + '.output_name', mode='w', encoding='UTF-8') as fopen:
fopen.write(final_name)
outdata = ""
outdata = overseek(gfile)
outdata = outdata + "; bigtree thumbnail end\r\n\r\n"
fh = QFile(gfile)
fh.open(QIODevice.ReadOnly)
stream = QTextStream(fh)
stream.setCodec(CODEC)
lino = 0
fg = stream.readAll()
fh.close()
bigtree3dfile = gfile
fh = QFile(bigtree3dfile)
fh.open(QIODevice.WriteOnly)
stream = QTextStream(fh)
stream.setCodec(CODEC)
stream << outdata
stream << fg
fh.close() |
|
there is something withing the rest of the code that is actively converting \r\n to \n. im looking through the file write process rn but I may need to pick this up later. at least were on the right track of what is working and what isn't |
|
Got it! Some post processing scripts run after to add in things like time remaining and other things that have to be calculated after the main gcode has been fully written and instead of reusing the end of line character present in the original file, it just uses \n at the end of each line. Got it patched so that it now determines the format previously used and keeps it original. |
|
Amazing! 👍🏻 Thank you very much!After this being sorted out, do you think you will be able to get the Thumbnail bigger? |
|
I would be happy to take a look, but I will do that in a different pull request. I already have a decent amount in this one. Just to confirm, did the last gcode file work? |
Yes, it definitely did. 👍🏻But I noticed that there were 3 code-blocks (I think you know what I mean by that 😊) generated: I think it would be best, if only the necessary blocks were generated depending on what is entered in the corresponding field:
|
|
Yeah. I was thinking about having a drop down option replace the thumbnail sizes option whenever BIQU is selected. My only concern with that would be if BIQU ever came out with a new display, the source code would need to be modified rather than just user settings |
|
What about making the drop-down dependent on a specific user setting. |
|
Possibly. Another option would be adding a "manual" option to the dropdown |
|
You are the one in the know here. Do as you wish! 😀 |
|
btw:
Do I need to open a dedicated issue regarding this or will you make a PR either way? |
|
I am working on an implementation rn. Currently having an issue where the config value keeps resetting to default in one of the places I am trying to read it. |
Great!
Ah that's not good. But as I have learned, you are not the one giving up as soon as issues emerge! 😀 |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Please implement the ability to select the format of the G-Code thumbnails.
PanelDue only supports QOI format.
The text was updated successfully, but these errors were encountered: