Since there’s a necessity to split large images into smaller chunks, align them in Illustrator/Inkscape/et al, add cut lines, and export as SVG, I decided since I hate tasks like this that it would be easier for me to write a small app that does this automatically (without the need for the Illustrator step).
It works! (It actually writes a PDF file instead of a SVG as there’s a weird bug in Processing. Happily GFUI loads the PDF no problem).
1 - Would this be useful to other folks? It would be like all my other apps – Processing code that you’d run in Processing (which makes it cross-platform, but requires you to install Processing and load code)
2 - If I do release it to the wild, is there any consensus on how small or large of individual sections work best for people?
I could make the splits:
based on number of divisions (e.g. half, thirds, etc regardless of image size)
based on a fixed pixel size (e.g. each cell is 100px x 100px with appropriate remainders - like the image above)
based on a fixed number of grid squares (e.g.: 10 x 10 with each cell’s width/height based on image width/height)
Each has their own trade offs, like larger image sections, or more pieces to change settings on. I’m not sure what would be preferred. I wasn’t planning on making an interactive UI for this app beyond a file picker, so I’d love to have a single output type.
This would be incredible. I would use the hell out of this. Im really curious to see how the actual engraves will look going in sections, its going to be interesting! I can see this being optimized based on some variables that are effected by laser quirks, like sectioning more in horizontal stripes than into quadrants
I think this is a great idea, but I thought Processing’s PDF library converted all raster images to 72 dpi. I don’t have any experience with the Glowforge, maybe that wouldn’t be a problem. Or perhaps you have a work-around. Then again, I could be completely wrong. I hope I’m wrong or there is a work-around, because this would be a very useful tool.
This is something I’ll investigate more, but I have not seen a change in DPI with my tests. If there is, a scaling factor can be added that should account for it, though it might require a manual user entry of original image DPI as Processing doesn’t expose that via API. Good thing to look for. Thanks!
