Here is another test that I performed yesterday. Each pair of images from left to right, top to bottom represent a raster image and a comparable image made up of 4 separate image tiles. They get incrementally larger by powers of two. So, the first pair is a 2 pixel x 2 pixel image, and 4 1 pixel images. The next pair is a 4 pixel x 4 pixel image followed by 4 2 pixel x 2 pixel images and so on up until 512 pixel x 512 pixel followed by 4 256 pixel x 256 pixel tiles. Each image is 2 inches x 2 inches, so each tile is 1 inch x 1 inch. So, that means the DPI of each image increases incrementally. You can see as we approach a normal DPI, the artifacts along the seams get smaller and smaller, but still exist. Furthermore, I performed this test in two different ways:
- This one was engraved in a single job by using an image tag that includes the 2nd SVG (to avoid breaking it into jobs in the Glowforge UI). It was engraved using 225 lines per inch. You’ll notice that the seam isn’t noticeable once the DPI of the image exceeds the lines per inch. My guess here is it’s a combination of the pixels being tiny and how the samples line up (i.e. those edge samples may not be sampled in a portion of the pixel that are lighter than they should be, or the pixels may not be sampled at all) as well as a different interpolation algorithm at play. It is strange to me that the interpolation of the 1 pixel x 1 pixel tiles are different than in #2, so there seems to be a couple different places that implement subpixel interpolation differently.
The SVG is here.
Another version of the SVG with image-rendering set to pixelated demonstrates how the seam artifacts disappear when viewed in Chrome or Inkscape due to the use of nearest neighbor sampling rather than bilinear interpolation.
- I performed the engravings as separate jobs (each whole image and each tile is performed as a separate job in the Glowforge UI, so each pair is 5 different jobs). This was a painful process, as the Glowforge UI really bogs down with so many jobs. The separate jobs seems to make sampling those edge pixels much more likely, so the issue is obvious in all pairs, even when the DPI exceeds the LPI. It may also be the different interpolation algorithm that seems to make edge pixels transition to white regardless of the pixel value. It also occurred to me that this could be a physical limitation, such as it’s difficult for the acceleration/deceleration of the machine to not affect the engraving at the extents of the engraving job, but there doesn’t seem to be much of a difference between the horizontal vs vertical seams so it seems to me that the interpolation differences are the main problem.
The SVG is here.
Another version of the SVG with image-rendering set to pixelated demonstrates how the seam artifacts disappear when viewed in Chrome or Inkscape due to the use of nearest neighbor sampling rather than bilinear interpolation.
The source code for what generated those images is here.