Uh oh…I did flip the images in this file. I’ll bet that’s the problem. What a weird thing though. I’d forgotten all about that. I’ll flip them back and see if that solves the problem. I wonder though, when we actually need to flip something, how we will get around that issue? Thanks for the heads up.
1 Like
If you need to flip it, you take it into Photoshop and resave it. 
2 Likes
Gees. Even though it’s too bad it fouls stuff up in the UI, sometimes the simplest things throw me for a loop. Don’t have photoshop, but can use AD or Affinity Photo. Going to try this again now and will report back.
flip it in an image editing program (photoshop etc), save as png and then load that to inkscape/coreldraw etc. tedius, but should work.
I don’t have corel or any photo editing programs yet loaded on the laptop, so for my print I just turned the flipped image off. need to fix something with the shared folder I use between desktop and laptop - sometimes both can see a file other times only one, really weird -had to have to run back and forth with a usb stick …also wish engrave of multiple images at the same setting and same general path would engrave together…(I guess need to make one png file and then import to inkscape).
4 Likes
affinity photo should be ok, designer will likely give you an issue as well as I suspect it does the flip similar to inkscape or CorelDraw…
2 Likes
You guys are great. The flip was the problem. I opened the offending image in AD, flipped it, copied it and replaced the one that didn’t work. It loaded and rendered just fine. This is a lesson I won’t soon forget. Thank you both, very much! 
5 Likes
No problem.
2 Likes
I haven’t found a material that handles such a high lpi, either. Had high hopes for anodized aluminum, but anything above 300 to 600 lpi doesn’t appear to add much to the party. Certainly not worth the increased run times.
5 Likes
Pixels are only half of the equation when a printer like the Glowforge is producing output. That’s because the software driving the printer is trying to map those dimensionless points to physical sizes. following this discussion back to the other thread about firmware, you mentioned:
That, along with @jules report that the file opened to be 58 inches wide tells me that the PNG was encoded with header information identifying it as 72 dpi. To fit that image into the 18" engraveable width would be a resolution of just over 235 dpi. You might want to change it to 300 dpi (just the header information, not changing the pixels at all) and see if that makes a difference.
My understanding (I don’t have a laser yet, so this could be flawed) is that the LPI setting is the vertical spacing of the centerline of the engraving passes. This is different from the vertical resolution. The laser’s dot is unlikely to be 1/1135" or 0.00088" in diameter. Measured kerf of cuts is IIRC somewhere around 0.008". Making a wild guess that the beam size at the engraving surface is 1/2 the size of the kerf of a cut, you might have a dot size of .004" Given that, any LPI greater than 250 will result in the beam overlapping on adjacent passes.
This means that the LPI setting is really more about the smoothness of the vertical image transitions, and less about a number of pixels. At higher LPI settings, the same spot on the engraved surface will be hit by the laser multiple times, providing an averaging effect.
Similarly, I don’t think it has been documented anywhere what the horizontal DPI is, though it is logical to assume that the maximum horizontal DPI will depend on both the speed and power settings for the engrave.
Because of these physical realities, your calculations about the optimum source material resolution are based on a shaky foundation.
I hope thinking about this in terms of the physical realities, and that the Glowforge deals in physical sizes and mapping image pixels to those physical dimensions will help you in understanding how to best feed your Glowforge to give you the results you want to see.
Happy Forging!
7 Likes
Everything you said. I had typed up something similar and then canceled. You said it better.
But (damn, always a but) DPI is irrelevant to the browser, because as you mentioned, it’s header information. It’s for printing.
I was going to post some nice examples and screenshots. Previously, when I imported a high resolution image to the UI, it would display at full resolution - meaning it would go way off the display and I’d have to resize it myself. Now, it seems a high resolution image is being scaled to fit the bed display. I don’t know the methodology behind how it’s doing that. For wanting an exact image size, my process is to create an SVG with the image sized how I want it, and save the SVG with the image embedded. You could also save to PDF. This will constrain the image to the size specified when creating the file (but the file still includes the high-resolution file).
However, I don’t want to bring this topic off the reservation. As I mentioned initially - “officially, it’s something that they are working on and have made improvements on but there are still some issues with engraving images.”
I’m not speaking officially because I’m just an owner and someone trying to help you out. The terms can get a little confusing - my experience has been that it’s not a disk file size issue (kB, Mb) (unless potentially you have very slow internet and the request times out, gets tired of waiting for the upload). It’s not a resolution/pixel count issue, as far as the image is concerned. It seems, in my experience, to be a combination the physical size of the requested engrave along with the LPI/resolution requested - or, more precisely how much data is in the motion plan. The workaround at the moment is splitting your images and doing separate engrave processes, which reduces the size of the motion plan.
As for:
I don’t fully comprehend where you are saying the issue exists; are there artifacts in the image files that you downloaded after they’d been split, or are you having problems recombining the image in the software to create a file to send to the Glowforge?
1 Like
This totally explains something I’ve noticed in testing when working with the engraves. I’ve always considered the optimal setting to be 270 LPI. The lines are not overlapping by much, but coverage is good and there are no gaps.
Very interesting reads @johnse and @jbmanning5 - thank you. I don’t even begin to understand what’s going on yet with the engraving sizing, much less take a shot at explaining it. I just haven’t done enough of them yet, and like you said, it’s a moving target right now. 
This is exactly what I’ve been doing, and it has worked without any issue for me from the beginning, so it’s been tough to diagnose the problems that a lot of folks are running into with engravings. I’ve also found that 300 PPI is fine for print and engraving work, so I definitely don’t take the resolution up any higher.
If this turns out to be a method for getting the larger sized images scaled down correctly for the GF interface, we need a workflow tutorial on it.
(Even if no one bothers to read them.) 
Yep. My guess on it as well. You did a much better job of explaining it than I could. 
3 Likes
A few things here. First, the glowforge cloud code doesn’t really care about the number of pixels in your source image. It’s going to have to rescale your image for the engraving process regardless, unless you miraculously hit on exactly the right factors. So it takes the pixels per inch specified in the file you upload and tries to display the image at that size in the GFUI. If the bounding box for your image is several times the size of the GF bed and/or any plausible browser window even with zoom-out, nothing good will happen.
Second, the glowforge cloud code is going to have to rasterize your image at least once to engrave it. So even if your file size is only 40K, an image 50,000 pixels across by something like 20,000 pixels wide will generate roughly a gigabyte of data for processing. This might be more than their cloud instance is will to handle.
Third, what other people have been saying about LPI. There are cases for going all the way to 1355, but they’re rare. And don’t believe wikipedia on the optimal ratio of source to final, because that’s based on a long chain of assumptions about how the image will be processed and how it will be lasered onto a material that do not necessarily hold for the GF.
1 Like
Yeah, I lost an entire evening to this flip thing. It just didn’t twig for me until after I posted a support request and thought about it some more. If you flip in Illustrator, there is a workaround, though: just rasterize the image (again) after flipping it.
2 Likes