August 31, 2018
Version 7.44 of gbr_rip includes a number of improvements; in particular we have greatly enhanced the front-end module called split274x by applying multi-threading to several of its functions: large polygon splitting, surface sizing and surface circularization. (A "surface" is a term from ODB++ and is implemented in Gerber using the G36/G37 area fill commands.)
Split274x provides a number of "conditioning" functions but the most compute intensive ones are where Boolean operations are involved. For example, splitting a polygon with many thousands of vertices into two or more polygons with a smaller vertex count is compute intensive. However doing so can be quite helpful downstream.
Extracting arcs from a number of vertices in the boundary definition of G36/G37 areas is also very compute intensive. By making this function multi-threaded we have greatly reduced the time required to rebuild the boundaries with arcs. This often results in significantly reducing the size of the Gerber file that the rasterizer must deal with.
We collected a number of files ranging in size from about 300MB to 2500 MB. These tend to be large area panels (up to 600 x 600 mm); they have a number of internal layers arranged as paint and scratch; They also tend to make use of a large number of surfaces - i.e. G36/G37 area fills.
| Gerber File Name | Gerber File Size (MB) | Image Size Uncompressed (MB)1 | Image Size PackBits (MB)2 | Gerber File Size AfterCircularize (MB)3 |
|---|---|---|---|---|
| VD701 | 774.4 | 7085 | 1240 | 246 |
| VD703 | 2281.3 | 7085 | 1240 | 722.3 |
| greater_2GB | 2678.9 | 7527 | 1382 | 505.3 |
| large_lp_cnt_1 | 354.4 | 7075 | 585 | 188.2 |
| large_lp_cnt_2 | 354.4 | 7075 | 585 | 188.2 |
| mt_slow_1 | 356.4 | 8251 | 1032 | 189.7 |
| mt_slow_2 | 293.6 | 9156 | 958 | 287 |
1. uncompressed image size using a DPI of 10160; a pixel diameter of 2.5 um.
2. image size after packbits compression.
3. the intermediate Gerber file after split274x has run circularization. This file is called the "cache" file.
Intel i7-4770K — 4 cores — hyperthreaded — 3.5 GHz
32 GB RAM
SSD for OS — SSD for data
Windows 8.1 Pro — 64 bit
In this flow, split274x does the usual pre-conditioning of the format and the apertures. No polygon splitting and no circularization is done before sending the new file to the rasterizer.
Command Line:
c:/wcad/Gbrip64.v744/gbr2tiff64.exe launch the executable %FILE%.gbr input file -pack:%FILE%.tif generate pack bits TIFF output -ram:1024 use 1024 MB for raster buffer -dpi:10160 use a DPI of 10160 (2.5 um pixel) -aw auto compute window -inch use inches for command line units -status report status -engargs -thrnum:2 engine arguments: use two threads for raster
Same as above except that max points is set to 4096 and -circularize:1um is specified in order to convert surface boundary segments to arcs. Further, split274x is instructed to keep the conditioned file instead of deleting it when the rip is done.
Command Line:
c:/wcad/Gbrip64.v744/gbr2tiff64.exe launch the executable
%FILE%.gbr input file
-pack:%FILE%.tif generate pack bits TIFF output
-ram:1024 use 1024 MB for raster buffer
-dpi:10160 use a DPI of 10160 (2.5 um pixel)
-aw auto compute window
-inch use inches for command line units
-status report status
-engargs -thrnum:2 engine arguments: use two threads for raster
-keep_split! keeps the conditioned file for later re-use
-bgn_split start of directives for split274x
-chord_error:0.5um sets chord error for fracturing input arcs
-circularize:1um turns circularization on and uses 1um tolerance
-dpi:0 no sizing but forces fracture of incoming arcs
-maxpts:4096 break polygons so that none has more than 4096 vertices
-end_split_args ends the directives for split274x
The assumption here is that the circularize flow has been run and the conditioned file has been "cached." So we deliberately turn off split274x since the conditioning it does has already been accomplished. The rasterizer will run directly on the conditioned file.
Command Line:
c:/wcad/Gbrip64.v744/gbr2tiff64.exe launch the executable %CACHE_FILE%.gbr input file cached from circular flow -pack:%FILE%.tif generate pack bits TIFF output -ram:1024 use 1024 MB for raster buffer -dpi:10160 use a DPI of 10160 (2.5 um pixel) -aw auto compute window -inch use inches for command line units -status report status -engargs -thrnum:2 engine arguments: use two threads for raster -no_split disables split274x
We can now run all of our files through the three benchmark flows: STD, Circularize, and Cache. We expect the Cache to be fast since the file conditioning has already been done. It's not clear whether STD or Circularize will be faster -- STD has less overhead in split274x but Circularize presents the rasterizer with a smaller file and less complex polygons.
| Gerber File Name | Gerber File Size (MB) | STD FlowTime (secs) | Circularize Flow Time (secs) | Cache Flow Time (secs) |
|---|---|---|---|---|
| VD701 | 774.4 | 136 | 109 | 69 |
| VD703 | 2281.3 | 287 | 205 | 95 |
| greater_2GB | 2678.9 | 296 | 187 | 78 |
| large_lp_cnt_1 | 354.4 | 87 | 85 | 52 |
| large_lp_cnt_2 | 354.4 | 84 | 85 | 52 |
| mt_slow_1 | 356.4 | 149 | 114 | 88 |
| mt_slow_2 | 293.6 | 108 | 101 | 77 |
April 6, 2011
|
Artwork has recently been tasked with supporting equipment that is required to process very large Gerber (RS274X) files -- on the order of 300 MB up to 2GB -- and to produce extremely high resolution raster images (from 50,000 DPI to 190,000 dpi) This is generally much larger input files and much higher resolution than is typically needed for a PCB imaging or inspection machine. In order to determine if our current RIP was up to the job (or whether we needed to come up with new algorithms and approaches) we generated some very large Gerber files and proceeded to run the RIP at different DPIs. The SetupWe used the following equipment and procedures to run this benchmark:
Command LineAll tests were run using the command line and the times were extracted from the log files: C:\WCAD\GBRIP\gbr2tiff.exe 325mb.gbr -274x -mm -pack:325mb_150k.tif -dpi:150000 -aw -ram:256 C:\WCAD\GBRIP\gbr2tiff.exe 325mb.gbr -274x -mm -pack:325mb_100k.tif -dpi:100000 -aw -ram:256 C:\WCAD\GBRIP\gbr2tiff.exe 325mb.gbr -274x -mm -pack:325mb_75k.tif -dpi:75000 -aw -ram:256 C:\WCAD\GBRIP\gbr2tiff.exe 325mb.gbr -274x -mm -pack:325mb_190k.tif -dpi:190000 -aw -ram:256 C:\WCAD\GBRIP\gbr2tiff.exe 730mb.gbr -274x -mm -pack:730mb_50k.tif -dpi:50000 -aw -ram:256 C:\WCAD\GBRIP\gbr2tiff.exe 730mb.gbr -274x -mm -pack:730mb_150k.tif -dpi:150000 -aw -ram:256 C:\WCAD\GBRIP\gbr2tiff.exe 730mb.gbr -274x -mm -pack:730mb_75k.tif -dpi:75000 -aw -ram:256 C:\WCAD\GBRIP\gbr2tiff.exe 730mb.gbr -274x -mm -pack:730mb_100k.tif -dpi:100000 -aw -ram:256 C:\WCAD\GBRIP\gbr2tiff.exe 730mb.gbr -274x -mm -pack:730mb_190k.tif -dpi:190000 -aw -ram:256 The output file is a monochrome TIFF image compressed using packbits |
| File Size (MB) |
DPI | RIP Times (min) |
BitMap Size (MB) |
| 325 | 50,000 | 2.5 | 162 |
| 325 | 75,000 | 4 | 333 |
| 325 | 100,000 | 5.5 | 562 |
| 325 | 150,000 | 8.6 | 1,200 |
| 325 | 190,000 | 14.5 | 1,890 |
| File Size (MB) |
DPI | RIP Times (min) |
BitMap Size (MB) |
| 730 | 50,000 | 6 | 221 |
| 730 | 75,000 | 7.5 | 405 |
| 730 | 100,000 | 8.6 | 637 |
| 730 | 150,000 | 16 | 1,285 |
| 730 | 190,000 | 21 | 2,050 |
Input file of 2300 MB cannot be run on a 32 bit version of GBR_RIP due to memory constraints.
| File Size (MB) |
DPI | RIP Times (min) |
BitMap Size (MB) |
| 2300 | 50,000 | ||
| 2300 | 75,000 | ||
| 2300 | 100,000 | ||
| 2300 | 150,000 | ||
| 2300 | 190,000 |
| Download | Price | Rev. History | Example | Benchmark |