This is what it looks like in theory:

The point is that in some spots in the right hand colorspace (CIELab), colors as defined in the RGB space are more crunched together than in other places, for example in the blue area. This effect is now exploited by applying a uniform subdivision on the CIELab color space and interchanging indivual, equally perceived colors to encode a message.

Here is the PDF: Using perceptually uniform color spaces for image steganography

Ingredients:

• 200 g of milk chocolate
• 200 g of dark chocolate
• 100 g of butter
• 175 g of sugar
• 1 egg
• 180 g of flour
• 1 pack of baking soda
• 1/2 teaspoon of salt
• 30 g of cocoa

Chopping, blending and baking action:

1. Chop 120 g of milk chocolate into chunks, melt in a bain-marie
2. Chop remaining chocolate into chunks
3. Mix butter, sugar and egg, add molten milk chocolate
4. Mix flour, soda, salt and cocoa, add to chocolate dough
5. Add chocolate chunks
6. Preheat oven to 175 °C
7. Form cookies, leave space in between on baking sheet
8. Bake each sheet for 10-12 minutes

Hint #1: The amount of dough yields 60 cookies, try 30 cookies (6 x 5) per sheet.

Hint #2: Get the cookies into shape by rolling dough into a ball and then squash it. If you would like to make really fancy cookies, bang a heavy knife from all four sides against the edges, this will give you almost square cookies.

Hint #3: If you feel the urge to prepare twice the amount, use a milk:dark chocolate ratio of 5:3. If you can handle bisection but have trouble performing an accurate cookie dough trisection, try to accept the fact that you may end up with some smaller and some bigger cookies. Get over it.

This recipe is a variant of the original recipe found in the German magazine Lecker, from the Christmas issue 2008, p. 19. In the original recipe, only dark chocolate was used, and butter/vanilla flavor was added. I tried it and changed the recipe. Been there, done that, trust me.

Before going all the way and building my own hip holster, I needed to print the book and so, feeling uncomfortable with the HTML PDF version, I made a LaTeX-powered PDF out of it, and here it is: Why’s Poignant Guide to Ruby (9.8 MiB). Update: Thanks to Alexandre Gravier who made a great contribution by improving the PDF in many ways. Alexandre also set up a GitHub repository.

For a comfortable always-carrying-the-book-around-everywhere-you-go experience, the PDF has a weird paper size of 6.8″ x 8.8″. Copy shops should be able able to cut 100+ pages to a custom size. Otherwise, feel free to scale the printout accordingly.

What’s not in the PDF:

1. The Tiger’s Vest expansion pack
2. The sidebars, as I felt that they would disrupt the reading flow.

Visualization is usually done using arrows in a regular grid, as depicted in Fig. 1. This article is about non-photorealistic rendering of vector fields, giving more intuitive and visually appealing images (see Fig. 2).

Fig. 1 classic visualization with arrows

Fig. 2 sketchy visualization with strokes

A drawback of the sketchy version is that the direction of the flow cannot be discerned.

This work is based upon [1], in which Salisbury et al. provide an interactive system in which the user can define an orientation for every region in a target image, and the program renders the individual strokes.

Thinking about strokes

How can we represent a stroke, anyway? There are several models: a stroke can be a simple straight line, a curved spline, or a bitmap or whatever you can think of. In this project, a stroke is defined as follows:

• It has a center x, y,
• a length and a width and
• an orientation, expressed by an angle between the stroke and the positive x-axis.

Up to here, our stroke is a simple straight line, and now comes the fancy stuff:

• a coefficient curveAmount which describes how much the stroke is bent,
• startWidth and endWidth, in case we want the stroke to be thicker or thinner at one of its ends,
• more variables could be defined here, such as more waviness coefficients or a noise coefficient to give the stroke a dashed or dotted look.

Now this is what an average stroke looks like:

Fig. 3 an average stroke

It has a length of 120, a width of 4, an angle of 5.7°, a curveAmount of 1.0, and a startWidth of 5.0. It was rendered in less than a second with the PCRenderer object from the pcbasics library.

Now that we have a function to render any stroke we want, we can move on to the next part.

Placing the strokes

The next step is to find out where to place strokes. First, a tone image is generated, which is dark where the vectors are long, and bright where less movement is going on. For every pixel, we divide the length of the vector at that pixel by the maximum vector length or the vector field. After this, the image has to be “gamma-corrected”, because simply normalizing the vectors may result in a much too dark or much too bright tone image.

Once we have the tone image, we build a list of pixels which are potential stroke centers. Whether a pixel gets on that list depends on its brightness in the tone image. If it is brighter than some threshold, there is no need to place a stroke on that pixel.

From that list, we randomly choose one pixel, and add a stroke to a global stroke list, centered at that pixel. The stroke is oriented according to the orientation of the vector field, and its length is set to a minimum length. The stroke length is increased until a maximum length is reached or the difference between the field orientation at one of its endpoints and the one at its center exceeds a given tolerance angle (like 10°).

The stroke is rendered as a quick preview without antialiasing. After that, the stroke is blurred (strokes in darker regions are blurred less) and then subtracted from the tone image. All pixels which are affected by the stroke and are now brighter than the brightness threshold are removed from the pixel list until the list is empty. This is when all strokes have been placed.

Fig. 4 initial tone image

Fig. 5 tone image after 100 strokes have been placed

Fig. 6 after 200 strokes

Fig. 7 after 300 stokes (the process finished with 330 strokes)

Fig. 8 the result image is initialized with white

Fig. 9 after 100 strokes

Fig. 10 after 200 strokes

Fig. 11 after 300 stokes

What needs to be done now is to render each stroke in the stroke list, and add it to the result image.

Result images

The images of the electrostatic field and the flow around a cylinder were computed with data sets generated by the mfield program written by Greg Turk and available in his streamline package.

Fig. 12 electrostatic field around a dipole

Fig. 13 electrostatic field around a dipole

Fig. 14 electrostatic field around a dipole

Fig. 2 and the following two images of a fluid flowing through a cell were generated with data sets available on John Burkardt’s website.

The other two images are based on photographs and a vector field which is dependent of the brightness of the tone image (there are three directions in each of the images).

Fig. 15 water flowing from the bottom left-hand to the top right-hand corner

Fig. 16 water flowing through a t-cell

Fig. 17 a portrait of a lady

Fig. 18 the photo for this rendering was taken by Thomas Schallschmidt in Kiev

References

[1] Michael P. Salisbury, Michael T. Wong, John F. Hughes, and David H. Salesin. “Orientable Textures for Image-Based Pen-and-Ink Illustration”. In Turner Whitted, editor, Proceedings of SIGGRAPH′97 (Los Angeles, August 1997), Computer Graphics Proceedings, Annual Conference Series, pages 401-406, New York, 1997. ACM SIGGRAPH.