The Sigma 18-35mm f/1.8, firmware updates, and auto-focus

July 27, 2015

Here is the quick summary: the firmware update for the Canon mount Sigma 18-35mm f/1.8 (2014-8-22) did more than add support for the EOS C100, as claimed by Sigma. It also changed the lens ID from 137 to 150, and seems to have improved auto-focus accuracy, although not precision. Update: The auto-focus is as good as a Canon EF 85mm f/1.8.

I got one of Sigma’s 18-35mm f/1.8 lenses to go with a new Canon EOS 70D over a year ago. At a New Year’s event with a local band that includes a neighbor of mine, I took a bunch of pictures with this combination. The result seemed to work pretty well in spite of the low light at the outdoor venue. However, I have found that many images I have taken with the lens since then have not been in focus when using the optical viewfinder. This is a fairly common problem with Sigma lenses, although it doesn’t account for its early good performance. I’m guessing that at the New Year’s event most of the pictures had a deeper depth of field from focusing far enough away.

To deal with the problem, I got one of Sigma’s dock gizmos. I printed out a focus test page and made a table that I filled out with the adjustments needed. Every time I used the dock, the Sigma software asked about updating the lens firmware. I always refused because Sigma claims they just added support for a camera I don’t have. I don’t like to update things unless the update is actually beneficial. It is a way of limiting the chances of dealing with an update that breaks something.

Auto-focus calibration tool

Auto-focus calibration tool

The attempt at improving auto-focus didn’t go well. I got very contradictory results from two attempts, each starting from no adjustments, and neither improved the results. I figured the paper at a 45 degree angle was to blame, so I built a focus target out of Lego. When I cleared the adjustments on the lens before testing, I decided to update the lens firmware just to keep the software from incessantly asking about it. Every test I did with the Lego target suggested the lens was fine. Some tests with more common subjects suggest the accuracy is decent, but the precision still isn’t as good as with Canon lenses, so it is still a good idea to take several pictures and review them.

The software I use for keeping track of my photos, Digikam, did not at first identify this lens. Instead it called it lens 137; it has since been updated. I think the Canon protocol uses an 8-bit unsigned integer to identify the lens model, although now additional information like the focal length range is needed to identify a specific lens model. Since I updated the firmware, Digikam identifies the new images as being taken with lens 150.

I don’t know if this change from 137 to 150 is needed to make the lens work with the EOS C100. It is possible that the change will affect how the lens and camera work together. From what I’m seeing, it has a favorable effect on auto-focus performance with my EOS 70D. I don’t know why Sigma wouldn’t mention this, and I really don’t like the short list of changes common in the photographic industry for such updates. I have suspected that some changes are omitted from the public list of changes, and my experience with Sigma’s 18-35mm f/1.8 lens deepens that suspicion.

Long commands on Windows with SCons

January 15, 2015

At my job, where one of my tasks is to handle builds for Windows software using SCons, I recently moved from using SCons 1.2 with some custom modifications to an unmodified SCons 2.3.4. The change comes along with a move to using a newer Visual Studio while still supporting builds with an older one. The newer SCons has trouble with issuing some commands, just like the older version. Neither version can run programs that have whitespace in their path if the entire command is longer than some threshold. The custom modifications I made were to correct the problem, but this time I wanted something less custom and easier to support. Here is a link to the solution I developed; read on for the details.

With shorter commands, SCons issues the commands about the same way it does on Linux, and it works fine. Longer commands run into trouble on Windows; I’m told it has to do with the C runtime libraries. SCons works around this by placing most of a long command into a temporary file and then passing the name of the file preceded by a ‘@’ character as the first command line argument. Microsoft’s compiler and linker will read the temporary file for their arguments.

The implementation of this has a flaw that makes it useless using default installations of Visual Studio. SCons first puts together the command line as though no special long command handling is required. If the result is too long, the command is modified to use a temporary file but is parsed incorrectly; the program to run is taken to be all the characters up to the first whitespace. This makes the command to run “C:\Program”, which isn’t a program, or even an existent path. Everything after the first whitespace is put into the temporary file. It may start with “Files (x86)\Microsoft Visual Studio 10.0\VC\bin\cl.exe”, for example.

I found an attempt at getting SCons to use long commands written by Phil Martin. He provided SCons with a different way to spawn processes. Unfortunately, it doesn’t handle the whitespace issue. By the time the spawn function is called, SCons has already modified the command to use the temporary file. Nevertheless, his implementation was a good place to start. Like his implementation, mine also requires PyWin32.

I modified it to detect the use of a temporary file. When used, the spawn function opens and reads the temporary file to rebuild the complete command line. Then it figures out the whole path to the program, including whitespace, and separates that from the arguments. I also made a modification to produce better error messages from CreateProcess().

Finding the path to the program works best when there is some delimiter in the program path. It is common on Windows to enclose paths that have whitespace with double quotes. The command constructed by SCons using the default program paths lack this delimiter. I solved this by supplying new complete paths for all programs used in Microsoft’s toolchain. It is quite a bother, but I did it the best and most complete way I could figure. This includes creating some build configuration options for several paths, and making two build environments: one for x86 targets and another for amd64 targets.

Hopefully this will help someone else. I really don’t understand why this bug has been around for so long considering that whitespace in paths on Windows is very common.

Personal Cloud

July 13, 2014


A cloud so personal, it senselessly gathers your intimate details that it doesn’t need.

A good combination

January 21, 2014

I tried this combination over the weekend: hot chocolate and chocolate flavored caffeinated marshmallows. The marshmallows had a couple of spots with a candy like flavor that they lack when eaten without hot chocolate, but otherwise the combination worked very well. I suppose marshmallows without a chocolate flavor would work, too, but these caffeinated ones don’t come it that flavor.

Replacement I2C kernel module for Raspbian

January 8, 2014

A while ago, I got I2C repeated starts and SMBus support to work from the Linux kernel on a Raspberry Pi. I recently built a new 3.10.25 kernel from the foundation’s kernel fork on Github and updated my own fork of their fork with just the I2C update in a new branch. In the process, I managed to misuse git so that commits now attempt to go to the Raspberry Pi Foundation’s kernel fork rather than my own. I tested the module on the copy of Raspbian that I have. It is running the 3.10.24 kernel, but is quite happy with the new kernel module (or for 3.10.37, or 3.12.24) and my MLX90614 test program. I also built the kernel module for the BMP085, but it looks like that requires more than just a kernel module file to get it working. No big deal for me; I’ll just replace the whole kernel.  I just wanted to see if I could make it really easy for someone else.

To use the updated I2C module, first download it. The file will need to replace the one in /lib/modules/<kernel version>/kernel/drivers/i2c/busses. You may want to keep a copy of what is already there. After copying it, check to see if the i2c-bcm2708 module is loaded. If not, load it up and have fun! If it is, you can either reboot or unload the i2c-bcm2708 kernel module. Before unloading will work, any dependent modules must first be unloaded. It wasn’t loaded for me right after boot, so it hopefully won’t be any trouble.

Update: I finally got the code up on Github. I hope the kernel module has been working out for anyone who has tried it. Please do leave a comment about any success or failures with it. I have yet to get any feedback, so I only have my own test case to claim that it works.

LumiQuest softboxes and flash zoom settings

January 2, 2014

Oops: I made a common mistake when I wrote this post. The output of a flash is controlled as a fraction of maximum output energy, not power. Changing flash power can only change brightness reliably for photographic use if the duration of the output is constant, and that assumes constant power during the output. A camera sees more light as brighter, so flash energy is useful to control, while flash power is not. Power is energy over time. I haven’t bothered to correct the rest of the post.

It is good to have diffuse light for soft shadows. To that end, when I can’t aim the flash at a ceiling I use LumiQuest softtboxes because they aren’t super pricey (although there are cheap competitors from beyond the USA now), and they are very portable. This isn’t an advertisement for the product, though; I’m not getting paid. Instead, this is about an investigation I did into how to get the best results from the LumiQuest’s Softbox and Softbox LTp.

Happy Thanksgiving!

The LTp softbox is directly over the minifigs and very close

I got the LTp to help with some Thanksgiving dinner pictures of Lego minifigures. It is almost too large for something attached to a flash, and it did take a few tries to keep it from falling off. It was facing downward to be an overhead light, but that made falling extra easy.

I wanted the light to be as even as possible, so I used the pull-out light scattering lens of the flash. This put the flash’s zoom head into its 14mm setting, which is really just the 24mm setting with the lens applied. The lens is made of some plastic like material and absorbs some light, which was also helpful because otherwise the flash was too bright. The flash in question here is the Yongnuo YN568EX II, which is working out quite well for me, but that could be the topic of another post.

Brightness uniformity test

Brightness uniformity test

Afterwards, I wanted to investigate what works best with the LTp to make the softest shadows. It makes sense that the light will need to be uniformly bright across the light scattering surface of the softbox for the best results. I took pictures of the LTp with different flash zoom and power settings to get an idea of the uniformity. The exposure was the same for all pictures (f/16, 1/125sec, ISO 100). The resulting test is not indicative of overall brightness because most of the images have over-exposed areas. They do, however, clearly show that the 14mm flash zoom setting does provide the most uniform light over the surface provided by the LTp softbox. The 24mm setting isn’t much worse, but the 105mm setting looks like it should make the LTp perform the same as a much smaller softbox.

Next, I decided to see what effect this has on the quality of shadows. I put a cardboard tube on frosted glass so that I could photograph the shadow on the glass, and because I had the glass already setup. I later discovered that the shadow on the glass was sometimes filled in with light from the flash reflecting from other surfaces in the room which obscured what the shadow would have been with light only directly from the softbox. The test images also had a shadow cast by the tube onto itself, which turned out to be mostly immune to the problem. It made for small test images, but I think they worked out well.

Shadow quality test

Shadow quality test (take link for bigger view)

For a more complete test, I also tried my old LumiQuest Softbox (the one with a notch in what otherwise would be a rectangular light scattering surface), a bare flash, and a misused Sto-Fen Omni-Bounce. I varied the flash power, but not the exposure (f/4, 1/160sec, ISO 100) or distance between the flash and tube (about 740mm, or 29 inches). In all cases, the 14mm setting required quadrupling the flash power and the modifiers required doubling it. The bare flash at 24mm used 1/32 flash power. The 105mm flash zoom setting required changing flash power, but it wasn’t so consistent.

The results show that the LTp softbox responds more to the flash zoom setting than the other LumiQuest softbox I have. The LTp improves with the 14mm setting over the 24mm, but the loss of light from the flash’s scattering lens will sometimes make 14mm too dim. Other flashes may fare better, but I think most will be similar if they don’t use a glass scattering lens. Using the LTp with the 105mm setting makes it about as good as the non-LTp softbox at 14mm or 24mm.

The LumiQuest Softbox (non-LTp) produces shadows with a negligible difference with the 14mm and 24mm zoom settings, but does get worse at 105mm. The bare flash gives the expected shadows with hard edges, but it does seem to be very slightly softer at 105mm. This suggests the zooming action changes the uniformity of the brightness across the flash head.

Finally, I tried a Sto-Fen Omni-Bounce pointed directly at the tube. The Omni-Bounce is a light scattering device that doesn’t add much surface area like a softbox does. This makes it half of a light diffuser. The other half is supposed to be the ceiling and walls of the surrounding room. The little card included with the Omni-Bounce states that it should be pointed at the ceiling and not the subject. This test shows why. I have seen some people misuse their Omni-Bounce by pointing it directly at their subject while inside a convention center with high black ceilings, but that just results in wasting flash power.

CD-R Stack as a Background for Pictures

October 12, 2013
Background setup

Background setup and messy desk

I’ve been using a stack of CD-R’s as the background for several images of Lego minifigures. The CD-R’s are lit by flashlight (a silver Hexbright). In front of the flashlight is a color filter and a light scattering filter, both really intended to be used with a flash. The position of the CD-R’s and the two Star Wars minifigs in front are unchanged from the recent photo “Don’t let this happen to you”. The examples shown here all use the same color filter, but I also used violet and red-ish ones, as well as none at all.

The background result is affected by the relative position and orientation of the flashlight, CD-R stack, and camera. This makes using a flash in place of the flashlight really difficult. Also, I usually had the Hexbright at a low brightness setting, so it really was flashing, but it bothered the camera more than me. All of these positions and orientations provide lots of variables to play with to make a number of interesting effects for colorful abstract out-of-focus backgrounds.

Mom, I can see straight!

Mom, I can see straight!

Some of the light going through the CD-R’s makes nice vertical columns of highlights. There are four of these columns: one on either side of the central spindle pillar thingy (I don’t know what that is called), and two further away that seem to be reflections of the first two. Getting all four in the same picture is nearly impossible, but two is pretty easy and three isn’t difficult. Some prism-like effects are visible in those highlights, and the CD-R’s colors the light a bit green. I’ve got two or three bands of CD-R’s in the stack, so the exact shade of green varies a bit. I also looked at some DVD-R’s, but they are a boring white. I think I’ve got older ones that’ll color the light a bit red, but I haven’t tried.

With this setup, horizontal bands over a limited vertical distance can be shown where the light passes between the disks. As a result, these bands are not colored by the CD-R’s. They are visible just under Iron Man’s left arm in “Looking for trouble”. The light also reflects between the surfaces of adjacent disks; this seems to create an odd pattern that can result in curved swirly lines that are more easily seen by a camera than eyes. The curvy swirlies are seen in “Mom, I can see straight” to the left of the minifig. Some placements of the camera versus the CD-R stack avoid this effect and have clear horizontal lines with beveled edges as seen near the minifig in “An explorer in a strange place”.

Looking for trouble

Looking for trouble in front of CD-R’s

With the help of a light in front of the CD-R’s (I used an on-camera flash pointed at the ceiling and nearby wall), a single vertical column of reflected light can also be put in the background. The reflection highlights look distinctly different from the highlights of light passing through the CD-R’s. Instead of aperture shaped highlights, they have horizontal bands that seem to be sections of the aperture shape. Since this light comes from a different source, it is a simple matter to make it a different color. This shows up in “Looking for trouble” with Lego Iron Man (sans iron). I used a CTO filter on the flash attached to the camera to help make the helmet look more golden, and it shows up reflecting off the CD-R’s.

This guy

This guy

What I’m most fascinated by are some horizontal bands in my picture “This guy” (lower middle of frame next to the minifig; not visible in the little thumby here, best seen after taking the link and viewing the image full size). Even though the stack is well out of focus, there are a number of thin bands. I’m guessing that the banding of horizontal disks caused similar banding in the out-of-focus light which can be made into thin lines by how the light from different bands are superimposed on each other.

The top of the desk is glass, so I usually have a flash under it. The effect works a lot better than some of the scenes of the evil Kirk in “The Enemy Within”. It also helped tremendously with my “Looking for trouble” picture; one flash lit the face and the other lit the helmet.

I also made a video to show how the background can change, but it really doesn’t give a full demonstration.

Adafruit’s Puft Cloud

September 9, 2013

There is a nice post on the Adafruit blog about the networks of stuff. It features this wonderful picture:

Adafruit's Puft Cloud

Adafruit’s puft cloud grabs hold of everything

A very happy looking cloud is grabbing everything in sight. It seems like the artist tried to think of the most harmless thing; something that could never possibly destroy us. The post is a short summary of a way to tame the puft cloud put forth by Limor Fried. There is also a Google+ page for it. The basic notion is to keep things open so that what is collected is known and how it is used can be limited and controlled by users. Given how companies love to keep everything proprietary, we may be doomed. But, maybe after a few more incidents like the Samsung Smartly-taking-away-your-privacy-through-security-flaws TV, companies might finally get the idea when users demand security they can verify. If no one outside the originating company can verify their device’s security, it is only a short matter of time until someone outside that company verifies the device’s lack of security. Such lacking security of a device used in the presumed  privacy of one’s home is a problem most people would rather not have, but a few will want to profit from.

I2C repeated starts implemented on the Raspberry Pi

July 13, 2013

Update: If you just want a kernel module for something close to kernel version 3.10.25, look here.

I’m working on a project that uses the Raspberry Pi and various sensors. One sensor is a MLX90614 IR thermometer; this communicates using SMBus. One of my goals is to avoid making the project specific to the target hardware, the hardware that actually runs my code. I want the code that communicates with the sensors to be Linux specific but not Raspberry Pi specific.

Communication with a MLX90614

Communication with a MLX90614

One of the problems a lot of people have had with the Raspberry Pi is with getting SMBus communication to work. SMBus is built on I2C, a way of managing serial communication between many devices with only two wires: clock and data. I2C is more flexible, while SMBus is made to be more reliable. As part of guaranteeing reliability, mostly in a multi-master setup, SMBus requires the use of I2C’s repeated starts for read operations. The I2C master driver for Linux on the Raspberry Pi does not support this, and I have been unable to find a patch or custom version anywhere that adds support. Most people have solved the problem by using code that directly interfaces with the Raspberry Pi’s hardware, ignoring the Linux kernel support altogether. This solution not only fails to meet my goal of avoiding code specific to the target hardware, it also won’t work well if more than one process on the same host attempts to use the I2c master hardware.

I decided to solve the problem by modifying the Linux kernel’s support for the I2C master of the Raspberry Pi. I succeeded. My implementation may not be the best or bug free (works for me is a weak guarantee), but it does allow for communication with a MLX90614 using the user-space (unprivileged code outside the kernel) SMBus interface provided by Linux. Since examples with SMBus are more difficult to find than I2C, here is my test code. I also tested with a BMP085 sensor using the support for it already in Linux. This sensor uses I2C rather than SMBus, and it also functions correctly. It doesn’t need a repeated start, but it gets one anyway.

To avoid causing extra trouble, I implemented repeated starts for a subset of conditions under which they could be valid. I focused on SMBus communication. With I2C, a slew of messages going back and forth can be requested, all with repeated starts, but this isn’t normally done or required.  Also, the hardware requires that once the first message has begun transmission, the second message be setup in the registers ahead of the stop condition. To make matters worse, there is no interrupt condition for this, so polling in a busy wait is required. I stuck all this inside the bcm2708_i2c_master_xfer() function of i2c-bcm2708.c so it isn’t in the interrupt handler. After the second message is configured, the interrupt handler is used to receive the data. That avoids additional polling at the cost of not allowing additional repeated starts.

If you’d rather see the kernel change in source control, I stuck it on Github. It is a 3.6.11 kernel, but not the latest revision out there. I’m still using it for now. There is no kernel or kernel module for download here because I’m running Gentoo on my Raspberry Pi and I build my own kernels. If I gave you my kernel, you may well find that something doesn’t work anymore.

A stupidly simple way to connect 3.3V logic to a Sainsmart relay board

June 16, 2013

A lot of hobbyists are using Sainsmart relay boards with their projects because the boards cost less than buying the relays, or come really close. The boards include circuits to drive the relay coils so that a typical logic output can be connected directly to the board. Each driver circuit uses an optocoupler so that the driver and the coils only share a ground potential. This is a great scheme to allow the driver to work at a different voltage than the relay coils, but the board was intended for use with 5 volt supplies for both. The drivers start to work reliably from around 3.8V up to 5.5V or so. The result doesn’t work well with a 3.3V supply for the drivers operated by 3.3V logic; some relays will function, and others won’t. The solution is to give the drivers a 5V supply, but then the floating driver inputs should rise to 5V; the drivers are connected to the positive supply, and are two LEDs and a resistor in series that connect to an input pin. A common solution to using 3.3V logic with the Sainsmart board is to add another driver circuit to drive the driver circuit on the board. I thought that was annoying and sounded rather silly, so I investigated further and found a simpler method.

Test setup

Test setup with 10MΩ probe

I started by hooking up 5V supplies to the board and measuring the voltage of one of the driver inputs when left floating. This setup is in the picture; channel 1 (left) is measuring the voltage on a driver input, and channel 2 (right) is measuring the 5V supply. The first results showed a drop of about 2.2V from the driver’s supply. This occurs even when the only wire connected to the board, besides the measuring probe, is the positive power end, VCC, to the drivers. This voltage drop is made possible by the current passing through the probe; connect the probe’s reference potential to the board’s VCC instead of ground, and the voltage measured is zero.

I measured using a 1MΩ probe. With the supply voltage measured at just over 4.8V, I get 2.5V on an otherwise disconnected driver input. The current flowing through the driver is adequate for the LED to make a very dim light.  By switching the probe to 10MΩ (as pictured), the voltage measured is over 0.27V, meaning the voltage on the input is 2.7V.

This indicates that a small current is all that is needed to keep the drivers below 3.3V when using a 5V supply. Connecting a 3.3V logic output directly to one of the board’s driver circuits should work just fine without adding an additional driver circuit. In many cases, though, some 3.3V processor is used and its general purpose I/O lines are initialized as inputs after a reset. Clamping diodes are often present and can probably handle the small current through the relay board’s drivers trying to pull the line to 5V. Adding a 10MΩ resistor to ground should save the clamping diodes from any work, while connecting it to the 3.3V supply should work almost as well while eating even less power. The small current draw of the input might actually take care of the problem, but I lack any measuring equipment that can confirm this without drawing the small current that will take care of the problem.

Circuit to connect 3.3V logic to a Sainsmart relay board

Circuit to connect 3.3V logic to a Sainsmart relay board

I’ve been asked to post a circuit diagram for the solution I mention above, so here it is. I threw it together in Inkscape even though I don’t really know how to use Inkscape. The circuit will work for the Sainsmart relay boards like the one I tested when the drivers on the board are given a 4V to 5V power source.

False Steps

The Space Race as it might have been

You Control The Action!

High Frontier

the space colony simulation game

Simple Climate

Straightforwardly explaining climate change, so you can read, react and then get on with your life.