I’m sure there is a simple answer but somehow I’m missing it. I want to upload a file, let’s say the coffee sleeve and apply artwork that was created using the Trace function to it. I don’t have the artwork as a file on disk. It’s only in the GF interface. I tried loading the “traced” image, doing a copy then loading the coffee sleeve and pasting it but this did not work. How can I do this?
Scan or take a picture with your phone and join the art and the scan/photo in your favorite vector program?
Or I’ve never tried this but if you scan can you drag your art file into the resulting scanned window?
I’ve never actually used the scan function, hah!
1 Like
The GFUI is like Fight Club. What goes into the GFUI stays in the GFUI. 
3 Likes
It’s easy, just open the sleeve file, then click on Add Artwork in the thumbnail column. Choose Trace Bed Image. Put your artwork in the bed, run the scan and then remove the paper from the bed and you can move the engrave wherever you like. When you close the file, the copy of the engraving will be saved with it.
3 Likes
Thanks Jules. The problem is I don’t have the artwork as a standalone file. It was a signature I had someone sign to demonstrate the trace function so the signature is in the GF interface but I didn’t save the paper they signed on that’s why I’m trying to figure out how to use the signature in the GF to apply to another image.
Oh…one extra step. Burn the signature onto a white masked scrap or very light colored wood (basswood is almost white), then scan it again.
Unfortunately, once it has been saved as an individual file, I don’t know of any way to combine two files that you don’t have on your own device. (If you created the file, you can just drag and drop it from your desktop into an open file in the GFUI. But if it’s a catalog file or a freebie, we don’t have that option.)
Thanks Jules. I had thought of that option but was hoping I would be able to combine the two files within the GF interface itself. Oh well. 
This is another thing we should be able to do. “Add artwork” should allow you to choose from your GF library. I feel like maybe it’s just an oversight that it can’t be done.
8 Likes
Totally agree. This seems like something that would not be too difficult to do in the GF software and would solve my problem.
1 Like
One could get really tricky 
If you bring up the design while the GF is off and the GFUI has no image to show your design will show up on a white background. if you then zoom in as much as possible and do a screen capture you will have an image with your design on it. If you brought that into Gimp or Inkscape you could then have your design back, though it might need some work.
Thats exactly what I wound up doing. Did a screen capture then brought it in to inkscape and added it to the other file. Solved this issue but it seems adding the ability to copy and paste between files in your GF Library would be beneficial to many folks and not that hard a solution to implement in the software.
1 Like
The company has spoken on this with their main issue is that the complications of DCMA being much worse where pockets are deep enough to go after no matter the legitimacy of the attack the expense is not worth it. I think that the whole DCMA should be reconsidered but my opinion does not have much force.
1 Like
I completely agree with you on this. I don’t even know why I didn’t think they would do this, man does this make me despise their cloud software so much more. A hardware company should not have the power to regulate what we can print.
If Marvel wants to sue me for selling their property that’s understandable and my problem for doing something dumb. If my child wants to print out Spiderman to play with that is also fine. Glowforge should not have the power to force us to take down prints and subsequently ban us for it.
I mean you do you, but despise is an awfully strong word here. You still despise it even with all the benefits that go with it? Faster update cycles, cross platform capabilities, high availabilty and speed, no local updates to drivers or other janky software, easy access to a great deal of data for troubleshooting on their end… in my mind, cloud-based is a massive win for all of us.
But if you despise it, then have at it. I just think you might be coming out more ahead than not by their use of the cloud.
Now if only they’d given us an ethernet jack…
5 Likes
So true, I’ve seen so many posts where “intermittent wifi was the cuplrit…”
None of these are even loosely tied to cloud-based software. I work on a large, internet capable, Desktop application that has biweekly releases and auto-updates to our users. We handle all these, except of course “HA” which isn’t a thing local to your computer. Sure you could have HA with a UPS or some weird remote session balancing to other computers on your network but why?
More importantly, it also supports offline mode because it’s well known that people like to be nomadic during their work days and having an internet connection isn’t always a guarantee. Chrome is also another great example of software that can do this.
I also don’t see why the Glowforge would need any custom drivers, it currently downloads the motion files from the web that wouldn’t need to change even for local offline. You could just have the Glowforge detect a web server running within the Desktop app.
Debugging is also easy so long as the application was designed to keep session reports and metrics locally, which is no more effort than storing all this data in the cloud. It would be a simple click of a button for the user to review and upload all the logs.
The GFUI would actually make a great Electron application (cross-platform) and would then benefit from only needing to support chromium to boot. IMHO this would be easier to manage in the long run and if they used each users local computer for computation they would have more collective processing capability than they would ever be able to afford in “the cloud”.
There is a huge difference between having a cloud to support a desktop application and requiring that everyone upload all of their data to the cloud to be able to play.
1 Like
…For a large company?
As for the motion files, GF tweaks how they’re made pretty often, so you’d definitely have to update any sort of algorithm there, yes? And now, if you’re pushing that to host computers and your entire business model is based on the competitive advantages that your camera dewarping and engraving calculation systems provide… that would seem a bit risky, yeah?
None of this is to say that any of this is even up for debate; we’re largely wasting our collective energy having this conversation, but it’s still interesting.
But I will say that there is cross platform, then there’s cross platform. Right now, it’s fairly browser agnostic, so they can push it to mobile and lots of other systems. I haven’t tried it, I wonder if an RPi could be used to run the GF? We should have a contest to see who can push a job to the UI with the least hardware, might be interesting (I wonder if you could do it with an ESP32?). Your “run your own web server with a large app” would struggle with that sort of scenario, yeah?
Kind of a “yeah but can it run doom?” scenario…
1 Like
I know, and it’s not even relevant to this topic. 
I wasn’t the one who tried to explain how cloud software can do things the desktop cannot…and yes it is a medium-large company, 700+ employees. Then again the last several places I’ve worked had similar continuous delivery pipelines. It’s a moot point, if a company understands how important a CD pipeline was from the beginning shipping would never be an issue.
I wouldn’t say that it’s risky at all:
- It’s not hard to obfuscate an algorithm to make it extremely difficult to reverse engineer. The fact that we already have the pulse files means that a dedicated person could reverse engineer if they were really dedicated.
- They are based in the U.S. so local competitors would have to be crazy to resell their algorithms, likely in the process of being patented.
- Camera lens correction isn’t new.
- Having an open ecosystem that people can create plugins for makes a platform significantly stickier. Users will think twice before going to another platform when they realize it doesn’t have all their plugins.
- Many companies have ships proprietary code to desktops for years, it’s very low risk.
- If the GFUI software is their only competitive advantage we’ve all bet on a losing horse. Fusion 360s built-in CAM software is amazingly powerful, professional image software will always have better trace capabilities, etc.
Being open can be a huge competitive advantage, and it tends to attract some of the best talent.
Not sure how their target user base would be able to interact with, let alone print from an ESP32. An RPi, would be doable with ease. Now, as far as a POC goes I don’t see why we couldn’t get an ESP32 to work for one-off prints.
What do you mean by run? Because this would be interesting. 
My point is that while it’s possible to do those things with a desktop app, it’s difficult to wrangle with a leaner company like GF. They aren’t tiny but they aren’t 700 employees either. I’d suggest that your model probably also scales very nicely but I suspect is less beneficial at GF’s size.
And also, at least part of GF’s biz model is “buy our stuff”, both designs and materials. Having us attached to the internet facilitates that, for sure.
And yes, while it’s all possible to setup and maintain software locally, this way is far simpler for less technical users, which are GF’s bread and butter. It just works, yeah?
Anyway, this horse has been dead for ages. Moving on 
1 Like
I knew you’d point that out. I originally was going to mention this, it’s even more important at their size. I usually start at places <30 employees grow for 3-5 years, repeat. The speed at which tasks get done in the early days is phenomenal if there is focus on CD from day one and it makes scaling employee count easy to around 500, then things slow down as managers have probably been hired
At their size, many of the tasks that have been “hoppered” could easily be delivered during a single hackathon day by teams of two or three. This is generally quite common practice which leads me to believe there is some other internal process blocking this.
Were you just joking about making this run on an RPi? I could also try my teensy, I don’t have ESP32s laying around.
And they knew that and chose this direction. Seems like a technically valid choice? I agree that I am sort of surprised at how slowly the hopper turns here, but what can you do? I have all sorts of UI gripes that aren’t even related to the actual lasering… gripes that should be so fixable. The issue of course is that it must be really stable and cater to a huge variety of users, so what I see as “ugh change this” is probably other users’ favorite thing.
Not exactly, I just figure a RPI can probably load the UI (as is) and send a job. It’ll come down to how fully functional the Rasbian browsers are these days, I’m rusty on my pi stuff.
The esp32 can access webpages and serve pages, seems like you might be able to get creative and push a file to the UI in some really hacky way, maybe not. It’d be hilarious if you could.