I had my topic closed without resolution which I do not appreciate. I was emailed that my file was too large so I should split it. the file was only 40kb. using the tool they linked the splitter put a black boarder around the images making it so that they couldn’t be joined. also lining them up is near impossible without controls for resize by % and px / width, height adjustments and things like grid snap or absolute positioning by numerical input box.
The file can be split and the parts embedded in an SVG file in order to avoid border lines. In order to do that, it helps to have knowledge of one of the 2D vector programs. Which one are you using?
i have inkscape, qcad, openscad, GIMP, Krita, Pinta, blender
Okay, I’m unfortunately not familiar with GIMP, but the process is - split the jpeg in GIMP and save each part as a separate jpeg. Take them into Inscape and align them there, add any cutlines that you want around the outside and save the file as a Plain SVG.
Drag that SVG file onto the Glowforge interface, and you will get multiple engrave options for each part. Just set all but one of the engraves to Ignore and run the one left. When that one is done, set it to Ignore, and open up one of the other ones and engrave that one. Continue until all the parts are engraved.
Do not move anything on the bed of the machine or on the screen, even if it looks like it is no longer aligned. As long as you do not close the file or move anything, the other parts will engrave exactly where they are supposed to in relation to the other parts. Last step is to cut it out, after setting all of the engraves to Ignore.
It’s a bit tedious if you are trying for something really large. You might want to try a test case on a smaller version of the image first, to see if it turns out the way you want it to.
The way support has been closing threads is starting to get less helpful.
It would be great to see a summary of the resolution in the closure statement.
To close a support issue and only reply with the solution by e-mail, instead of in the post seems much less helpful.
Makes me want to only use the Forum for support rather than send an accompanying e-mail.
I hesitate to reply here on this… but we’d like to help you. The reason that the other thread was closed was because you had emailed support, which opens a support ticket. Posting in Problems and Support also opens a Support Ticket - having multiple support tickets to work on a problem never seems to be the ticket.
Officially, it’s something that they are working on and have made improvements on but there are still some issues with engraving images. It’s helpful knowing what size you’re trying to engrave at and it gets a little confusing when you mention that the file is 40kb when the linked files were around 2.5mb.
I loaded one of the images earlier that you had linked to, but to get it to process at a larger engrave size, I had to reduce the LPI down to 125. That was somewhere around a full bed-width/max engrave size. I have no idea what the quality would be like at 125.
I broke apart one of the hi-res images you had linked to. I don’t see any black lines around any of the borders on this split (Clarify: I do see some thicker black lines on the borders, but those are also on the original that I saw on imgur?).
ybpPGhV [www.imagesplitter.net].zip (2.0 MB)
I, like Jules, don’t know Inkscape or GIMP well. But the process is similar across all of the programs, just slightly different methodologies.
You can load up the 4 images into inkscape and just butt them together. Follow Jules instructions for the rest (engrave 1 section at a time - don’t move anything, just process the next section and go), and you should probably be able to get a higher LPI engraving that way.
The 8th and 15th image are around 40k. Those are the ones that are just a black line making a box.
I guess I will try it at 125LPI
it wasnt the borders it was on the edge where they were to be joined
this is an instance where terminology gets confusing.
There is a big difference between the actual filesize being too big, and the placed image itself being too big onscreen/in the GFUI. So, when I am just told that the file is " too big", I don’t know which size measurement is being referred to.
This has happened to me a few times already, and it would be great to get a message in the UI about what actually went wrong (I know, I know, it’s in the hopper.)
It seems to me that most of the time that I have gotten these errors, it had to do with the size of the engraving in the UI, and not the filesize. Dropping the LPI “solves” this as @markevans36301 said … but not really, if you want that really clean high-lpi look.
I’m going to just link my answer to the box issue on the other thread that you started here.
And that first map is something like 85 inches wide. (Look at the rulers)
@jbv did a good job of explaining it - I also tend to think the main issue here is the images are just physically too large in size.
There is a GIMP tutorial on reducing the file size linked in the Matrix if you need it.
I’d give that a try before splitting the file. It might not be necessary. (Or it might still be needed, but you can try that first and you might be able to keep the LPI on the final image in the 270 range.)
Well crud…I just got the ‘error’, too. Tried a couple of times. Third time, I deleted the bottom row, since those will be cut out of wood and the top row is from acrylic. I even set everything to ignore, except the engraves. Nuthin’!
Here’s my SVG if anyone has the time and inclination to look at it. Sure would appreciate some help.
Small box - Alison.svg.zip (80.2 KB)
It opened fine for me, where is it hanging up? During the opening or during the render?
Never mind, during the render.
Hang on - you can probably take it in steps and get it to work.
Nope. Might be something with the file. Checking.
Definitely the file. Other engrave files process just fine.
I’ll mess with it some more.
This is @polarbrainfreeze’s box design that he gave everyone for free. I made one before…and even changed the cut-outs in the sides and it worked fine. This time, I added some engraves for the inner part which is supposed to be from frosted acrylic.
pixels are what should matter. The glowforge settings go up to 1355 LPI. the bed width for cutting area is 20 inches. wikipedia suggests using a source image of 1.5 to 2x the size of the output. that puts the optimal image resolution width at 54,200
The problem appears to be with those images, and I don’t know what it is. I took them into Photoshop, saved them as jpegs without changing anything else and reloaded the images, and the file Processes just fine. 24 minutes to print it.
Anyway, give this one a try and see if it loads for you.
Small box2 - Alison.zip (76.5 KB)
Thank you, Jules. Those images were pngs. I’ll try yours.
you may be mixing units here. LPI ≠ DPI
The LPI refers to the number of
horizontal vertical steps. That would only be 12 inches, not 20.
Does Wikipedia has suggestions for Glowforge settings? Or is it just a general laser-settings page? Link? I have had the best results from stuff that was designed at the size it will print, and it feels like I lose data when I shrink stuff down.
As for the high LPI of 1355… there may be great reasons for going that high, but I have not yet found them.
Oops, sorry! I probably had that setting at a really low resolution because i was working on huge fliers that needed to be scaled.
Let me see if resaving them as a PNG from Photoshop makes any difference in getting it to open. We’ve seen some strange results from trying to use Illustrator for jpeg work. It might be the same for AD.
They were PNGs to begin with. It opens just fine…I just get ‘the error’ when rendering.
main hang up I have run into is flipping an image - it will not take when you submit to print sometimes it gives an eorror message, most of the times the upload window just goes away (when clicking pring in UI) . both as svg from inkscae or pdf from corel (I’m still on good old corel 9, which cant save to svg, but does export to pdf). if I set the flipped image to ignore in the GF UI, the rest will print. this is a known issue, but easy to overlook. was surprised that it was an issue in the PDF as well.
just something to keep in mind. we may want to put together a known bug list/ wiki somewhere