MTF charts help to objectively explain the quality and performance attributes of a lens. The charts plot the ability of the lens to distinguish between evenly spaced black lines in a one millimeter space. This resolving power is referred to as line pairs per millimeter (lp/mm).

10 line pairs per millimeter and 30 line pairs per millimeter are most commonly used. Some charts will show 40 lp/mm. The camera manufacturers will display these lines on the graph in various colors and thicknesses, so check the key to decipher their system.

Even so, you can read these charts fairly quickly from left to right and up to down. These charts are very helpful to see how your lens might perform and compare it against qualitative reviews from photographers. For example, the Canon 85mm prime lens performs exceptionally well at the widest aperture: it preserves high resolution from the absolute center of the lens all the way to the outer edge of the glass with excellent defocusing. You can see that in the MTF chart above in the top blue line. There is very little deviation of line resolution from center to outside. Both the latitudinal (lines parallel to the radius of the lens, shown as solid lines on the graph) and longitudinal (lines perpendicular to the radius of the lens, shown as dotted lines on the graph) lines on the graph match for the largest aperture opening. This lens is well known for it’s beautiful blur (bokeh) and extreme sharpness at wide apertures. However, the graph also reveals that the lens performs quite poorly when shot at an aperture of f/8. Even at the center of the lens, the resolving power for 30 lines per millimeter drops from around 82% to 48%, and continues losing resolution the farther from the center. What this means is that the lens is more a specialty piece than general purpose, and that you should not expect good performance from this lens at smaller apertures.

When looking at these charts quickly, keep these points in mind:

1. MTF charts are useful when comparing lenses of the same focal length, for example, a 50mm Canon versus a 50mm Sigma.
2. The higher any line is on the graph the better.
3. Graphs with a lot of variability do not always mean a bad lens. In the case of the 85mm from Canon, it means that it excels within certain parameters.
4. The straighter the line (i.e., it doesn’t drop down or wiggle up and down) the better and more consistently it performs from the center of the lens outward.
5. The smaller the distance between the various lines are to each other, the more consistently the lens performs over a wide set of apertures.
6. The pair of solid and dotted lines shows resolution between perpendicular (longitudinal) and parallel (latitudinal) lines to the radius of the lens. The closer these line pairs overlap, the better the defocusing will be.

If you haven’t heard, a cooking robot and IBM’s Watson can now cook better than you.

This is interesting because we have to load machines with a basic set of assumptions, and because of the accuracy of machinery and their long-term memory, they essentially will never forget these assumptions.

For example, if you were teaching a robot how to write, you would teach it the difference between your and your’re. This is a pretty standard grammar rule that I very often forget or ignore, leaving my writing pot-marked with errors.

Though that example is banal, if we look at localization, evolution, and culture: most “innovations” or differences arise either from error, accident, or deliberate changes to a set of assumptions.

The problem is, do we risk freezing culture at a point in time when we load our assumptions into the robot’s machine learning? Or are the scientist clever enough to introduce randomization and evolution into the machine learning? The problem is, how do you teach a robot to be both accurate but also open to doing things “wrong?” — the hallmark of creativity and innovation.

An engineer is a problem solver. A cultural engineer uses culture (philosophical, material, social, political, artistic) to solve problems. In that sense most humanities or “soft” fields of study can all be considered cultural engineers as they use do not use purely scientific or mathematic solutions to solving problems. They work inside other bodies of theory.

These “solutions” take their cues from anthropology, sociology, philosophy, and aesthetics for the most part. Here are some rough examples:

1. Aesthetic designers who use “good” design as a means of increasing product longevity (and slowing done consumerism) to help either benefit underprivileged communities or help the environment. The theory embraced here is that concerns of beauty, usefulness, and design create better solutions than merely solving for mechanical issues.
2. Anthropological how airlines design status systems to increase customer spend taking cues from generally accepted ideas around status and gift giving. But human behavior or “cognitive biases" can also be used to promote better health and more just societies. Problem solving in this vein owes its theory from twentieth-century anthropologists.
3. Sociological this is perhaps the easiest to pull from because essentially most policy makers, lobbyists, and governments use sociology — with its cherry-picking of mathematics and psychology — as the most “scientific” of the humanities to cull from. It is also a very popular field of study for liberal arts graduates, so many can relate to its vocabulary later on in life.
4. Philosophical the work of Marx or Kant may be considered a systematic approach (like an engineer’s approach) to solving issues of the the present and future. Philosophy offers the most formalized system for the humanities, as it attempts to define semantics and the structure (of language) itself used by the discipline; concerns that also occupy many a computer engineer when dealing with computer languages.

These are merely top-of-the-head categories, which are useful insomuch as I jotted them down in this post. The more important point is that these fields of study borrow from mathematics and science but ultimately don’t need to obey their rules. They don’t need, for example:

1. Empirical evidence
2. Repeatability of findings
3. Experiments
4. Testable hypotheses
5. Strong arguments
6. Proofs necessary for validity

In fact, the idea of proving anything is debatable. Indeed, and especially, for aesthetics, proof is nearly a non-issue. Personal agency and force are more legitimate.

In anthropology and sociology, a single incident or case, or study, can pave way for validity and general acceptance, even without repeatability. By the very nature of the communities studied in anthropology, often repeatability of findings is impossible.

And in philosophy — a field I know little about — I will venture forward and say that many things have been argued quite elegantly in the course of time: from forgotten scrawls to major systems of thought like religion. These can range from highly systematic and “scientific” to requiring Kierkegaardian “leaps of faith” when some things are left unexplained. But all of which have seemed to find someplace in the philosophical canon as “legitimate” or “true.”

But rather than make this seem like I am pointing my finger at these broad fields of study to exclaim, “Look! Look at their fallacies, imprecisions, and false idols. Can they be trusted?” What I really mean to say is that their approach to problem solving is different from science and math (the original bastions of an engineer’s thought process), but not at all necessarily weaker or less valid.

And I cannot emphasize enough, these are certainly not a replacement or usurper to math or science.

In fact, that is why a cultural engineer is a particularly relevant position: they are poised to transform technology from a scientific and mathematic phenomena of problem solving into an uncharted world of culture and social significance only because they draw on the rules of those fields — and not math and science — as further areas of understanding for the engineer: as their points of departure, and as their tools to solving greater engineering problems than previously encountered.

And it is my hope, that by pulling from cultural systems of understanding that technology can be transformed in unforeseen ways but hopefully in ways that better humankind. I feel like the well of science has run dry in helping to guide technology to make us better, and perhaps we should feel free to take cues from elsewhere when solving issues of the engineer.

Consider this scenario: a engineer is working on a project and finds another engineer has worked on something similar but has a better solution. This other engineer shared his solution on his blog. The code is open-sourced. The engineer grabs that code, and uses it. This is a fairly common, and not really falling under any scrutiny, as far as I am aware.

Now, a designer is working on a project and finds another designer has worked on something similar but has a better solution. This other designer shared his solution on his blog. The designer grabs the design and uses it.

Whereas for the engineer, this is common practice, for the designer it is not as reputable. If the designer were to share his work and let it be known that it is from someone else, his talent would diminish. My question is: do engineers ever feel similarly about this? I for one feel less authentic and less skilled if I use a template file. Even if I remake that template from scratch following the same steps I feel more satisfied: much like a musician playing Mozart or a chef using an established recipe: even when the steps are copied, variation and innovation seem to occur. When something is copied wholesale — even with tacit encouragement from the creator — the mutation of creativity does not seem to occur.

Let’s say you are being sent data from all over the world. But what if you get data in all sorts of odd capitalization? For example:

1. SOMETHING SET IN CAPITALS
2. SOmething that has common capitalization Mistakes
3. something that channels e.e. cummings

Use CSS like that below to correct these common capitalization discrepancies.

p {
 text-transform: lowercase;
}
p:first-letter {
 text-transform: uppercase;
}

This takes the whole string inside the element and down-cases it for a uniform letterset, then it capitalizes the first letter using the pseudo-class first-letter.

The HTML:

<p>TEXT THAT IS SET IN ALL CAPITALS.</p>
<p>TExt that wAs wriTTEn rather poorly.</p>
<p>A normal sentence would be treated just fine.</p>

The CSS:

p {
 text-transform: lowercase;
}
p:first-letter {
 text-transform: uppercase;
}

The Result:

Text that is set in all capitals.

Text that was written rather poorly.

A normal sentence would be treated just fine.

View the JS Fiddle.

We are very familiar with the em unit in CSS (which counter to traditional print typography measures the font’s point size or height not width), but have you ever used the ex unit? It is defined as the x-height of a font, which is the height of its lowercase letters.

Ex unit expression can especially be useful for content-heavy sites, in which case, you can preserve alignment and font-rhythm much more consistently without relying on cumbersome line-height calculations, which can also allow better control with mixed font designs.

For example, 1.8 is usually considered a good measure for line-height. If you have the ex height, you can simply set the line height as 1.8 × ex.

Referencing parent selectors in SCSS

I was going over the SCSS documentation after finding some curious SCSS I was unfamiliar with. Did you know you can generate a CSS rule based on the existence of a parent class without having to nest that CSS within the actual parent?

In CSS, you can only scope an element or class based on its parent if that CSS is embedded within that parent like:

.parent .child {
 background: red;
}

With SCSS, you can re-create this scope without the nesting:

.child {
 .parent & {
 background: red;
 }
}

This can be useful for browser-specific scraping, responsive design elements, or when you find the organization clearer by keeping the child’s style variations centralized rather than scattered ’cross your stylesheets.

Did you know (I didn’t) that CSS can read the text out of a data-attribute in HTML? If this is your html, <div data-today="Currently reading">Vanity Fair</td>, you can populate the data attribute into your CSS through content:

div[data-today]:before {
 content: attr(data-today)": ";
}