Since I’m shifting the letters 1/3 pixel at a time and not as whole pixels, the actual pixels used for rendering the text constantly change color, coming back to the same color every 3 frames. My speculation is, this constant shifting of colors improves the clarity of the text.

An artifact of subpixel rendering is colored halos around letters due to the fact that colored pixels are required to render even completely black text. However, since the colored pixels of the scrolltext keep taking on different colors, they’re just being perceived as tones of gray. The colored halos are barely noticeable when the text is on the move.

This effect is not evident when anti-aliasing (for eliminating color fringing) is fully enabled. When the anti-aliasing level is changed, the effect can be observed on the intermediate buffer that I use as a speed optimization and kept visible for the purpose of this demo. Since the letters on the intermediate buffer are static, the colored halo effect is noticeable:

With partial anti-aliasing, the halos are going to get worse:

Finally with anti-aliasing turned off, it’s a whole mess of bright colors, making the text almost completely unreadable:

However, if you look at the scrolling text at all anti-aliasing levels, you’ll observe that even when anti-aliasing is completely turned off, the color halo lessens and what you see is mostly a horribly flickering black text.

This is a programming experiment that dates back to 2002. Having played around with POP3 for a while (see E-Res-Q), I just wanted to prove to myself that POP3/FTP protocol translation could work (and I guess I also had more free time back then). Burrito is certainly not a utility that would appeal to the general public, due to its obscure function. The only real-life scenario I can think of is an employee trying to circumvent the company firewall that blocks POP3 traffic (which is something I’ve experienced first-hand).

Very Brief Usage Instructions

The About tab has an Check for update button which takes you back to this site to tell you that you’re using the most recent version of Burrito (since I currently don’t have any intentions of releasing updates).

In the Options tab, you can determine how you’ll be passing the POP3 username and server to your FTP server. The password that you use for the FTP connection is used as the POP3 server password, so Burrito doesn’t have to know your password in advance. However, the POP3 username and password must be combined and used as the FTP username. You can change the username-server separator here (defaults to “\”).

You can also configure how filenames for individual messages are to be composed. The default is to use the name of the sender, followed by a dash, followed by the message subject. The default file extension is “.eml”. After copying files to your local disk, you should be able to simply double click to view them in Outlook Express. Use “.msg” etc. to match whatever e-mail client you’re actually using.

By default, Burrito listens on port 21, on all IP addresses. The Security tab allows you to tweak the FTP server listen settings.

Here’s how a typical FTP client configuration looks like (I use Total Commander):

And here’s how your e-mail messages appear as files in your FTP client:

For every FTP connection you establish with Burrito, it will typically open a POP3 connection to the server that specified in the FTP username. It has a connection sharing feature for when multiple FTP clients access the same POP3 account.

Because Burrito doesn’t download entire messages until you attempt to do an FTP-copy, simply listing and deleting messages are typically faster than a normal POP3 client. Therefore, it can actually be used for cleaning up a POP3 account after it gets choked by a huge messages or spam.

Cool? I guess so. Pointless? Probably :)

Known Issues

• After the system wakes up from hibernation/suspension, the FTP listen port becomes unresponsive. Momentarily chaning the FTP server listen mode in the Security tab to some other mode may (depending on the mode change) reset the listen port.

You can probably figure it out on your own by playing with the checkboxes at the lower left corner of the pop-up, but read on to find out how it all works.

The demo renders only regular polygons, but any convex, irregular, closed area can be rendered.

We start with a list of vertices:

Then we find the bounding rectangle (minimum and maximum x and y coordinates) of the vertices and apply the fill <div> with either a solid color or a background image:

Now the fill rectangle has to be masked to leave behind our filled polygon. Notice that each side of a polygon can be fitted with a right angle triangle:

For vertices that lie on the bounding (or fill) rectangle, the right angle triangles will be flush with the sides of the bounding rectangle (I, II and III above). For vertices that fall inside the bounding rectangle, the right angle triangles (IV and V) will leave behind rectangles (VI). The number of rectangles depends on the number of sides of the polygon and also its orientation.

What we want to do now is to place triangles and rectangles over the numbered areas so that only the actual polygon will remain visible. For rectangular masks, absolutely positioned <div> elements (with the background color) will do the trick, but for triangles we’ll have to think about the rectangles that bound them:

Since we can’t have an infinite supply of right angle triangle images at all sorts of slants, we can simply resize isosceles right angle triangles to get any angle variations we want. We will need at least four different triangles, with their right angles at each corner. The filled parts of the triangles should be of the background color and the rest should be transparent:

Since these triangles will be resized, it’s important to make them sufficiently large to minimize aliasing. The images used in the demo are 600 x 600 in dimensions. Once the remaining areas are masked with the triangular masks, all we’re left with is our polygon:

The edges may look jagged a bit, but when the polygon is animated, it’s barely noticeable.

Concave areas can be filled if the angles don’t cause overlapping of the masks. I’ve played around with drawing n-spoked stars instead of convex polygons, but couldn’t perfect the method to entirely avoid overlaps. The technique can also be used for rendering circles, since as the side count grows, polygons eventually start to look like circles.

Quoting from A Multifocus Method for Controlling Depth of Field by Paul Haeberli:

When a photograph is taken with a camera, the lens is focused at a particular distance. Objects nearer or farther than this focal distance will appear blurred. By changing the focus of the lens, near objects or distant objects can be made to appear in sharp focus. If you want to create an image where distant objects as well as close objects are in focus, two or more images can be merged together to make an image with increased depth of field…

Instead of creating a single, in-focus image from two images, I wanted to see how a smooth morphing effect would look like.

Hovering over the image controls how much each of the two images contributes to the final image. Vertical movement controls the contribution amount of the image where the bottle at the front in-focus. Horizontal movement controls the image where the bottle at the back is in-focus.

To get a natural, focus-back-and-forth experience, move the mouse from the top right corner to the bottom left corner and back.

This Java applet was done using Processing. The source is below. You can also download the PDE file.

/*
   Depth of Field

   by Ates Goral
   Nov 6, 2003

   Based on
   "A Multifocus Method for Controlling Depth of Field"
   by Paul Haeberli
   http://www.sgi.com/grafica/depth/index.html

   The images that are used are taken from the original
   document.

   Instructions:
   - Roll over the photograph to bring the near and far
     portions in and out of focus.
   - Vertical movement controls the near portion.
   - Horizontal movement controls the far portion.
*/

// Globals
PImage imgNear, imgFar, imgSel, imgTxtNear, imgTxtFar;
boolean bInitial; // Initial paint?

void setup()
{
    size(250, 250);
    cursor(CROSS);

    imgNear = loadImage("near_in_focus.gif");
    imgFar = loadImage("far_in_focus.gif");
    imgSel = loadImage("selector.gif"); // Pixel selector

    imgTxtFar = loadImage("txt_far.gif");
    imgTxtNear = loadImage("txt_near.gif");

    // Thin frame around the photograph
    stroke(0);
    noFill();
    rect(0, 0, 240, 240);

    // Small decorative rectangle at bottom right
    noStroke();
    fill(0);
    rect(241, 241, 9, 9);

    bInitial = true; // Enforce initial paint
}

void loop()
{
    // Don't bother if the mouse hasn't moved
    if (pmouseX == mouseX && pmouseY == mouseY && !bInitial)
        return;

    float nearFade, farFade;

    if (!bInitial) // If not doing the initial paint, use
                   // mouse input
    {
        nearFade = mouseY / 239.0;
        farFade = mouseX / 239.0;
    }
    else // If doing the inital paint, assume 50% fade
    {
        nearFade = 0.5;
        farFade = 0.5;
        bInitial = false;
    }

    for (int y = 0; y < 239; y++)
    {
        int offY = y * 239;

        for (int x = 0; x < 239; x++)
        {
            int offXY = offY + x; // Pixel offset

            float briNear = (imgNear.pixels[offXY] & 0xff) /
                255.0;
            float briFar = (imgFar.pixels[offXY] & 0xff) /
                255.0;
            int sel = imgSel.pixels[offXY] & 1;

            // Calculate brightness - this expression can
            // probably be simplified, but then it would
            // become harder to follow...
            float bri = (briNear * nearFade +
                briFar * (1 - nearFade)) * (1 - sel) +
                (briFar * farFade + briNear *
                (1 - farFade)) * sel;

            // Plot using a sepia hue
            set(x + 1, y + 1, color(228 * bri, 212 * bri,
                180 * bri));
        }
    }

    // Vertical/near fade
    fill(255 * farFade);
    rect(241, 0, 9, 241);

    // Horizontal/far fade
    fill(255 * nearFade);
    rect(0, 241, 241, 9);

    // Put the text, centered
    image(imgTxtNear, (241 - imgTxtNear.width) >> 1, 242);
    image(imgTxtFar, 243, (241 - imgTxtFar.height) >> 1);
}

Quoting from Synthetic Lighting for Photography by Paul Haeberli:

Light from different light sources add together to illuminate objects in a scene. We can use this super-position principle to modify the lighting of a scene after it has been photographed…

I’ve created an interactive application with three light sources with different colors.

Hover over the image to change the intensities of the three light sources.

This Java applet was done using Processing. The source is below. You can also download the PDE file.

/*
   Multiple Synthetic Lights

   by Ates Goral
   Sometime, 2003

   Based on
   "Synthetic Lighting for Photography"
   by Paul Haeberli
   http://www.sgi.com/misc/grafica/synth/index.html

   Instructions:
   - Roll over the photograph to change the intensities of
     the three different light sources.
*/

// Globals
PImage imgAmb, imgA, imgB, imgC;
float[] ambs, diffA, diffB, diffC;
color clrAmb, clrA, clrB, clrC;
boolean bInitial; // Initial paint?

// Calculate the difference between an image and the ambient
// image
void genDiff(PImage img, float[] arr)
{
    for (int y = 0; y < 250; y++)
    {
        for (int x = 0; x < 250; x++)
        {
            int offs = y * 250 + x;

            float sub = red(img.pixels[offs]) / 255.0 -
            ambs[offs];

            if (sub < 0)
            {
                sub = 0;
            }

            arr[offs] = sub;
        }
    }
}

void setup()
{
    size(250, 250);
    cursor(CROSS);

    imgAmb = loadImage("lighting-11.jpg"); // Ambient
    imgA = loadImage("lighting-09.jpg");
    imgB = loadImage("lighting-10.jpg");
    imgC = loadImage("lighting-14.jpg");

    ambs = new float[250 * 250];
    diffA = new float[250 * 250];
    diffB = new float[250 * 250];

    diffC = new float[250 * 250];

    for (int y = 0; y < 250; y++)
    {
        for (int x = 0; x < 250; x++)
        {
            int offs = y * 250 + x;
            // Normalize to 1.0
            ambs[offs] = red(imgAmb.pixels[offs]) / 255.0;
        }
    }

    genDiff(imgA, diffA);
    genDiff(imgB, diffB);
    genDiff(imgC, diffC);

    // Colors
    clrAmb = #202A35;
    clrA = #7F1025;
    clrB = #8A8768;
    clrC = #291D80;

    bInitial = true; // Enforce initial paint
}

void loop()
{
    // Don't bother if the mouse hasn't moved
    if (pmouseX == mouseX && pmouseY == mouseY && !bInitial)
    {
        return;
    }

    float mX, mY;

    if (!bInitial) // If not doing the initial paint,
                    // use mouse input
    {
        mX = mouseX / 250.0;
        mY = mouseY / 250.0;
    }
    else // If doing the inital paint, assume 50% fade
    {
        mX = 0.5;
        mY = 0.5;
        bInitial = false;
    }

    // Coefficients
    float coeffA = pow((1 - mX), 0.5);
    float coeffC = pow(mX, 0.5);
    float coeffB = (1 - mY);

    for (int y = 0; y < 250; y++)
    {
        for (int x = 0; x < 250; x++)
        {
            int offs = y * 250 + x;
            float amb = ambs[offs];

            // Contribution of each light source
            float contrA = diffA[offs] * coeffA;
            float contrB = diffB[offs] * coeffB;
            float contrC = diffC[offs] * coeffC;

            // Calculate components
            float cmpR = red(clrAmb) * amb +
                red(clrA) * contrA +
                red(clrB) * contrB +
                red(clrC) * contrC;

            float cmpG = green(clrAmb) * amb +
                green(clrA) * contrA +
                green(clrB) * contrB +
                green(clrC) * contrC;

            float cmpB = blue(clrAmb) * amb +
                blue(clrA) * contrA +
                blue(clrB) * contrB +
                blue(clrC) * contrC;

            set(x, y, color(cmpR, cmpG, cmpB));
        }
    }
}

The original images I used are below. I had snatched them a while ago from a search result on Google Images but I can't find the actual source anymore. So, this will have to go without credit. Please drop me a comment if you know the source of these images. They're from the "Lighting direction" article at megapixel.net. I've submitted a belated permission to use these images in this article and I'm waiting for their response.