This is the detailed continuation of my post in Made on a Glowforge about a project to create a new top for my wife’s ottoman from here:
TLDR Version:
- Sometimes vectors are too complicated to load and bitmapped images will work instead
- Just as there’s a relationship between power/speed there’s one between image DPI and engrave LPI - make one smaller to get past Print Load Errors if the image is too big or complicated to engrave
- High res images (2400 or 1200 DPI aren’t going to work in large sizes - the file size is too big to load and the resolution isn’t going to show up as improved quality)
- Burning through the masking on PG with an engrave isn’t going to happen at less than 5 on the power scale
- Make something your wife asks you for and you can justify a $5,000 piece of technology
For the rest who want to know how I arrived at the above, read on.
The project is not an overly complex appearing one - it’s 12x12" although I did keep the engraving within the 11.5" height restriction of the GF’s bed. However, although it took me only a few minutes to create the first iteration of the design; it took another 20 hours and days of wrestling with the settings to get it to engrave properly. And required my first email to Support in a month or more. I’ve generally found that once you get the GF down, it just works.
So it was unexpected when I tried to upload my design to the GFUI. I did the design work in Corel Draw X8 and then saved it as an SVG file.
I take my BMP file (the hawks are images) that is 135MB and convert it to a PNG file so I can just drop it on my piece of Baltic Birch (11.75" square) as an initial test piece. The PNG compresses down to a nice little 2.4MB file. No soap radio - Chrome tells me (after a long time) that the page has become unresponsive and asks if I want to wait or kill the page. Optimistically I choose Wait. And I do. For another long time (I hadn’t started timing things at this point). Chrome again asks me if I feel lucky. I don’t so Kill it is.
Okay, maybe it’s the file size - I dimly recall something about multi-MB files causing an issue but don’t hold me to that. I decide to convert the images to vectors. That file is a nice tidy little 683KB. Surely we’re cooking now.
Drag & drop it onto the GFUI. And wait. And wait some more while it displayed the “preparing your design” message. Several (10) minutes later it shows up in the bed image portion of the GFUI. A couple of Wait or Kill prompts (I pick wait a couple of times this time). Success, it’s the GFUI bed image! Lots of bits of colors that are going to be needed to be specified for operations and power/speed. This is going to be challenging. So since this is my first test I just tell it I’ve got PG Maple ply in there and then let it take the defaults for all of the many operations. Hit Print.
It does its prep thing and I wait again - probably not as long as the initial load but then instead of giving me the blinking print button, it just drops back to the bed image. No error message, no freezing of the page in Chrome, just a return to the bed image. Tried it again. No go. Returned to the catalog page and deleted the project. Reloaded it, get to the bed image, take the defaults (it’s “remembering” my Baltic Birch is PG Maple ply - huh), hit Print. Return to the bed image.
So a bazillion nodes that aren’t going to be easily converted to clean pathways is my thought. But we’ll try. Convert the complex pathways to curves. This reduces the Corel file a bit (10% smaller) and somewhat less for the SVG. Run it through the process again.
This time I get the generic “an error has occurred” (Print Load Error) message so rather than contact support as suggested I think about my options. Obviously, the vectors are an issue - I had a similar problem months ago when I did the obligatory Aztec Sunstone. So what about going back to an image but down-sampling the images to reduce the size (I started at 2400DPI originally).
Good idea. Until I get the “aww Snap” message from Chrome trying to load a PNG version. And then a Chrome crash. Restart machine. Log back in. Try again. Several times. Clear cache. Bang head on table. Resume.
Okay, time for external help. Email Support. Go to bed. Rita is good enough to thank me for my report and also suggest I try breaking the file up. So that’s the next step.
I break it into parts - corners, center, wreath. All load okay into the GFUI. Grayscale engrave the birds. Each is the major portion of an hour. Finally we get to the lavender. Print Load Error.
Something about that is too large.
Down-sample some more. End up at 600DPI for the birds and 300DPI for the lavender. But it loads all as one file I I do that. Cool.
Load and run. Crash & don’t burn. No pew pew. What?
Turn off the lavender engrave and just do the birds. Yes! Looking good no?
That’s the Map Grays to Power - from 0-100%. Really pretty sharp.
This looks really neat to me. The detail around the feathers and head really surprised me. The GF team knocked this out of the park as far as I’m concerned.
Back to the GFUI and we’ll engrave the lavender. Or not. Why is the GFUI including the two hawks on branches? They’re separate images in the file. Oh well, hit Print. About 10 minutes later, Print Load Error (PLE).
Sigh.
Okay, how about reducing the LPI - I had been taking the default values for the Map Grays to Power option so I step it down to 275 LPI. Another 10 minutes. Another PLE. Set it for 225. Yes! Woohoo! This works! The GFUI can’t handle it as one big job but it will do the parts (as long as the last one is lower LPI) - this last one is an hour & 25 minutes. Total time for this is about 3 hours of engrave time.
So far I’ve learned that files are better smaller than larger. That bitmapped engraves may be doable where a vector might not (which seems really counterintuitive but it’s the nodes that matter). Lower res images may be needed so don’t bother with 2400 or 1200 dpi if you’re not going to use that image data for something specific. I’ve also learned that there’s some relationship between image dpi & engrave LPI so if bumping one down doesn’t work, try the other; or conversely if you don’t want the “grain” of a low LPI, try bumping the DPI of the images down.
So while it’s engraving I figure I’ll send an email to Support and let them know about this weirdness with the extra birds. Document everything. Attach SVG. Start to type “and there are no duplicate images in the source file, the GFUI seems to be adding them - maybe because they’re touching?” when I realize I don’t know there aren’t any dups in the SVG, just in the Corel source. So let’s open it up in Inkscape.
I click on the lavender and drag it to the side. Along with two birds on branches. Leaving 2 other copies of the birds on branches. Huh.
So, Corel users - it looks like if you have a file where you have multiple bitmaps and some of those overlap each other, when you do the Save|As SVG, it will save each of the separate images and another combined image of the ones touching. So in my case the birds in flight and the center head don’t get duplicated but the two on branches are.
So I delete the lavender (and extra birds) in Inkscape, switch over to Corel and copy the lavender so I can drop it in Inkscape. Save, load into the GFUI and run the drill again. This time I get the images separated correctly. Go back to my email and hit the discard button. Not a problem with the GFUI. Just an issue with the translation between Corel and SVG. Wonder if I can bump the DPI of the lavender again so it’s the same as the birds - with the extra birds gone, maybe it’ll work.
Re-do the file with a resampled lavender wreath (back up to 600 DPI). Everything loads into the GFUI.
Looks like I’m ready to graduate to my final piece - I have 3 sets on Baltic Birch. Getting good points from my wife on the “it’s beautiful” scale. Let’s do the PG Maple Plywood.
Engrave the birds. Send the lavender to Print. Chrome cough. Oh well, drop the LPI. Hit Print again (this wears on the nerves - 10 minutes to Prepare to Print each time). Chrome coughs again. Drop the LPI again (to 225), hit Print. Ten minutes later, glowing white button! Another hour 20 minutes of engrave time. Woohoo! All done. 3 hours of engrave, 40 minutes of “Preparing to Print”. Sheesh.
Pull it off the GF and let’s get to weeding.
What happened to the feathers? Look closer.
Those white spaces in the bird’s head and feathers are where the PG masking was but where the engrave only burned the paper away leaving the glue and untouched wood. 
Another Baltic Birch slice into the GF (after putting on some masking paper). Change the Map Grays settings to bump the minimum power up some (5? 10?) so those white areas which were the lightest grays will burn a little hotter and through the masking. I’m assuming the masking I have is pretty similar to the stuff on the PG.
Run it all again. This time it’s only 3 hours 20 minutes because I skip the two higher LPI attempts with the lavender. Funny but I don’t mind the 3 hours of engraving as much as I do the 20 minutes of “Preparing to Print”.
Success! Time for some more PG. Cheap guy I am, I take the first PG attempt and flip it over - after all it’ll be glued to the ottoman top, no one will notice or care.
This time it engraves through the masking. It looks, although it may be I’m just looking for it, as if there’s some reduction in detail due to the compressed range of gray/power mapping I need to get through the masking. But in the end, I’m happy.
Clean up the ottoman’s top and using contact cement, apply the new engraved top. Very cool result. “Too nice to put my feet on” per my wife.
Finally, done. Ready to move on to the next project. Purchase justified in her eyes 
Some useful learnings for me.
