You are not logged in.
Pages: 1
Hello,
Trying to use a png mask to calibrate the screen brightness on Wanhao D7.
I'm having problems with the mask png being all corrupted when I slice my plates on 2052 (windows or pi (2052). I am able to upload the mask as a PNG file (which I exported from GIMP with compression set to 0) and it renders properly in the mask configuration pages. However, once I slice, the first layer shows a corrupted copy of the mask which has multiple interlaced copies of the image. This corrupted mask is then applied to the rest of the layers.
I followed some steps for the Wanhao D7 to approximate a mask by taking a picture of the screen with a camera and preparing it for use as a mask in png format.... are there specific requirements for the PNG format? Seems like there's a bug here, either in whatever is causing the corruption, or if there are undocumented requirements for the mask image format.
Erik
Offline
You are the most probably right and it is a format issue.
Could you share a screenshot of the issue?
Offline
Sure.
The mask I'm using, and some screenshots. I also tried rotating the mask 90 degrees, which had much the same result.
https://ibb.co/7CszkYd
https://ibb.co/rbC3Nh0
https://ibb.co/MP7rVx2
Offline
Use following PNG format see if it solve the issue or not.
PNG 1920x1080 1920x1080+0+0 8-bit sRGB 10548B 0.000u 0:00.000
Offline
OK. I found that my Windows install had the bed size set to 1920x1080. Once I changed the mask to match that, a 1920x1080 png worked on Windows, but no mask file at either 1920x1080, 1080x1920, 1440x2560 or 2560x1440 would work on the Pi. (got the weird tiling effects).
The pi connected to the D7 is set up for 1440x2560. But since I also have a Windows one for testing, it uses remote slicing.
Once I changed both nanodlp installs to have matching resolutions at 1440x2560, and used the same mask (this time at 1440x2560), it worked. (I also updated to latest beta release again)
So perhaps there is some wonky interaction with the remote slicing? Also, perhaps you can add some protection around making sure the mask used is the same resolution/orientation as the print bed? At least some error text to indicate a size mismatch? Additionally, can you fix it so that regenerating the plate will pick up the current system mask (unless a custom one was used for the plate)?
Offline
Is the correct mask being used by remote slicer? Or you submit both side?
Offline
I used the same mask file on both sides, so I am not sure if it uses the one from the client or the host.
Offline
Are they identical? Maybe it use wrong one. I could not find issue on code. If we could find, exact problem it will be much easier to fix.
Offline
I will do some more experiments to further isolate.
Let me break it into 3 behaviors:
These interactions can be investigated by setting up different screen sizes on local and remote slicers. (e.g. use 1440x2560 on the Pi, and 1920x1080 on the Windows remote slicer host, and mask files of various dimensions).
1)(locally) On a local slice, if the mask dimensions/orientation do not match the local screen dimensions/orientation, you get weird corruption/artifacting in the rendered layers. There should be a check when setting up the local default mask that the mask and screen dimensions match. Since the configuration can change, this should also be checked if the screen dimensions change, when a custom mask is provided for a model, and probably should be checked at slice time as well. Maybe it should attempt to scale the mask when there is a mismatch, or warn or block the user.
2)(remotely) If the screen and mask dimensions on the local system do not match the remote slicer system, you get similar corruption/artifacting in the rendered layers. When doing remote slicing, does the remote slicer receive all job parameters in the job, or are there dependencies on the local configuration of the remote slicer? Ideally these should be fully independent because you might have one remote slicer and several printers with different screen dimensions and masks. The remote slicer's local configuration should not affect the job. The observed behavior suggests these are not fully independent.
3)(remotely) I'm not sure if the remote slicer uses the mask from the remote job, or its own local default mask on remote render jobs. Should be easy enough to check by using specially marked mask files on each side.
Offline
Pages: 1