Category: Software

Running more grayscale images through the cookie cutter process revealed some problems and solutions…

It seems OpenSCAD (or the underlying CGAL library) chokes while creating a 3D surface from a bitmap image more than about 350-ish pixels square: it gradually blots up all available memory, fills the entire swap file, then crashes after a memory allocation failure. As you might expect, system response time rises exponentially and, when the crash finally occurs, everything else resides in the swap file. The only workaround seems to be keeping the image under about 330-ish pixels. That’s on a Xubuntu 12.04 box with 4 GB of memory and an 8 GB swap partition.

So I applied 2.5 pixel/mm scaling factor to images intended for a 5 inch build platform:

317 pixel = (5 inch × 25.4 mm/inch) * 2.5 pixel/mm

Any reasonable scaling will work. For smaller objects or platforms, use 3 pixel/mm or maybe more. If you have a larger build platform, scale accordingly. I baked the default 2.5 factor into the Bash script below, but changing it in that one spot will do the trick. Remember that you’re dealing with a 0.5 mm extrusion thread and the corresponding 1 mm minimum feature size, so the ultimate object resolution isn’t all that great.

Tomorrow I’ll go through an image preparation checklist. However, given a suitable grayscale height map image as shown above, the rest happens automagically:

./MakeCutter.sh filename.png

That process required some tweakage, too …

Auto-cropping the image may leave empty borders: the canvas remains at the original size with the cropped image floating inside. Adding +repage to the convert command shrinkwraps the canvas around the cropped image.

If the JPG file of the original scanned image has an embedded comment (Created by The GIMP, for example), then so will the PNG file and so will the ASCII PGM files, much to my astonishment and dismay. The comment line (# Created by The GIMP) screwed up my simplistic assumption about the file’s header four-line header layout. The +set Comment squelches the comment; note that the word Comment is a keyword for the set option, not a placeholder for an actual comment.

It turns out that OpenSCAD can export STL files that give it heartburn when subsequently imported, so I now process the height map and outline images in the same OpenSCAD program, without writing / reading intermediate files. That requires passing all three image dimensions into the program building the cutter and press, which previously depended on the two incoming STL files for proper sizing. This seems much cleaner.

The original program nested the cookie press inside the cutter on the build platform as a single STL file, but it turns out that for large cutters you really need a T-shaped cap to stabilize the thin plastic shape; the press won’t fit inside. The new version produces two separate STL files: one for the press and one for the cutter, in two separate invocations. The command-line options sort everything out on the fly.

Because the cutter lip extends outward from the press by about 6 mm, you must size the press to keep the cutter completely on the build platform. The 5 inch outline described above produces a cutter that barely fits on a 5.5 inch platform; feel free to scale everything as needed for your printer.

The time commands show that generating the press goes fairly quickly, perhaps 5 to 10 minutes on a 3 GHz Core 2 Duo 8400. The multiple Minkowski operations required for the cutter, however, run a bit over an hour on that machine. OpenSCAD saturates one CPU core, leaving the other for everything else, but I wound up getting a cheap off-lease Dell Optiplex 760 as a headless graphics rendering box because it runs rings around my obsolete Pentium D desktop box.

The MakeCutter.sh Bash script controlling the whole show:

#!/bin/bash
DotsPerMM=2.5
MapHeight=5
ImageName="${1%%.*}"
rm ${ImageName}_* ${ImageName}-press.stl ${ImageName}-cutter.stl
echo Normalize and prepare grayscale image...
convert $1 -type Grayscale -depth 8 -auto-level -trim +repage -flip -flop -negate +set Comment ${ImageName}_prep.png
echo Create PGM files...
convert ${ImageName}_prep.png -compress none ${ImageName}_map.pgm
convert ${ImageName}_prep.png -white-threshold 1 -compress none ${ImageName}_plate.pgm
echo Create height map data files...
ImageX=`identify -format '%[fx:w]' ${ImageName}_map.pgm`
ImageY=`identify -format '%[fx:h]' ${ImageName}_map.pgm`
echo Width: ${ImageX} x Height: ${ImageY}
cat ${ImageName}_map.pgm | tr -s ' \012' '\012' | tail -n +5 | column -x -c $((8*$ImageX)) > ${ImageName}_map.dat
cat ${ImageName}_plate.pgm | tr -s ' \012' '\012' | tail -n +5 | column -x -c $((8*$ImageX)) > ${ImageName}_plate.dat
echo Create cookie press...
time openscad -D BuildPress=true \
-D fnPlate=\"${ImageName}_plate.dat\" \
-D fnMap=\"${ImageName}_map.dat\" -D Height=$MapHeight \
-D ImageX=$ImageX -D ImageY=$ImageY -D DotsPerMM=$DotsPerMM \
-o ${ImageName}-press.stl Cookie\ Cutter.scad
echo Create cookie cutter...
time openscad -D BuildCutter=true \
-D fnPlate=\"${ImageName}_plate.dat\" \
-D ImageX=$ImageX -D ImageY=$ImageY -D DotsPerMM=$DotsPerMM \
-o ${ImageName}-cutter.stl Cookie\ Cutter.scad

The Cookie Cutter.scad OpenSCAD source code:

// Cookie cutter from grayscale height map using Minkowski sum
// Ed Nisley KE4ZNU - November 2012

//-----------------
// Cookie cutter files

BuildPress = false;						// override with -D Buildxxx=true
BuildCutter = false;

fnMap = "no_map.dat";					// override with -D 'fnMap="whatever.dat"'
fnPlate = "no_plate.dat";				// override with -D 'fnPlate="whatever.dat"'

DotsPerMM = 2.5;						// overrride with -D DotsPerMM=number

MapHeight = 5.0;						// overrride with -D MapHeight=number

ImageX = 10;							// overrride with -D ImageX=whatever
ImageY = 10;

MapScaleXYZ = [1/DotsPerMM,1/DotsPerMM,MapHeight/255];
PlateScaleXYZ = [1/DotsPerMM,1/DotsPerMM,1.0];

echo("Press File: ",fnMap);
echo("Plate File: ",fnPlate);

echo("ImageX:",ImageX," ImageY: ", ImageY);
echo("Map Height: ",MapHeight);
echo("Dots/mm: ",DotsPerMM);
echo("Scale Map: ",MapScaleXYZ,"  Plate: ",PlateScaleXYZ);

//- Extrusion parameters - must match reality!

ThreadThick = 0.25;
ThreadWidth = 2.0 * ThreadThick;

//- Cookie cutter parameters

TipHeight = IntegerMultiple(8.0,ThreadThick);		// cutting edge
TipWidth = 5*ThreadWidth;

WallHeight = IntegerMultiple(4.0,ThreadThick);		// center section
WallWidth = IntegerMultiple(4.0,ThreadWidth);

LipHeight = IntegerMultiple(2.0,ThreadThick);		// cutter handle
LipWidth = IntegerMultiple(3.0,ThreadWidth);

PlateThick = IntegerMultiple(4.0,ThreadThick);	// solid plate under press relief

//- Useful info

function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);

Protrusion = 0.1;						// make holes & unions work correctly

MaxConvexity = 5;						// used for F5 previews in OpenSCAD GUI

ZFuzz = 0.2;							// numeric chaff just above height map Z=0 plane

//-----------------
// Import plate height map, slice off a slab to define outline

module Slab(Thick=1.0) {
	intersection() {
		translate([0,0,Thick/2])
			cube([2*ImageX,2*ImageY,Thick],center=true);
		scale(PlateScaleXYZ)
			difference() {
				translate([0,0,-ZFuzz])
					surface(fnPlate,center=true,convexity=MaxConvexity);
				translate([0,0,-1])
					cube([2*ImageX,2*ImageY,2],center=true);
			}
	}
}

//- Put peg grid on build surface

module ShowPegGrid(Space = 10.0,Size = 1.0) {

	Range = floor(50 / Space);

	for (x=[-Range:Range])
	  for (y=[-Range:Range])
		translate([x*Space,y*Space,Size/2])
			%cube(Size,center=true);
}

//- Build it

//ShowPegGrid();

if (BuildPress) {
	echo("Building press");
	union() {
		Slab(PlateThick + Protrusion);
		translate([0,0,PlateThick])							// cookie press height map
			scale(MapScaleXYZ)
			difference() {
				translate([0,0,-ZFuzz])
					surface(fnMap,center=true,convexity=MaxConvexity);
				translate([0,0,-1])
					cube([2*ImageX,2*ImageY,2],center=true);
			}
	}
}

if (BuildCutter) {
	echo("Building cutter");
	union() {
		difference() {
			union() {										// stack cutter layers
				translate([0,0,(WallHeight + LipHeight - 1)])
					minkowski() {
						Slab(TipHeight);
						cylinder(r=TipWidth,h=1);
					}
				translate([0,0,LipHeight - 1])
					minkowski() {
						Slab(WallHeight);
						cylinder(r=WallWidth,h=1);
					}
			}
			translate([0,0,-1])								// punch central hole for plate
				Slab(TipHeight + WallHeight + LipHeight + 2);
		}
		minkowski() {										// put lip around base
			difference() {
				minkowski() {
					Slab(LipHeight/3);
					cylinder(r=WallWidth,h=LipHeight/3);
				}
				translate([0,0,-2*LipHeight])
					Slab(4*LipHeight);
			}
			cylinder(r=LipWidth,h=LipHeight/3);
		}
	}
}

And then it Just Works…

That process produces a grayscale height map PNG image in the proper orientation:

OpenSCAD, however, requires a flat ASCII data file to build a 3D model, as described there.

It turns out that a PGM (“Portable Graymap”) file is almost exactly what we need: a fixed format header in ASCII text, followed by the pixel data in either ASCII or binary. To get an ASCII-formatted PGM file from that PNG image:

convert jellyfish_prep.png -compress None jellyfish.pgm

The top of the PGM file looks like this:

P2
149 159
255
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255
... more data ...

The data isn’t in the XY array layout that OpenSCAD expects; It Would Be Very Nice If OpenSCAD could read PGM files, including the header describing the array size, but it doesn’t. Fortunately, some Bash-fu can handle the reformatting.

First, store the number of pixels along the X axis in a Bash variable:

ImageX=`identify -format '%[fx:w]' ${imagename}_prep.png`

Note the backticks around the whole mess that tell Bash to execute what’s inside and return the value. The -format operation returns the width as an integer, which is what we need.

Now, returning our attention to the PGM file, convert multiple blanks and line ends to single line ends, thus putting one entry on each output line with no other whitespace:

cat filename.pgm | tr -s ' \012' '\012'

Nota bene: there’s a leading blank in the first character string and the escape sequences should read “reverse-slash zero one two” to denote the Unix-style line end character (ASCII 10 = newline). I think the meta-markup works around the usual WordPress formatting, but ya never know what can go wrong.

The first four lines then contain the magic number, X size, Y size, and the maximum data value, respectively:

P2
149
159
255

Those values are all known, because:

• The magic number is P2 for ASCII PGM files. It would be useful to verify this, but …
• The XY values correspond to the image size
• The maximum data value will be 255 because of  the auto-level operation applied to the image’s 8-bit grayscaleness

Strip off the first four lines and wrap the remaining data into an array corresponding to the image size:

tail -n +5 | column -x -c $((8*${ImageX})) > filename.dat

The $((8*${ImageX)) magic comes from the way the column command works: it’s right-aligning each data values in an 8 character column, so you specify the total width of the result in character columns. Think of the parameter as specifying the screen width and you’ll be on the right track.

That fits neatly into a single line of Bash gibberish:

cat filename.pgm | tr -s ' \012' '\012' | tail -n +5 | column -x -c $((8*${ImageX})) > filename.dat

The first complete line of that file goes on basically forever, but it actually has the right stuff. You can examine it thusly:

head -1 filename.dat

The file should then Just Work when sucked into OpenSCAD with the surface() function:

surface("filename.dat",center=true,convexity=10);

And, indeed, it does:

Note that it’s oriented with the head in the +Y direction, the tentacles (or whatever) in the -Y direction, and the freckle over the eye on the proper side. Here’s the original PNG image of the cookie for reference:

Using center=true centers the object on the XY plate, but the base of the solid remains at Z=-1. That makes some sense, as the “solid” part of the model lies below the Z values set by the data: the model includes a one unit thick slab below Z=0 for all points.

The convexity=10 parameter helps OpenSCAD’s quick rendering code (invoked by hitting F5 in the GUI) determine when it can stop looking for intersections between the visible ray and the object. It doesn’t affect the F6 CGAL compilation & export to STL. Because this routine will eventually be used only from the command line, the value doesn’t matter.

That works and the height map looks OK, but the model is too large in all directions and the slab below Z=0 has got to go. But it’s looking good…

While pondering the notion of making cookie cutters, it occurred to me that the process could be automated: a grayscale height map image of the cookie should be enough to define the geometry. The existing height map solutions (like William Adams’s fine work) seem entirely too heavyweight, what with custom Windows or Java programs and suchlike. Some doodling indicates that a simpler solution may suffice for my simple needs, although the devil always hides in the details.

The overall problem with a cookie press involves producing a non-rectangular solid with a bumpy upper surface corresponding to the grayscale values of an image: dark pixels = low points of the surface, light pixels = peaks. The image size controls the XY extent of the solid and the pixel values control the Z, with some known value (likely either black or white) acting as a mask around the perimeter. Given such a solid, you can then wrap a cutter blade and handle around the outline, much as I did for the Tux cutter.

OpenSCAD has a lightly documented surface() function that reads an ASCII text file consisting of an array of numeric values. Each array element defines a 1 × 1 unit square of the resulting 3D object; the example in the doc shows a 10 x 10 array producing a 10 x 10 unit object. Each numeric value sets the height of the surface at the center of the square.

This array, slightly modified from the one in the doc, shows how that works:

9 9 8 7 6 5 5 5 5 1
9 9 7 6 6 4 3 2 1 0
8 7 6 6 4 3 2 1 0 0
7 6 6 4 3 2 1 0 0 0
6 6 4 3 2 1 1 0 0 0
6 6 3 2 1 1 1 0 0 0
6 6 2 1 1 1 9 9 9 0
6 6 1 0 0 0 9 8 9 0
3 1 0 0 0 0 9 9 9 0
9 8 7 6 5 4 3 2 1 0

Feeding that into this OpenSCAD program:

module ShowPegGrid(Space = 10.0,Size = 1.0) {

  Range = floor(50 / Space);

	for (x=[-Range:Range])
	  for (y=[-Range:Range])
		translate([x*Space,y*Space,Size/2])
		  %cube(Size,center=true);

}

ShowPegGrid();
surface("/tmp/test.dat",center=true,convexity=10);

Produces this object, surrounded by a few non-printing 1 unit alignment cubes on the Z=0 plane for scale:

Some things to note:

• The text array looks like it builds downward from the upper left, but the solid model builds from the origin toward the +X and +Y directions, with the first line of the array appearing along Y=0. This reverses the object along the Y axis: the first line of the array is the front side of the object.
• The “center=true” option centers the object in XY around the Z axis, with a 1 unit thick slab below the entire array; the top surface of that slab (at Z=0) represents the level corresponding to 0 elements in the array.
• Each array element becomes a square one unit on a side; the RepRap software chain regards units as millimeters
• The center point of each element’s square is at the nominal height
• The Z coordinate of the edges of those squares linearly interpolate between adjacent centers
• Vertical edges become slanted triangular facets

Remember that STL files contain a triangular tessellation (or whatever you call it in 3D) of the object surface, which means rectangles aren’t natural. The edge interpolation make the whole thing work, because an array of pure square pillars probably won’t be a 2-manifold object: some pillars would share only a common vertical edge. The interpolation does, however, produce a bazillion facets atop the object.

So the problem reduces to generating such an array from a grayscale image, for which some ImageMagick and Bash-fu should suffice, and then manipulating it into a model that will produce a cookie press and cutter. More on that tomorrow…

[Update: image file, height map file, solid modeling, printing]