Silicone casting part 1

I am working on a real-life version of the Wikipedia puzzle globe. After redrawing the virtual one that I was sent by the Wikimedia Foundation, I posed it and animated it: I put the Blender files up at GitHub and the animation is up on YouTube.

That's all very well, but I want to hold it in my hands. I created a 3D printable version and put it up on GitHub, but never got around to testing it. Then I got an email out of the blue from someone at Lumileds who printed it out in 3D as a gift for a colleague:

Apparently it worked as a 3D puzzle, but the letters were so slightly embossed that they were scarcely visible, and one tile was missing from my file. In this case it wasn't really a problem, because it was on the bottom of the globe, so it made a suitable opening for the LED lamp.


This success motivated me to fix those problems and also create two indented versions (done!), and the itch grew to get my own physical copy. 

So I uploaded my model to Shapeways and ordered a copy in "transparent acrylic". It was quite expensive - about €60, but what's life without a few luxuries?

So what does this have to do with Silicone casting? Well, my plan is to make copies of the model once I get it, so I ordered some silicone resin from Amazon and bought some fibreglass resin from my local hardware shop, and while waiting for the model to arrive, I started experimenting with casting:

So far I've had 100% success: I have successfully made a mould of my bike lock's key.

Finished product first:

 The mould itself:

The view down the keyhole:

I'm quite happy with the results. The detail is good, and the rubber is easy to mix and pour. The resin I bought is probably great for automotive repair jobs, but it's really not a casting resin, so I'll probably have to find a proper casting material.

Update: in which I enter the business of counterfeiting.

In preparation for moulding puzzle pieces, I decided to try my luck with a €1 coin. Success!

I first pressed a lump of wondergom into a cardboard mould box, and put the coin on top. I then cast the silicone on top of the coin. After it had set, I turned it around and removed the putty, applied vaseline as a release agent, and cast the other side of the mould. When the second half had set, I used a razor to cut a slot to allow excess resin to escape (on the right-hand side of the bottom half of the mould - on the left in the picture). To make my casting, I mixed some resin, poured it into the bottom half of the mould, and then put the top half on, letting the excess run out. After 30 minutes, my coin was done, with a thin rod sticking out where the relief vent was, and a thin veil of resin surrounding it. I could remove both of these quite easily with my fingernails.

The casting doesn't seem to have shrunk or swollen - it fits exactly onto the coin, so now I'm much more confident in my ability to duplicate my Wikipedia globe when it arrives.

My Scientology Anthology

Wikipedia has quite a bit of good, well-sourced information about Scientology.  I've put together a collection of articles that can be printed as a book. The collection is now up on Wikipedia, and you can download it as a PDF from the links on that page, or even buy it as a printed book. I don't get any money from this, but 10% of the price goes to Wikipedia. Maybe you'd like to buy a few to donate to local school libraries?

10 years 20 000 edits

Ten years ago today, I made my first edit as "Slashme" to Wikipedia, adding an image that I had modified from an existing template into an article about the Oshima Peninsula.

Today, 10 years and 21 minutes later, I made my 20000th edit to a Wikimedia Foundation wiki. That's almost 5½ edits per day. For nostalgia's sake, I edited the same article, this time adding the fact that the Oshima Peninsula is home to Japan's northernmost castle.

An interesting fact that I've noticed is that my edits to the various Wikimedia wikis seem to follow some smooth distribution - I'll figure out later exactly which distribution. Here is the log-scale plot:

So I've made on the order of:

• 2×10³ edits to the English Wikipedia,
• 1×10³ edits to Wikimedia commons,
• 0.5×10³ edits to Meta (I was on the Wikimedia South Africa board for a while),
• 0.3×10³ edits to the German Wikipedia
• 0.2×10³ edits to the English Wiktionary

and less than 100 edits to various other projects.

Based on this count, I'm now a Tutnum of the Encyclopedia.

I have collaborated on a featured picture, successfully submitted one Did You Know (for Promin) and created a parliament diagram tool that is in wide use.

I have also created an animatable, printable version of the Wikipedia globe logo, but because it's copyrighted, you can't use it without the permission of the Wikimedia foundation.

Here is an animation of the globe being built up from component pieces, in my humble opinion, a good metaphor for how the encyclopedia is being built:

Very many editors have made much greater contributions than I have, but as another Wikipedian pointed out to me recently, it's not a race. Any contribution is a good thing, and I'm happy and proud to have done what I have.

Focus stacking with Magic Lantern and Hugin

I have tried focus stacking before, but I've never really focused on the topic, because I don't have a macro lens.  I tried out Jon's extension tubes while on holiday in South Africa last month, and of course that got me back onto focus-stacking.

I found a co-operative subject: a South African 10c piece, and took 18 pictures at different focus points, using Magic Lantern to change the focus automatically. Here are some examples from that series of images:

Because I had taken the pictures in raw mode, I used darktable to export them to TIFF files (not JPEG, because I wanted all the data to be present in the processing steps). I then used the following commands from the hugin/PanoTools suite to create the focus stack:

First I aligned the images, creating a second set of tiff files:

align_image_stack -m -a zframe_ *.tif

This was to make sure the images were aligned. Besides camera movement, which can be eliminated with a solid tripod, there might be side-effects of focusing, depending on the lens geometry.

Next, I created the stacked image:

enfuse -o coin.tiff --exposure-weight=0 --saturation-weight=0 --contrast-weight=1 --hard-mask zframe*

This tells enfuse to blend the images without trying to select pixels based on their exposure (--exposure-weight=0) or saturation (--saturation-weight=0); but by looking at the contrast of the area around the pixel (--contrast-weight=1), without smoothing out the area around the pixel (--hard-mask).

I then took the resulting .tif file to The Gimp to tweak the final exposure and contrast a bit, and to create a JPEG file. This was the result:

I think that worked pretty well, so I might just be buying a set of extension tubes soon.

Extra: as pointed out in the comments, one can automate this a bit more if you're not going beyond default settings. For example, with minimal effort you could create a very simple-minded script that looks like this:

#!/bin/bash
#Batch-export tiffs from raw images:
for i in *; do darktable-cli $i $i.tif; done
#Align the image stack:
align_image_stack -m -a zframe_ *.tif
#Blend the image stack:
enfuse -o output.tiff --exposure-weight=0 --saturation-weight=0 --contrast-weight=1 --hard-mask zframe*
#Make a JPEG from the stack (note: this is for a medium sized file - tweak the size and quality to taste)
convert output.tiff -quality 75 -resize 4000x4000 output.jpg

Make it executable and put it somewhere that's in your path, and call it something like "focusstacker". Then you can just go to where you've put the raw files and type "focusstacker" and let it run. In my case, it gave the following result:

#NoFilter (except for all the default ones in the camera and the software I used…)

I'd normally want to edit this in The Gimp before publishing anyway, because I like a bit more contrast, and in this case I also applied an unsharp mask, but because I didn't do anything in Darktable this time, I'd have gotten exactly the same result as I posted above if I'd skipped the last step in the script and taken the output tiff into The Gimp.

The pen is mightier than the sword.

Yesterday, Muslim extremists shot and killed a maintenance worker, two police officers, a proofreader, three journalists and five cartoonists.  You can read about this murder on Wikipedia.  They were killed because they worked for the paper Charlie Hebdo, who published the Jyllands-Posten cartoons of Muhammed.

Anyone who believes that a cartoon can be worse than murder, and who then plans and executes the murder of people who draw and publish certain cartoons does not deserve a place in society. A religious community which tolerates this kind of extremism is a danger to all of us. Muslim organisations worldwide have denounced these murders, and any who have not done so are enemies of peace.

The "Banksy" instagram account (not the real Banksy) summed it up so well:

As Salman Rushdie said: "I stand with Charlie Hebdo, as we all must, to defend the art of satire, which has always been a force for liberty and against tyranny, dishonesty and stupidity, [-] religious totalitarianism has caused a deadly mutation in the heart of Islam and we see the tragic consequences in Paris today."

To remind anyone who thinks that violence will silence anyone, here are those cartoons:

My proposed logo for the European Go Federation

This is my entry into the European Go Federation's logo design contest.  Besides the logo, I'm presenting a 3D concept representing the core idea, and various levels of design for use in different settings.  I'm also presenting a few concept documents to show how the proposed logo would be used in practice.

If my design is selected, I am willing to work with the EGF and any external designers they might select to refine the design if required. For example, if the map of Europe is considered objectionable it can be removed or modified. I will also provide:

• A blender file with the 3D design, to be used for derivative logos
• Pictures of the full-colour view of the design at various resolutions, to be used on websites and on marketing materials
• Inkscape SVG vector versions of the design with various levels of detail, down to simple line-art examples
• Concept documents illustrating the use of the logo, which can be used by other designers to prepare stationery, business cards and promotional material.

The overall concept

The design features white go stones with the letters E, G, and F, partially surrounding a black go stone with a rough map of Europe.  Just below the black stone is a star point.  This is intentionally a simple layout. It incorporates the abbreviated name of the organisation, a depiction of the game of go, and a recognisable depiction of Europe.

For a more complete concept, the full name of the organisation can be included below the stones. Here is one possible rendering, with the map of Europe and the name of the organisation rendered in a brushed metallic texture:

Although not the logo itself, this 3D aspect of the design can be used on websites or incorporated into the design of trophies, or added to videos; here, for example, the 3D concept is overlaid onto a video of a real go-board:

From concept to logo

To develop a logo from this design, however, it needs to be simplified. Here are two stages of simplification.  First, a grayscale version with no background, black 2D text, and the goban's lines cropped to form a visually appealing shape:

This is closer to a logo, but it is still not very clear, and it is not yet suitable for use at small sizes, or on documents which are to be printed in black and white, photocopied, etc. For the next level of simplification, here is a version without the text, and with the go stones shown as black and white line-art objects:

Note that this logo will still be recognisable at low resolutions, and will be quite resistant to deterioration when photocopied. The background is transparent, but the white go-stones remain white.

Here is an example at extremely low resolution:

This is a 64x64 image, slightly cropped, and still the overall design is recognisable.

The full name of the Federation can be added at any position around the logo, depending on how it is used in a document.  For example, top right:

or bottom left:

The typeface that was selected for the logo (including the letters on the go-stones) is Crimson, a free and open-source font family that is in continuous development.  Crimson supports a wide range of European languages, including Greek and Russian. This means that it can be used to generate documents and designs that harmonise with the logo itself.

Use of the logo

Here are three examples of how the logo might be used in stationery:

Business cards

Game record sheets

Official letters

Converting SVG files in bulk and parallelizing for loops

What I learned about Inkscape today: it's easy and quick to export files from the command line, and for testing purposes, it has a rather cool interactive command line mode, accessed by the command "inkscape --shell"

I found out about this by reading Inkscape's man page to find out how to export files from the command line.  There I found this:

--shell

With this parameter, Inkscape will enter an interactive command line shell mode. In this mode, you type in commands at the prompt and Inkscape executes them, without you having to run a new copy of Inkscape for each command. This feature is mostly useful for scripting and server uses: it adds no new capabilities but allows you to improve the speed and memory requirements of any script that repeatedly calls Inkscape to perform command line tasks (such as export or conversions). Each command in shell mode must be a complete valid Inkscape command line but without the Inkscape program name, for example "file.svg --export-pdf=file.pdf".

I also found out that to export the page area of a file to a pdf, I can use the command "inkscape file.svg --export-area-page --export-pdf=file.pdf". (or, a bit shorter, "inkscape file.svg -C -A=file.pdf").

OK, let's see how this works. First I pull my list of svg files into vim:

$ ls *svg | vim -

Then, in vim, I add the command line parameters to export the whole page to the respective pdf file, giving a list that I can copy and paste. That's a one-liner:

:%s/\(.*\).svg/\1.svg -C -A=\1.pdf/

In another xterm, I enter inkscape interactive mode and see this:

$ inkscape --shell
Inkscape 0.48.4 r9939 interactive shell mode. Type 'quit' to quit.
>

I paste the first command from my list and check that it works out OK. All good, so paste the rest and all my files are converted within a few seconds.  If I weren't curious and procrastinatory, I'd have stopped here, but now I want to know what other options I have for bulk export, and how they stack up against each other.

First test: just string them together on the command line. Back to vim, type "vipj" to gather all my commands into one line, add the magic words "time inkscape" to the start of the line and paste into bash:

$ time inkscape egflitetext.svg -C -A=egflitetext.pdf EGFLogoMonoPathsBusinessCard.svg -C -A=EGFLogoMonoPathsBusinessCard.pdf [etc. etc. - long command line snipped here]

real    0m3.298s
user    0m3.132s
sys     0m0.144s

So exporting 12 svgs to pdf took just over 3 seconds.  Not bad, but a bit clunky if I want do do this frequently. I spent some time trying to figure out how to make find or xargs generate this commandline, but I can't figure it out.  I could probably do it in sed, but for my purposes that's just a bit too conceptually complex, so instead I used this loop:

$ time (for i in *svg ; do inkscape $i -C -A=$i.pdf; done)

real    0m5.512s
user    0m5.080s
sys     0m0.412s

That's 67% slower, but much more convenient. But wait, I have a 4 core processor in my laptop, so why not let them all work at once? xargs can run jobs in parallel.

 $ time (find . -maxdepth 1 -name "*svg" -print0 | xargs -0 -P4 -I % inkscape % -C -A=%.pdf)

real    0m2.572s
user    0m8.360s
sys     0m0.460s

Wow, quite a lot quicker when we do things in parallel! But hang on, if I detach the jobs in the for loop, they'll also run in parallel.  Let's see how that performs:

$ time (for i in *svg ; do inkscape $i -C -A=$i.pdf & done)

real    0m0.007s
user    0m0.000s
sys     0m0.004s

Oh, right: these processes run as separate jobs, so their time isn't counted towards the total. Bright ideas to profile this are welcome! It felt really quick, and it's simpler to remember than the find | xargs solution, but of course if I had hundreds of files to convert instead of a dozen, it might lock up my system, so then xargs would be the way to go.

As we all know, Inkscape isn't the lightest svg converter out there: librsvg (based on the cairo library since 2005) has a utility called rsvg-convert which is specially built for this task. Let's give it a spin. For comparison, I'll run the jobs first in series and then in parallel:

$ time (for i in *svg ; do rsvg-convert $i -f pdf > $i.pdf; done)

real    0m2.976s
user    0m2.772s
sys     0m0.160s

$ time (find . -maxdepth 1 -name "*svg" -print0 | xargs -0 -P4 -I % rsvg-convert % -f pdf > %.pdf)
 
real    0m1.341s
user    0m4.460s
sys     0m0.208s

Even when called once for each file, the librsvg tool easily outperforms Inkscape called as a single instance.  These svgs were originally made in Inkscape, so librsvg isn't guaranteed to give the same output, but when I compared the results, the pdfs from Inkscape's export and rsvg-convert had almost exactly the same file size, and the only difference I could see in the pdfs was the scaling: in evince, when the two pdfs were the same size on the screen, they had different zoom levels.

Even though librsvg is faster, I'm going to keep using Inkscape: even though I couldn't spot any differences between the output files, I don't want to have to worry about it. This would be different if I were running a server.

Of course, in all my examples except the one with the long command line, the filenames end with .svg.pdf .  If I want to fix that, it's a simple matter of typing "rename -f 's/.svg//' *svg.pdf"

Relevant XKCD:

Is it worth the time?

Automation

The General Problem