But the consensus in this thread was that vector engraving usually takes a lot less time than raster engraving with the same bounding box. Which means, if the vector versions of our makerspace’s designs are rejected by GFUI due to complexity, but the raster versions, taking more burn time, are successfully laser-engraved, then burn time must not be the only reason for GFUI to reject a design. My guess is that the Glowforge company is trying to limit CPU load on their cloud servers, for processing vector designs, and therefore vector designs with more than a certain number of fonts or path elements are rejected, even if the burn time of those designs wouldn’t be very long.
There are some things that can make that time even longer:
Some materials require slower laser-head movement.
From watching the Glowforge in operation (I didn’t specifically look for this), I think the laser head overshoots the end of each raster row; in order to slow down, stop, and turn around for the next raster row. This will increase (probably by only a few percent for a full-sheet engrave) the time needed per raster row.
Yes, my idea of making a design for a laser cutter is to plan what artwork will be done by what method (raster/vector, engrave/score/cut). All the artwork in each step should be monochrome, so that both GFUI, and anyone looking at your design file, are clear on what artwork should be processed how. This typically means converting colorful vector clipart to monochrome.
The point you’re making seems to be about raster engraving of vector artwork. The “time stacking” may happen in both a vector design & a rasterized version of the same design, but if vector-engraving that full-sheet rectangle (suppose it has only stroke; no fill & no bitmap, nor other contents) takes 11 seconds ((58-inch perimeter / 335 IPM) X 60 seconds/minute), then the “time-stacked” total burn time would be 44 seconds, which isn’t much, vs. 8.8 hours for a rasterized version of the same 4 rectangles.
You have done such a great job of documenting the challenges inherent to the Glowforge workflow. In a production environment where all these things need to be addressed and standardized, I really appreciate the challenges you are trying to manage. For me it’s only ever a few pieces of text, usually don’t have to worry about rights, repeatability, and shared working environment. Thanks so much for taking the time.
(Suppose it is a rectangle, just so we have a specific example to visualize.)
You can’t engrave the interior of a no-fill object in vector mode (although, if that object is a group, there may be many objects engraved within the bounding box of that group). In raster mode, however, the laser head spends a lot of time in the interior of that rectangle.
Yes, technically, due to a limitation (detailed below) in GFUI, in most cases you don’t want to raster-engrave a no-fill object. However, I didn’t propose raster-engraving a no-fill object. I proposed engraving:
no-fill vector rectangles (emphasis added).
The fact that GFUI misinterprets your design intent (changing “no laser power” in the middle of a no-fill raster rectangle to “full laser power”) doesn’t alter the vector vs. raster comparison that mpipes was making.
The attached files illustrate this raster vs. vector question, and were made as follows:
Make a vector rectangle that fills the vector_engrave layer.
Set this rectangle to have stroke (black) but no fill.
Duplicate this rectangle (Inkscape will put the duplicate at the same location as the original).
Move the duplicate to the raster_engrave layer.
Set the raster_engrave rectangle to have fill (white). (The stroke is left unchanged.)
Apply the rasterize filter to the raster_engrave rectangle.
Make the raster_engrave layer be the only one visible.
Export the Inkscape file as PDF (using File > Save a Copy…) at 225 dpi. (I will use the terms DPI and PPI interchangeably.)
Make the vector_engrave layer be the only one visible.
Export as in step 8.
If you omit step 5, then the following will happen:
a. A rectangle with stroke but no fill gets rasterized by Inkscape to have transparent fill, and is stored in the PDF that way.
b. GFUI doesn’t support transparency, so it converts the transparent fill to a solid color.
c. The color picked by GFUI is black (full laser power), which is the opposite of the white (no laser power) that we wanted.
Anyway, notice that the filesize of the raster PDF is bigger, by a significant ratio, than the filesize of the vector PDF. Also notice that GFUI will let you engrave, cut, or score the vector PDF, but only engrave the raster PDF. These differences are as we’d expect for vector vs. raster.
Our makerspace’s Glowforge machine isn’t turned on at the moment (and I’m not there), so I don’t have an official estimate of the burn time for each of the 2 PDF files, but my expectation is that the burn time of the attached raster file is a lot more than the burn time of the vector version.
Other laser ecosystems refer to vector engrave, which is what the “score” function is on the Glowforge.
The Glowforge has the ability to accept vector graphics directly. Those systems utilizing a print driver rasterize everything when sent to print. That’s why stroke sizes have to be below a certain threshold on other systems, and the Glowforge doesn’t care about stroke size. A 1” stroke is treated the same as a .0001” stroke.
In Glowforge world, you have 3 functions. Cut, score, engrave. Cut and score are vector elements. Engrave can be a raster or vector element.
Vector artwork is not being rejected because of complexity. It’s being rejected because every object of a different color is an entirely different operation so a design with 10 colors ends up with 10 independent steps/operations. If each color spans the full bed size that means the laser head is going to zip back and forth over the whole sheet - 10 times. Using my example above of 2.2 hour run time for a step, a job with 10 colors (even vector shapes) is going to take 22 hours.
And that’s why GF does not like them, it does not have a 22 hour buffer.
Part of your other problem with things is using white as a fill color when you don’t actually want a fill color at all. If you dont want that shape completely engraved, don’t use white. Just make it a NO FILL object, give it a stroke, and things will be fine. GF knows how to translate that fine and so do all the main design apps we use.
@vee or other staff member, can I please have a response to ticket 122616 which I opened on April 16 about this thread? By e-mail to me would be the best way. Thanks.
She might not see it here, your best bet is to send a reply to the original (automated) email response that you got when you sent your first email. (It keeps everything in one place, notifies them again, and is easier for them to track.)
Our initial attempts at vector uploads to GFUI had only about 3 colors. So I don’t think “too many colors” was the reason for our uploads to be rejected.
“Zipping back and forth over the whole sheet” only applies to rastering over the whole sheet; it doesn’t apply to our initial vector uploads (prior to the revision 7 that I uploaded at the start of this thread) that consisted only of text in a large font size. Some revisions did have raster elements (a gradient that got converted by GFUI to a solid color) but these weren’t a large percentage of the full bed size, and were all the same color.
I think the phrase “(even vector shapes)” is inaccurate; a vector step in GFUI, unless that vector step is remarkably complex, is not likely to take as long as rastering over the whole bed area. See next paragraph.
I notice this to be true, for instance, during vector cutting of the phone number at the bottom of my local makerspace’s business card.
This is good advice for vector engraving. As I’ve noted, vector engraving is important & valuable because it’s usually faster than raster engraving. Some users may also prefer the smoother look of vector engraving.
If the user doesn’t want to design-rule-check their drawing to make sure fills aren’t used where harmful & are used where required, or if the drawing is still rejected by GFUI, then rasterizing may be an option.
If area fill (non-white) is specifically desired within a vector object (such as text), then that object will have to be rasterized somehow. I have found that doing this during Inkscape export to PDF seems to be easier than expecting GFUI to do it.
Earlier in this thread, I provided a rasterize filter for Inkscape; I’ve now fixed an error in this filter.
The previous version of the filter worked correctly only for opaque rectangles that were aligned with the drawing’s horizontal & vertical axes.
For any other kind of drawing object, the previous filter would leave transparent pixels (needed to pad the outline of the drawing object to a raster rectangle) as transparent, which would then get converted by GFUI to black. So, for example, black text would be laser-engraved as a filled-in black rectangle.
The solution was to “Merge” into the filter a “Flood-fill” of opaque white. This way, any transparent pixels in a non-rectangular drawing object are rasterized as opaque white, which GFUI then interprets as transparent (no laser power). It’s still a very simple filter, and it now works with any shape of drawing object, including text.
If a drawing object has partly transparent pixels, the filter will blend those with opaque white in the obvious way, and the laser output should still be what you expect.
I made this fix a while ago, but only now have I had time to upload the corrected filter to this thread.
The attached .zip file contains both the corrected & previous filters as 2 separate SVG files, with their names & descriptive text updated so users can tell the 2 filters apart from each other. (The descriptive text appears in the Inkscape status bar as noted in an earlier posting.) I’m including the original filter in case anyone ever has a (non-Glowforge) use for leaving transparent pixels transparent during rasterization. There are 2 separate files so that if people want to install only one filter, they can do so without needing to edit the SVG files. The correct filter to use now for Glowforge is called “glowforge-rasterize”. The SVG files should be put into the appropriate Inkscape configuration folder as noted earlier in this thread.
At my local makerspace, we used the attached files to check whether GFUI combines overlapping rasterized objects into a single raster. The answer is no, it does not; “time stacking” applies to both raster objects & vector objects.
To confirm this, we had to send the design to the Glowforge machine, not just upload the design to GFUI. This is because, if you try to separate the individual steps to different areas of the machine’s workspace by using drag-and-drop in GFUI, the steps stay together, implying they’ve been merged by GFUI into one raster.
The test is: Does the laser make one pass over the area in the middle where the 2 squares overlap, or two passes? It makes two passes, meaning that the 2 squares are sent by GFUI to the laser cutter as 2 separate rasters.
To be more specific, at my local makerspace we tested with the following files. The SVG contains nothing but a nearly full-page hollow rectangle (stroke but no fill) on both the “vector engrave” & “raster engrave” layers. On the “raster engrave” layer, the rectangle has the glowforge-rasterize filter applied. We exported each of the 2 layers to a separate PDF, and uploaded the 2 PDFs in turn to GFUI.
We didn’t engrave these; we only noted GFUI’s time estimate for each PDF, using GFUI’s default settings for Medium Draftboard:
vector 1 minute, 35 seconds = 95 seconds
raster 1 hour, 47 minutes = 6420 seconds
(In the raster case, we had to shrink the design by a few percent in GFUI because GFUI’s margins interfered with the PDF design.)
Earlier in the above-quoted post, I also wrote:
This might be more significant than I had thought. At the same time as the vector-vs.-raster full-sheet rectangle test described above, we also noted GFUI’s time estimate for the then-current version of our business-card design. This design contains 16 raster-engraved business cards, each 2" x 3.5", plus a small amount of vector cutting (the rectangular outline of each card, and the phone number). With this business-card design, the laser head needs to reverse direction about 8 times per raster row, instead of only once per raster row in the full-sheet-rectangle situation.
2 hours, 25 minutes.
It was hard to time the vector cutting since it was interspersed with raster operations, but I assume the vector work took only a few minutes of the 38-minute difference between the two nearly-full-sheet raster cases (one rectangle vs. 16 rectangles).
I’ve mentioned it before, but you are using terminology as it applies to other laser cutters.
The Glowforge has 3 operations: cut, score, and engrave.
Other laser systems use “vector engrave” as “score.” They say “raster engrave” for anything that goes left-right-left across the media.
Your “vector engrave” in the above example is simple a “score”, which is why it is magnitudes faster. You get a single line that’s the width of the laser beam where it makes contact with the material.
Here are two rectangles. One is a rasterized version of the original vector. The other is a vector rectangle that has been expanded, so that it creates a closed shape and actually engraves instead of scores. raster_vector-engrave.svg.zip (3.2 KB)
The time for the vector is 1 minute faster over a total engrave period of 1 hour, 17-18 minutes (full speed, 225 LPI). The reason that the vector is faster is because Illustrator refuses to expand a shape to .008", so the rasterized rectangle has a couple more lines to engrave than the vector. The smallest that Illustrator will rasterize to is 1 pixel (1/72 or .013").
Later in this post, I will explain (so that other forum readers hopefully can understand) why the format of the vector data caused GFUI to rasterize the Adobe Illustrator vector rectangle, which then took a long time to engrave.
A few comments first about terminology:
My terminology is not based on other laser cutters.
A dictionary definition of “raster” is,
So I think it reasonable to …
I now gather that you intentionally …
your Adobe Illustrator output to get it to be rasterized by GFUI. I will discuss this for the benefit of other readers.
I modified your test SVG files & mine into several versions, and got GFUI’s time estimate for each, to understand why GFUI was rasterizing Illustrator’s vector output.
When a vector shape is uploaded to GFUI, there are 3 possibilities:
The shape has fill. In this case, GFUI always rasterizes. (Earlier posts in this thread:
indicate that any stroke that may be on the vector shape is disregarded, which means if there is a thick stroke, the fill will go only to the centerline of the stroke rather than to the outer perimeter of the stroke. I didn’t specifically test this.)
The shape has stroke but no fill. In this case, GFUI moves the laser head in vector fashion along the stroke, producing
The shape has neither stroke nor fill. In this case, the convention in SVG is to treat the shape as being filled with opaque black (& having no stroke). Item 1 in this list then applies.
Apparently, you started in Illustrator with a vector rectangle that had a stroke width of
Then you had Illustrator “expand” this, which looks to me like: convert the rectangle, which has some stroke width (and no fill), into two rectangles that have no stroke width (and no fill): one rectangle for each side of the original rectangle’s stroke width. This produces a “picture frame” shape with neither stroke nor fill, which GFUI rasterizes by filling, with black, the 0.008-inch-wide “picture frame” region between the two no-stroke rectangles. (The 0.008" stroke width in your demonstration files is the same as the laser-beam diameter, but a user would notice similar contrasts between the various ways of sending a design to the Glowforge with any stroke width of approximately that, be it 0.006", 0.010", etc.)
The advantage of this “using neither stroke nor fill, trace both sides of the desired stroke” approach is that, instead of always getting “a single line that’s the width of the laser beam” for the strokes in your vector artwork, you get strokes that are the width you specified in your design software (within the Glowforge’s ability to duplicate that width).
If you specify a stroke width of 0.1" (0.100") and send this to the Glowforge in vector format without “expanding” the artwork, you get a stroke width of only 0.008", which is the laser-beam diameter. If you send the same 0.1" stroke in raster format (which you can get by uploading “expanded” vector data to GFUI), then the laser engraves with the full 0.1" stroke width.
On the other hand, since the “neither stroke nor fill” format forces GFUI to rasterize the design, the laser engraving takes much longer. This time penalty can be unnecessary with vector artwork that is well suited to the Glowforge as follows:
the artwork has stroke width that is already the same as, or close to, the laser-beam width, and
the artwork is simple enough that the user can feasibly get the Glowforge to interpret properly the vector form of the design (there aren’t style issues like
or
)
Back to terminology…
You generated a design using vector tools, then intentionally had it rasterized upon sending it to the Glowforge, then indicate that this is a vector engrave, and that a vector design that the Glowforge processes in vector fashion can only be called a “vector score.”
But users need to have the freedom to call a rasterized design, that used to be a vector file, a “raster engrave.” To put it another way, using the term “vector engrave” for a job that was intentionally rasterized, might not make sense to many users.
This is especially true on this forum, where a lot of the discussion is about “how long does the Glowforge take to engrave this design?” and many people understand that whether the laser operates in raster or vector fashion is a big influence on that duration.
I think my terminology & expectations are consistent with other forum users, such as mpipes:
If mpipes talks about “non-complete engraving” and changing from a filled object to a stroke-only object without changing the laser power, or the expectation, from “engrave” to “cut,” then there must be such a thing as vector engraving on Glowforge (as opposed to saying that the only vector operations that can be done are cut or score).
You said on the 5th of May that
… implying that Glowforge doesn’t support vector engraving. But you had already stated on the 16th of April:
“Score” implies “cutting halfway through the material so the material can be folded on that line” (my words). That’s great, but there’s no reason that shapes can’t be marked with a lower laser power that merely singes the material, to make a visible line by moving the laser head vectorwise. Also, when getting time estimates, I (actually the makerspace director, who was helping me with this) always selected “engrave” in GFUI, not “score.”
Rasterizing a design that started as vector artwork is a useful technique sometimes; and vector artwork can be engraved in vector format (if the artwork was constructed to allow this, e.g., without gradient fills).
A footnote:
I assume there is a setting in Illustrator to change this. As noted in earlier posts in this thread, Inkscape’s PDF export allows rasterizing to any resolution (within reason).
Okay, I’ve got to correct a couple of assumptions going here…you and your makerspace director are very close, but not quite there.
A raster image consists of pixels. Vector fill is solid, but it does not consist of pixels, it’s a filled closed shape. The GFUI will Engrave (ie: move back and forth in a horizontal stair step manner), for all rasterized images that it encounters, AND for solid vector fill color.
But it does not automatically rasterize vector fill.
If you want to rasterize vector fill (ie: turn it into pixels) you have to do that in a separate step before saving the file. When we are recommending that people rasterize something, we want them to turn it into a pixel image. It frequently cuts down on the motion plan calculations and allows a more complex vector image to be engraved with a more efficient motion plan. (Which keeps the file from hanging up in the buffer.) That’s why we do it.
If you would like to understand a little bit more about rasters and vectors, you can read this short tutorial on the subject. It describes the difference between rasters and vectors and how the Glowforge treats them.
You are making this so much more complicated than it actually is. I’m not sure how to explain it any more clearly, but apparently, I’m not doing a good enough job at that…
What I meant is that Inkscape can rasterize, not just to 72 dpi, but to many different resolutions. These can include:
72/90/96 dpi for webpages/thumbnails/etc.
225/270/340 dpi to match a Glowforge lines-per-inch setting
450/540/680 dpi if you prefer 2x your Glowforge lines-per-inch setting
300/600/1200 dpi which are common printer resolutions
I successfully tested using Inkscape to rasterize an arbitrarily chosen vector-based image (downloaded from the Web, and including gradient fills) to three thousand dpi. I believe that high resolutions like this are used in commercially printed graphics (magazines, brochures, etc.), although for a multi-page document you might want to use Scribus, since Inkscape’s UI is oriented more toward single-page documents.
I don’t know what you mean by “rasterize sub-pixels.” I have not tried to claim that Inkscape can do anything that’s mathematically absurd. If I had, it would fail my test of “within reason.”
Inkscape 0.92 doesn’t seem to allow fractional DPI. For instance, if you enter 300.5 DPI, it’s automatically converted to 300 DPI.
