Category Archives: Project

QMake hackery: Dependencies & external preprocessing

Posted on by
Reply

Qt Creator is a favorite IDE of mine for when I have to deal with miserably large C++ projects. At my job I ported a build in Visual Studio of one such large project over to Qt Creator so that builds and development could be done on OS X and Linux, and in the process, learned a good deal about QMake and how to make it do some unexpected things.

While I find Qt Creator to be a vastly cleaner, lighter IDE than Visual Studio, and find QMake to be a far more straightforward build system for the majority of things than Visual Studio’s build system, some things the build needed were very tricky to set up in QMake. The two main shortcomings I ran into were:

  • Managing dependencies between projects, as building the application in question involved building 40-50 separate subprojects as libraries, many of which depended on each other.
  • Having external build events, as the application also had to call an external tool (no, not moc, this is different) to generate some source files and headers from a series of templates.

QMake, as it happens, has some commands that actually make the project files Turing-complete, albeit in a rather ugly way. The eval command is the main source of this, and I made heavy use of it.

First is the dependency management system. It’s a little large, but I’m including it inline here.

# This file is meant to be included in from other project files, but it needs
# a particular context:
# (1) Make sure that the variable TEMPLATE is set to: subdirs, lib, or app.
#     Your project file really should be doing this anyway.
# (2) Set DEPENDS to a list of dependencies that must be linked in.
# (3) Set DEPENDS_NOLINK to a list of dependencies from which headers are
#     needed, but which are not linked in. (Doesn't matter for 'subdirs'
#     template)
# (4) Make sure BASEDIR is set.
#
# This script may modify SUBDIRS, INCLUDEPATH, and LIBS. It should always add,
# not replace.
# It will halt execution if BASEDIR or TEMPLATE are not set, or if DEPENDS or
# DEPENDS_NOLINK reference something not defined in the table.
#
# Order does matter in DEPENDS for the "subdirs" template. Items which come
# first should satisfy dependencies for items that come later.
# You'll often see:
# include ($$(BASEDIR)/qmakeDefault.pri)
# which includes this file automatically.
#
# -CMH 2011-06

# ----------------------------------------------------------------------------
# Messages and sanity checks
# ----------------------------------------------------------------------------
message("Included Dependencies.pro!")
message("Dependencies: " $$DEPENDS)
message("Dependencies (INCLUDEPATH only): " $$DEPENDS_NOLINK)
#message("TEMPLATE is: " $$TEMPLATE)

isEmpty(BASEDIR) {
    error("BASEDIR variable is empty here. Make sure it is set!")
}
isEmpty(TEMPLATE) {
    error("TEMPLATE variable is empty here. Make sure it is set!")
}

# ----------------------------------------------------------------------------
# Table of project locations
# ----------------------------------------------------------------------------

# Some common locations, here only to shorten descriptions in the _PROJ table.
_PROJECT1   = $$BASEDIR/SomeProject
_PROJECT2   = $$BASEDIR/SomeOtherProject
_DEPENDENCY = $$BASEDIR/SomeDependency

# Table of project file locations
# (Include paths are also generated based off of these)
_PROJ.FooLib               = $$_PROJECT1/Libs/FooLib
_PROJ.BarLib               = $$_PROJECT1/Libs/BarLib
_PROJ.OtherStuff           = $$_PROJECT2/Libs/BarLib
_PROJ.MoreStuff            = $$_PROJECT2/Libs/BarLib
_PROJ.ExternalLib          = $$BASEDIR/SomeLibrary

# ----------------------------------------------------------------------------
# Iterate over dependencies and update variables, as appropriate for the given
# template type
# ----------------------------------------------------------------------------

# _valid is a flag telling whether TEMPLATE has matched anything yet
_valid = false

contains(TEMPLATE, "subdirs") {
    for(dependency, DEPENDS) {
        # Look for an item like: _PROJ.(dependency)

        # Disclaimer: I wrote this and it works. I have no idea why precisely
        # why it works. However, I repeat the pattern several times.
        eval(_dep = $$"_PROJ.$${dependency}")
        isEmpty(_dep) {
            error("Unknown dependency " $${dependency} "!")
        }

        # If that looks okay, then update SUBDIRS.
        eval(SUBDIRS += $$"_PROJ.$${dependency}")
    }
    message("Setting SUBDIRS=" $$SUBDIRS)
    _valid = true
}

contains(TEMPLATE, "app") | contains(TEMPLATE, "lib") {
    # Loop over every dependency listed in DEPENDS.
    for(dependency, DEPENDS) {
        # Look for an item like: _PROJ.(dependency)
        eval(_dep = $$"_PROJ.$${dependency}")
        isEmpty(_dep) {
            error("Unknown dependency " $${dependency} "!")
        }

        # If that looks okay, then update both INCLUDEPATH and LIBS.
        eval(INCLUDEPATH += $$"_PROJ.$${dependency}"/include)
        eval(LIBS += -l$${dependency}$${LIBSUFFIX})
    }
    for(dependency, DEPENDS_NOLINK) {
        # Look for an item like: _PROJ.(dependency)
        eval(_dep = $$"_PROJ.$${dependency}")
        isEmpty(_dep) {
            error("Unknown dependency " $${dependency} "!")
        }

        # If that looks okay, then update INCLUDEPATH.
        eval(INCLUDEPATH += $$"_PROJ.$${dependency}"/include)
    }
    #message("Setting INCLUDEPATH=" $$INCLUDEPATH)
    #message("Setting LIBS=" $$LIBS)
    _valid = true
}

# If no template type has matched, throw an error.
contains(_valid, "false") {
    error("Don't recognize template type: " $${TEMPLATE})
}

It’s been sanitized heavily to remove all sorts of details from the huge project it was taken from. Mostly, you need to add your dependent projects into the “Table of Project Locations” section, and perhaps make another file that set up the necessary variables mentioned at the top. Then set the DEPENDS variable to a list of project names, and then include this QMake file from all of your individual projects (it may be necessary to include it pretty close to the top of the file).

In general, in this large application, each sub-project had two project files:

  1. One with TEMPLATE = lib (a few were app instead as well). This is the project file that is included in as a dependency from any project that has TEMPLATE = subdirs, and this project file makes use of the QMake monstrosity above to set up the include and library paths for any dependencies.
  2. One with TEMPLATE = subdirs. The same QMake monstrosity is used here to include in the project files (of the sort in #1) of dependencies so that they are built in the first place, and permit you to build the sub-project standalone if needed.

…and both are needed if you want to be able to build sub-project independently and without making to take care of dependencies individually.

The next project down below sort of shows the use of that QMake monstrosity above, though in a semi-useless sanitized form. Its purpose is to show another system, but I’ll explain that below it.

QT -= gui
QT -= core
TEMPLATE = lib

## Include our qmake defaults
DEPENDS = FooLib BarLib
include ($$(BASEDIR)/qmakeDefault.pri)

TARGET = Project$${LIBSUFFIX}
LIBS += -llua5.1 -lrt -lLua$${LIBSUFFIX}
DEFINES += PROJECT_EXPORTS

INCLUDEPATH += /usr/include/lua5.1 
    ./include

HEADERS += include/SomeHeader.h 
    include/SomeOtherHeader.h

SOURCES += source/SomeClass.cpp 
    source/SomeOtherClass.cpp

# The rest of this is done with custom build steps:
GENERATOR_INPUTS = templates/TemplateFile.ext 
    templates/OtherTemplate.ext

gen.input = GENERATOR_INPUTS
gen.commands = $${DESTDIR}/generator -i $${QMAKE_FILE_IN}
# -s source$(InputName).cpp -h include$(InputName).h

# Set the destination of the source and header files.
SOURCE_DIR = "source/"
HEADER_DIR = "include/"
# What prefix and suffix to replace with paths and .h.cpp, respectively.
TEMPLATE_PREFIX = "external/"
TEMPLATE_EXTN = ".ext"

#
# Warning: Here be black magic.
#
# We need to use QMAKE_EXTRA_COMPILERS but its functionality does not give us
# an easy way to explicitly specify the names of multiple output files with a
# single QMAKE_EXTRA_COMPILERS entry. So, we get around this by making one
# entry for each input template (the .ext files).
# The part where this gets tricky is that each entry requires a unique
# variable name, so we must create these variables dynamically, which would
# be impossible in QMake ordinarily since it does only a single eval pass.
# Luckily, QMake has an eval(...) command which explicitly performs an eval
# pass on a string. We repeatedly use constructs like this:
#    $$CONTENTS = "Some string data"
#    $$VARNAME = "STRING"
#    eval($$VARNAME = $$CONTENTS)
# These let us dynamically define variables. For sanity, I've tried to use a
# suffix of _VARNAME on any variable which contains the name of another
# variable.
#

# Iterate over every filename in GENERATOR_INPUTS
for(templatefile, GENERATOR_INPUTS) {
    # Generate the name of the header file.
    H1 = $$replace(templatefile, $$TEMPLATE_PREFIX, $$HEADER_DIR)
    HEADER = $$replace(H1, $$TEMPLATE_EXTN, ".h")
    # Generate the name of the source file.
    S1 = $$replace(templatefile, $TEMPLATE_PREFIX, $$SOURCE_DIR)
    SOURCE = $$replace(S1, $$TEMPLATE_EXTN, ".cpp")
    # Generate unique variable name to populate & pass to QMAKE_EXTRA_COMPILERS
    QEC_VARNAME = $$replace(templatefile, ".", "")
    QEC_VARNAME = $$replace(QEC_VARNAME, "/", "")
    VARNAME = $$replace(QEC_VARNAME, "\", "")
    # Append _INPUT to generate another variable name for the input filename
    INPUT_VARNAME = $${QEC_VARNAME}_INPUT
    eval($${INPUT_VARNAME} = $$templatefile)

    # Now generate an entry to pass to QMAKE_EXTRA_COMPILERS.
    eval($${VARNAME}.commands = $${DESTDIR}/generator -i ${QMAKE_FILE_IN} -s ${QMAKE_FILE_OUT} -h $${HEADER})
    eval($${VARNAME}.name = $$VARNAME)
    # ACHTUNG! The 'input' field is the _variable name_ which contains the
    # input filename, not the filename itself. If you put in a filename or
    # either of those variables don't exist, this will fail, silently, and
    # all attempts at diagnosis will lead you nowhere.
    eval($${VARNAME}.input = $${INPUT_VARNAME})
    eval($${VARNAME}.output = $${SOURCE})
    eval($${VARNAME}.variable_out = SOURCES)

    # Now tell QMake to actually do this step we meticulously built.
    eval(QMAKE_EXTRA_COMPILERS += $$VARNAME)
    # Also add our header files. I doubt it's really necessary, but here it is.
    HEADERS += $${HEADER}
}

This one uses a bit more black magic. The entire GENERATOR_INPUTS list is a set of files that are inputs to an external program that is called to generate some code, which then must be built with the rest of the project. This uses undocumented QMake features, and a couple kludges to generate some things dynamically (i.e. the filenames of the generated code) from a variable-length list. I highly recommend avoiding it. However, it does work.

These two links proved indispensable in the creation of this:

QMake Variable Reference

Undocumented qmake

Context Free

Posted on by
Reply

My last post mentioned a program called Context Free that I came across via the Syntopia blog as his program Structure Synth was modeled after it.

I’ve heard of context-free grammars before but my understanding of them is pretty vague. This program is based around them and the documentation expresses their limitations; what I grasped from this is that no entity can have any “awareness” of the context in which it’s drawn, i.e. any part of the rest of the scene or even where in the scene it is. A perusal of the site’s gallery shows how much those limitations don’t really matter.

I downloaded the program, started it, and their welcome image (with the relatively short source code right beside it) greeted me, rendered on-the-spot:

The program was very easy to work with. Their quick reference card was terse but only needed a handful of examples and a few pages of documentation to fill in the gaps. After about 15 minutes, I’d put together this:

Sure, it’s mathematical and simple, but I think being able to put it together in 15 minutes in a general program (i.e. not a silly ad-hoc program) that I didn’t know how to use shows its potential pretty well. The source is this:

startshape MAIN
background { b -1 }
rule MAIN {
   TRAIL { }
}
rule TRAIL {
   20 * { r 11 a -0.6 s 0.8 } COLORED { }
}
rule COLORED {
   BASE { b 0.75 sat 0.1 }
}
rule BASE {
   SQUARE1 { }
   SQUARE1 { r 90 }
   SQUARE1 { r 180 }
   SQUARE1 { r 270 }
}
rule SQUARE1 {
   SQUARE { }
   SQUARE1 { h 2 sat 0.3 x 0.93 y 0.93 r 10 s 0.93 }
}

I worked with it some more the next day and had some things like this:

I’m not sure what it is. It looks sort of like a tree made of lightning. Some Hive13 people said it looks like a lockpick from hell. The source is some variant of this:

startshape MAIN
background { b -1 }
rule MAIN {
    BRANCH { r 180 }
}
rule BRANCH 0.25 {
    box { }
    BRANCH { y -1 s 0.9 }
}
rule BRANCH 0.25{
    box { }
    BRANCH { y -1 s 0.3 }
    BRANCH { y -1 s 0.7  r 52 }
}
rule BRANCH 0.25 {
    box { }
    BRANCH { y -1 s 0.3 }
    BRANCH { y -1 s 0.7  r -55 }
}
path box {
    LINEREL{x 0 y -1}
    STROKE{p roundcap b 1 }
}

The program is very elegant in its simplicity. At the same time, it’s a really powerful program. Translating something written in Context Free into another programming language would in most cases not be difficult at all – you need just a handful of 2D drawing primitives, a couple basic operations for color space and geometry, the ability to recurse (and to stop recursing when it’s pointless). But that representation, though it might be capable of a lot of things that Context Free can’t do on its own, probably would be a lot clumsier.

This is basically what some of my OpenFrameworks sketches were doing in a much less disciplined way (although with the benefit of animation and GPU-accelerated primitives) but I didn’t realize that what I was doing could be expressed so easily and so compactly in a context-free grammar.

It’s appealing, though, in the same way as the functions discussed in the last post (i.e. those for procedural texturing). It’s a similarly compact representation of an image – this time, a vector image rather than a spatially continuous image, which has some benefits of its own. It’s an algorithm – so now it can be parametrized. (Want to see one reason why parametrized vector things are awesome? Look at Magic Box.) And once it’s parametrized, animation and realtime user control are not far away, provided you can render quickly enough.

(And as @codersandy observed after reading this, POV-Ray is in much the same category too. I’m not sure if he meant it in the same way I do, but POV-Ray is a fully Turing-complete language and it permits you to generate your whole scene procedurally if you wish, which is great – but Context Free is indeed far simpler than this, besides only being 2D. It will be interesting to see how Structure Synth compares, given that it generates 3D scenes and has a built-in raytracer.)

My next step is probably to play around with Structure Synth (and like Fragmentarium it’s built with Qt, a library I actually am familiar with). I also might try to create a JavaScript implementation of Context Free and conquer my total ignorance of all things JavaScript. Perhaps a realtime OpenFrameworks version is in the works too, considering this is a wheel I already tried to reinvent once (and badly) in OpenFrameworks.

Also in the queue to look at:

  • NodeBox, “a Mac OS X application that lets you create 2D visuals (static, animated or interactive) using Python programming code…”
  • jsfiddle, a sort of JavaScript/HTML/CSS sandbox for testing. (anarkavre showed me a neat sketch he put together here)
  • Paper.js, “an open source vector graphics scripting framework that runs on top of the HTML5 Canvas.”
  • Reading generative art by Matt Pearson which I just picked up on a whim.

Isolated-pixel-pushing

Posted on by
1

After finally deciding to look around for some projects on github, I found a number of very interesting ones in a matter of minutes.

I found Fragmentarium first. This program is like something I tried for years and years to write, but just never got around to putting in any real finished form. It can act as a simple testbench for GLSL fragment shaders, which I’d already realized could be used to do exactly what I was doing more slowly in Processing, much more slowly in Python (stuff like this if we want to dig up things from 6 years ago), much more clunkily in C and OpenFrameworks, and so on. It took me probably about 30 minutes to put together the code to generate the usual gawdy test algorithm I try when bootstrapping from a new environment:

(Yeah, it’s gaudy. But when you see it animated, it’s amazingly trippy and mesmerizing.)

The use I’m talking about (and that I’ve reimplemented a dozen times) was just writing functions that map the 2D plane to some colorspace, often with some spatial continuity. Typically I’ll have some other parameters in there that I’ll bind to a time variable or some user control to animate things. So far I don’t know any particular term that encompasses functions like this, but I know people have used it in different forms for a long while. It’s the basis of procedural texturing (as pioneered in An image synthesizer by Ken Perlin) as implemented in countless different forms like Nvidia Cg, GLSL, probably Renderman Shading Language, RTSL, POV-Ray’s extensive texturing, and Blender’s node texturing system (which I’m sure took after a dozen other similar systems). Adobe Pixel Bender, which the Fragmentarium page introduced to me for the first time, does something pretty similar but to different ends. Some systems such as Vvvv and Quartz Composer probably permit some similar operations; I don’t know for sure.

The benefits of representing a texture (or whatever image) as an algorithm rather than a raster image are pretty well-known: It’s a much smaller representation, it scales pretty well to 3 or more dimensions (particularly with noise functions like Perlin Noise or Simplex Noise), it can have a near-unlimited level of detail, it makes things like seams and antialiasing much less of an issue, it is almost the ideal case for parallel computation and modern graphics hardware has built-in support for it (e.g. GLSL, Cg, to some extent OpenCL). The drawback is that you usually have to find some way to represent this as a function in which each pixel or texel (or voxel?) is computed in isolation of all the others. This might be clumsy, it might be horrendously slow, or it might not have any good representation in this form.

Also, once it’s an algorithm, you can parametrize it. If you can make it render near realtime, then animation and realtime user control follow almost for free from this, but even without that, you still have a lot of flexibility when you can change parameters.

The only thing different (and debatably so) that I’m doing is trying to make compositions with just the functions themselves rather than using them as means to a different end, like video processing effects or texturing in a 3D scene. It also fascinated me to see these same functions animated in realtime.

However, the author of Fragmentarium (Mikael Hvidtfeldt Christensen) is doing much more interesting things with the program (i.e. rendering 3D fractals with distance estimation) than I would ever have considered doing. It makes sense why – his emerged more from the context of fractals and ray tracers on the GPU, like Amazing Boxplorer, and fractals tend to make for very interesting results.

His Syntopia Blog has some fascinating material and beautiful renders on it. His posts on Distance Estimated 3D Fractals were particularly fascinating to me – in part because this was the first time I had encountered the technique of distance estimation for rendering a scene. He gave a good introduction with lots of other material to refer to.

Distance Estimation blows my mind a little when I try to understand it. I have a decent high-level understanding of ray tracing, but this is not ray tracing, it’s ray marching. It lets complexity be emergent rather than needing an explicit representation as a scanline renderer or ray tracer might require (while ray tracers will gladly take a functional representation of many geometric primitives, I have encountered very few cases where something like a complex fractal or an isosurface could be rendered without first approximating it as a mesh or some other shape, sometimes at great cost). Part 1 of Mikael’s series on Distance Estimated 3D Fractals links to these slides which show a 4K demo built piece-by-piece using distance estimation to render a pretty complex scene.

(Later addition: This link covers ray marching for some less fractalian uses. “Hypertexture” by Ken Perlin gives some useful information too, more technical in nature;  finding this paper is up to you. Consult your favorite university?)

He has another rather different program called Structure Synth which he made following the same “design grammar” approach of Context Free. I haven’t used Structure Synth yet, because Context Free was also new to me and I was first spending some time learning to use that. I’ll cover this in another post.

My experiences with Apache Axis2/C

Posted on by
Reply

(This is an abridged version of a report I did at my job; I might post of copy of it once I remove anything that might be considered proprietary.)

I was tasked at my job with looking at ways of doing web services in our main application (which for an upcoming delivery is to be separated out into client and server portions). Said application is written primarily in C++, so naturally our first look was into frameworks written for C or C++ so that we would not need to bother with language bindings, foreign function interfaces, porting, new runtimes, or anything of the sort.

Our search led us to Apache Axis2/C. We’d examined this last year at a basic level and found that it looked suitable. Its primary intended purpose was as the framework that the client and server communicated over in order to transfer our various DTOs; that it worked over SOAP and handled most HTTP details (so it appeared) was a bonus.

I discovered after investing considerable effort that we were quite wrong about Axis2/C. I’ll enumerate a partial list of issues here:

  1. Lack of support: There was a distinct lack of good information online. I could find no real record of anyone using this framework in production anywhere. Mailing lists and message forums seemed nonexistent. I found a number of articles that were often pretty well-written, but almost invariably by WSO2 employees.
  2. Development is largely stagnant: The last update was in 2009. In and of itself this is not a critical issue, but combined with its extensive list of unsolved bugs and a very dense, undocumented code base, this is unacceptable.
  3. Lack of documentation: Some documentation is online, but the vast majority of the extensive API lacks any documentation, whether a formal reference or a set of examples. The most troubling aspect of this is that not even the developers of Axis2/C seemed to comprehend its memory management (and indeed our own tests showed some extensive memory leaks).
  4. Large set of outstanding bugs: When I encountered the bug-tracking website for Axis2/C (which I seem to have lost the link for), I discovered a multitude of troubling bugs. Most of them pertain to unfixed memory leaks (for code that will be running inside of a web server, this is really not good). On top of this, a 2-year-old unfixed bug had broken the functionality for binary MTOM transfers if you had enabled libcurl support, and this feature was rather essential to the application.
  5. Necessity of repetitive code: It lacked any production-ready means to automatically generate code for turning native C/C++ objects to and from SOAP. While it had WSDL2C this still left considerable repetitive work for the programmer (in many cases causing more work rather than less) and its generated code was very ambiguous as to its memory-management habits.
  6. Limited webserver support: Axis2/C provided modules only for working with three web servers: Apache HTTPD, Microsoft IIS, and their built-in test server, axis2_http_server. Our intended target was Microsoft IIS, and the support for IIS was considerably less developed than the support for Apache HTTPD. To be honest, though, most of my woes came from Microsoft here – and the somewhat pathetic functionality for logging and configuration that IIS has. I’m sorry for anyone who loves IIS, but I should not be required to manually search through a dump of Windows system calls to determine that the reason for IIS silently failing is that I gave a 64-bit pool a 32-bit DLL, or that said DLL has unmet dependencies. Whether it’s Axis2/C’s fault or IIS’s fault that the ISAPI DLL managed to either take IIS down or leave it an an indeterminate state no less than a hundred times doesn’t much matter to me. (However, on the upside, I did learn that Process Monitor from Sysinternals can be very useful in cases where you have otherwise no real source of diagnostic information. This is not the first time I had to dump system calls to diagnose an Axis2/C problem.)
  7. Poor performance: Even the examples provided in the Axis2/C source code itself had a tendency to fail to work properly.
    1. Their MTOM transfer example failed to work at all with Microsoft IIS and had horrid performance with Apache HTTPD.
    2. On top of this, the default configuration of Apache Axis2/C opens up a new TCP connection for every single request that is initiated. Each TCP connection, of course, occupies a port on the client side. On Windows, something like 240 seconds (by default) must pass upon that connection closing before the port may be reused; on Linux, I think it’s 30 seconds. There are 16384 ports available for this purpose. Practical upshot of this: A client with the default configuration of Axis2/C cannot sustain more than 68 requests per second on Windows or 273 requests per second on Linux. If you exceed that rate, it will simply start failing. How did I eventually figure this out? By reading documentation carefully? By looking at an API reference? By looking at comments in the source code? No, by looking at a packet dump in Wireshark, which pointed out to me the steadily increasing port numbers and flagged that ports were being reused unexpectedly. I later found out that I needed to compile Axis2/C with libcurl support and then it would use a persistent HTTP connection (and also completely break MTOM support because of that unfixed bug I mentioned). None of this was documented anywhere, unless a cryptic mailing-list message from years ago counts.

So, I’m sorry, esteemed employees of WSO2, but to claim that Apache Axis2/C is enterprise ready is a horrid mockery of the term.

This concluded about 2 weeks of work on the matter. In approximately 6 hours (and I’ll add that my starting point was knowing nothing about the Java technologies), I had a nearly identical version using Java web services (JAX-WS particularly) that was performing on the order of twice as fast and with none of the issues with memory leaks or stability.

P.S. Is it unique to Windows-related forums that the pattern of support frequently goes like this?

  • Me: This software is messed up. It’s not behaving as it should.
  • Them: It’s not messed up; it works for me. You are just too dumb to use it. Try pressing this button, and it will work.
  • Me: Okay, I pressed it. It’s not working.
  • Them: Oh. Your software is messed up. You should fix it.

Macro photography, attempts #1 and #2

Posted on by
Reply

I picked up some very cheap extension tubes and a reversing ring for my DSLR, hoping to do some macro photography with them. However, I sort of ignored that both my lenses default to having their apertures at their narrowest setting (rather than their largest, which for some reason I assumed) until instructed otherwise whether electronically or via the aperture lever. This made it a bit more difficult to do a lot of the shots. I have a 49 to 52 mm step-up ring coming in the mail which will let me use the old SMC Pentax 50mm lens, which has an aperture ring, but it appears to be on a slow boat from China so it’s not coming anytime soon.

Part of business card

LCD monitor

CFL

Plastic edge in alligator clips

Those same alligator clips

PCB

Solder pads

Cyanotypes, first attempt

Posted on by
Reply

Having procrastinated for around a month, I finally got around to acquiring the chemicals for a standard cyanotype (I went with digitaltruth.com) and followed the method given in “The Book of Alternative Photographic Processes” by Christopher James, which my friend Lea loaned me. I started out with a 1/5 batch of each solution (thus 20 g ferric ammonium citrate & 100 mL water, and 8 g potassium ferricyanide & 100 mL water).

The book had wonderful, detailed instructions, most of which I ignored for now because I was just trying to get the feel of the cyanotype process…

  • Sunshine was in short supply and it was snowing anyway, so I used someone’s UV lamp instead. It doesn’t provide very even lighting, but it looks plenty bright.
  • The book said to let the individual chemical mixtures “ripen” for 24 hours before mixing them. I was too impatient to do this.
  • I attempted all my prints on some crappy 8.5×11 paper that is flimsy and likely has some detrimental chemicals in it.
  • I probably should have invested in some clothespins to hang things up to help them dry.
  • I still don’t have any dark glass containers to store the mixtures in, so I just coated a jar in a layer of tape.
  • I don’t know where to find a hake brush, so I used some (metal-free) foam brushes from the hardware store.

Dave from Hive13 already had a transparency on hand that he had used to burn an image for screenprinting, and I used that as my negative. It had only black-and-white, but I’ll try with a negative with actual gray tones later.

The first attempt sort of worked and had a clear image exposed after about 20 minutes. I thought was a good first step since it indicated that I’d mixed the chemicals properly and that the UV light was sufficient. However, when I washed the paper in cold water, nothing at all remained. This looked to me like major underexposure, or a case of the paper just being unsuited to cyanotypes.

I tried again with a different image and exposed it a little longer, but results weren’t much better. Some of the darkest areas developed to a very light, almost invisible blue. I looked to the textbook for advice on how long to expose, and it said to go until the darkest parts had exposed past blue to almost a silvery-gray sort of shade.

So I tried to follow that advice on the third attempt I made… actually, I wanted to expose it longer than I did, but I needed to get back home so I rushed it a little.

Here’s the exposed, but not developed, print:

The gradient in the top left is a strip of paper that I moved away at periodic intervals. I placed several strips of paper to the right but they were removed first and aren’t visible here. The Hive13 logo also has a faint image to the left, probably from me moving the print early in the exposure and jolting the negative a little.

I developed the print (just rinsed it in cold water until the water ran clear) and let it dry for maybe 7 hours:

There are a lot of artifacts here. The darker border might be from the edges of the acetate on the negative. The things in the top left are some etching on one of the plates of glass that I used to hold the negative. In the undeveloped print, the strip to the right of that has clearly visible steps of tone, and I find it a little weird that all of these developed to pure white, while areas that are all the same color in the undeveloped print turned into clearly different tones in the developed one. I probably should read up on how to control this better.

But all in all, I’m impressed with how it turned out after 3 tries.

Hacked infrared camera, attempt #1

Posted on by
2

This page at GeekTechnique discusses how most digital cameras are easily turned into infrared cameras by removing the IR blocking filter in front of the CCD, and replacing it with a filter that blocks visible light but passes IR. As luck would have it, exposed film negatives work very well as such a filter.

So I attempted this on my Kodak EasyShare CX6200, my first camera, which somehow still works after 6 years of abuse. It was surprisingly easy, minus the part where I had to manually resolder the coil which controls the shutter on the lens because it was attached by single hair-thin strands of uninsulated wire. But I digress…

I think it’s working well. It very clearly passes IR light because the IR pens for the Wii whiteboard showed up quite brightly; it blocks light from LCD monitors and passes sunlight, but red LEDs seem to show up a bit. Trying it on another camera with more manual controls, and perhaps with a sharper filter, might prove interesting.