Math error in dither pattern (but only on the print)?

Hello,

I am working with a rather busy photo and am working to get it the way I want it, its trial and error.

I had thought the preview in the app was WYSIWYG. I found that what is shown in the the app differs from what the machine actually cuts.

You can see there the screenshot of my print and the dither pattern it chose.

Here is the engrave :

In my GF app I copied the project and renamed it to math error if you need to examine it.

As you can see there is a repeating horizontal line where it is missing dots. Further I noted that the exact dot pattern used is not the same as the preview there are dots in the preview around his eyes that are missing in the print.

I know the preview has some loss of pixels when when zoomed out but these artifacts do not show when zoomed into 1000% which I would assume shows you exactly what the machine is going to do, except it doesn’t.

The print was May 13th 2019 around 4pm EDT.

Please advise, thanks !

-Greg

There is a line that goes through his eyes as well. That could account for the differences. In any case I see three horizontal lines in the engrave that look like encoding errors so some sort.

2 Likes

Look at his hair, in the preview there are many dots , in the print they are not there. There is an issue with the math error on the final print for sure, but I think it stems from not printing what its showing you. It is as if it re-dithers it before the print.

Yeah I get that. I was just saying that I see more problems with the print. Unfortunately I don’t have an answer for you.

For the dither it looks like the preview is at a higher DPI than the print. If the DPI matched it might be WYSIWIG. Regardless I agree that the preview and the print should match. Otherwise it is just trial and error to get the correct settings.

1 Like

It may just be my imagination but his face looks a little compressed horizontally in the print.

Yeah it looks that way, however if I hold the print up a few inches from the monitor, using forced perspective I can move it in an out until it is the same size, and it matches horizontally and vertically. So its probably just an illusion / angle the photo was taken at.

1 Like

I noticed the photo was not parallel with the camera but I didn’t think it was off enough to make that big of a difference. Glad to hear that’s not another issue you are having. :wink:

1 Like

I’m not seeing any prints from May 13th on the Glowforge associated with your account. Can you let us know the serial number (in ABC-123 format) of the machine where you’re experiencing this issue? Thanks!

Messaged you, thanks !

Thank you! While investigating I noticed the print you did at the time mentioned in your post was not done using Proofgrade settings, but you did print this design a few more times using Proofgrade settings. How did those other prints turn out?

You will note the non proofgrade settings were to slow down the cut speed on the final cut, as the proofgrade cut was not making it through the material. Also I force the material using the menu because I remove the proofgrade sticker and masking on the side that I am cutting. Finally the settings on the dither need adjusting from 0 to 100 to 0 to 60 on the dither pattern or the print comes out too muddy. All of these things should not affect the dot pattern shown vs the dot pattern printed.

I have since printed it using a different method, however I would have considered that print good enough if not for the missing lines (the error) and I figured I would report it to you and leave it there for you to give to your programmers who could then re-produce and possibly squish a math error. I have written my own dithering program and could detect and solve for this type of error. Also it alarmed me to find that the dither pattern used vs the pattern shown was different when zoomed in to 1000 % or anything over real 1:1 ratio . I understand that when viewing less then 1:1 substitution needs to be made, and I would expect the pattern difference in that case.

-Greg

I have since printed it using a different method

Oh good!

I figured I would report it to you and leave it there for you to give to your programmers who could then re-produce and possibly squish a math error. I have written my own dithering program and could detect and solve for this type of error.

I really appreciate that. I’ve opened an investigation with the team here for just this purpose.

I’m going to close this thread - if the problem reoccurs, go ahead and post a new topic (we can add the details to the investigation). Thanks for letting us know about this!