We are using formware for slicing dental models, after upgrading to 1.0.37, customers noticed prints are bigger, than they used to be. So I also updated to 1.0.3.7 and yes, slicing produces different results.
See the detail in the image, GREY is 1.0.3.5 sliced, WHITE is 1.0.3.7 sliced
Attached new sliced data PHZ(renamed to ZIP), old sliced data PHZ ( renamed to zip), project
Hi Petr,
Thanks for your message.
You are right that things have changed from 1.0.3.5 -> 1.0.3.7.
The slicing core has been rewritten to speed up the process.
Can I ask you what anti aliasing levels you used in slicing with 1035?
In general the V1037 slice engine has more accurate results than V1035.
When setting anti aliasing to ‘High’ it yields 64 shades of gray; instead of the previous 8 shades of gray in V1035.
This better describes the contours in your pixel map.
So yes it could be in some scenario’s that there is a pixel that is now ‘gray’ instead of ‘black’ if they have have a value that is otherwise not. It’s always an approximation.
Secondly in V1035 the Anti aliasing was done on the GPU. This could lead to some very slight changes in gray values of each pixel depending on GPU vendor. An extra uncertainty at the level that you are looking at.
in V1037 this uncertainty is gone as we use the CPU to do the anti aliasing.
Then third; as the slicing is now done on the CPU it also means that the slice contours are (depending on settings) first reduced to speed up your process. Usually the curve reduction factor is either turned off (0micron) or set to a default of 5micron. Depends on the printer/OEM if this feature is enabled or not in the print profiles section.
Lastly if you or customers feel there is to much difference you can always apply some XY correction to offset in a negative way inwards.
Does that help?
kind regards
Elco
Hello Elco,
antialiasing is set to 0.
On the picture posted, you can see there are no grey levels.
These are 2 pictures combined together. Same file, same settings, only version was changed.
Grey is 1.0.3.5 sliced, PNG file extracted and converted “white” to grey
White is 1.0.3.7 sliced, PNG file extracted.
Both images aligned and the difference, what you see, is that 1.0.3.7 generates different results ( 100microns in total in a hole ), than 1.0.3.5
Hi Petr,
I’ve had a look at your sliced files.
I just remember fixing a ‘bug’ 3 weeks ago that existed in PNG and TIFF outputs. Rows of pixels were shifted by 1 pixel in vertical direction of the image. So partially you are right in that the actual output is different. However it has no influence on your print. (well everything is shifted by 1 pixel, but the output should be similar).
Have checked what happens when you re-import the print job in the slicer?
You can do this over menu -> print job -> import (folder or file). (screenshot below of your files).
You can color them as well.
You can then overlay your print job pixels over your model to inspect how it is interpolated.
This way you could see if you agree on what the slicer did in interpolation.
What I notice there is you use a shrinkage corrrection; it seems as if all models are a bit larger sliced then they are in the 3d file. Are you aware of this? (this makes a direct compare on top of the model more difficult)
Wat is the reason you are not using any form of AA? usually it does have a smoothing effect for some part.
Furthermore, if I factor out the 1 pixel shift, i think they are pretty similar on the parts I inspected. Yes there will be some minor differences as summed up earlier.
Elco
Hello, will test soon and report back.
Scale is used to compensate the shrink of the resin after curing. We are printing dental models, we calibrate the resin by printing and scaning and comparing the data to get most accurate results possible.
This is the reason we do not use any AA, it does not work well on LCD printers.
I have followed your guide:
RED - STL curves
GREEN - slicer 1.0.3.5
BLUE - slicer 1.0.3.7
Scale tuner OFF, BLUE shifted 1 pixel down to correct the pixel shift
RED layer is on top, then GREEN layer and then BLUE layer.
Easily to see the slicing in 1.0.3.7 produces wrong slices, 1.0.3.5 is very close to ideal curve, 1.0.3.7 is 2 pixels away from ideal in some lines / rows , which means in total 100 microns difference, which makes huge impact on the accuracy of the model
Hi,
Thanks.
I’m thinking maybe it’s in the non-AA version; it looks to me like it assigns a pixel always a positive value instead of halfway. Or it could be a pixel location issue; where does it evluate the value of the pixel. Half way or on a corner.
Truth be told I only checked AA versions when you posted this as that is what most people use.
I’ll check it and let you know.
can take a couple of days as I have to dive into the code.
Elco
Short update; i seems to be only in the non-anti aliased case it’s to aggresive in painting the slice.
Compare these 2 images below with none and highest AA.
It seems the AA image(s) are all pretty OK. the gray levels correspond nicely with how much the curves overlap.
It seems to me as the none-AA version is checking off all pixels to aggresively. I need to check the core algoritm for this. can take a little.
If you are concerned with print results for now; you could always switch to AA to achieve a more accurate result.
I don’t completely agree with you that AA does not work on LCD. It has definitely an effect. The question is usually more how accurate the optical engine in your LCD is. We have our severe doubts as to if pixel accuracy is even possible on LCDs. We believe a DMD based machine with a well aligned optical engine is much much more accurate.
Elco
Last update; after thinking for a while about it and making some more tests.
I think it has to do with the core workings of the algoritm that aligns curves to the pixel grid.
It’s not easy to change this logic. However I managed to fix it with a valid work around.
It will be included in the V1038 release most probably next week. It solves the problem.
If you need it faster please write us an email at our info@ address. I can wetransfer you a beta installer.
Thanks a lot for pointing this out thoroughly! 
kind regards
Elco
