I am a PhD student & a researcher in Electrical Engineering with focus on Computational Imaging and Computational Photography. I love signal processing, computational imaging and photography. I also love travelling to places and meeting people. Please visit my website at http://indranilsinharoy.com to learn more about me.
[By the way, the red pepper in the profile picture is not photoshopped. I found this pepper in a vegetable market in California. I had to photograph it because of its uncanny resemblance to a human fist.]
Who says math is not beautiful? Anyone who doubts the beauty in math must check out algebraic surfaces.
An implicit functions has the form:
where, is an arbitrary constant.
For example, the implicit equation of the unit circle is and the equation describes a sphere of radius 1.
An algebraic surface is described by an implicit function . It may be rendered using Mayavi by evaluating the expression on a regular (specified) grid, and then generate isosurface of contour value equal to 0.
Here are some examples of algebraic surfaces plotted using Mayavi:
I wrote a quick function called implicit_plot for plotting algebraic surfaces using Mayavi. The most important argument to the function is of course the expression as a string. It is probably not the best function, but the idea is to show how to plot implicit surfaces. The code snippet is included at the end of this post. Suggestions for improvement are always welcome.
Thanks to the megapixel war, pixels in digital sensors have shrunk considerably over the years. Consequently, the pixel resolution (number of pixels in a digital image) has improved. Currently, the pixel resolution, assuming gray-scale sensor, can compete with the aerial resolution of lenses on paper. This post is about a plot I created sometime back (for a different presentation) which shows the growth of pixel count and the diminishing of pixel size over the years for three popular segments of digital cameras. The green line plots the diffraction-limited (aberration free) optical resolution 3 stops below the maximum aperture available for off-the-self lenses during the same period. The optical resolution line doesn’t mean much; however, it is plotted to compare the sensor resolution with the optical resolution over time. The graph shows that while the sensor resolution has improved by leaps and bounds, the optical resolution hasn’t. It is no surprise though, because improving the optical resolution by traditional means is very expensive, and results in bulky lenses. The time is just right for exploring computational methods for improving the system resolution of imaging systems.
Other interesting data-points in the graphs are:
1. The Kodak DSC460, based on a Nikon SLR, was one of the first digital cameras.
2. The Sharp J-SH04 was the cellphone with a camera.
The number of mega-pixels and the pixel resolution (decrease in pixel size) has increased rapidly for the cellphone and point-and-shoot cameras, probably driven by marketing rather than by picture quality. In the more professional segment, clearly the strategy has been different. This may be because of two main reasons — one, the image quality dictated by noise, color reproduction, low-light performance, etc are more important for these shooters, and two, building high-quality large lens is relatively more expensive.
Summary: Most cellphone cameras today come with “large aperture” lens such as F/2.0 or F/2.2. Since the optical resolution of a “perfect” lens (a lens devoid of any aberration) is inversely proportional to the F/# (the relation is shown in equation 1), one may assume that a F/2.0 cellphone camera lens should be able to resolve fine details on an object as well as a F/2.0 DSLR lens.
The above image shows two lenses of same F/#, and also of equal normalized focal length. The one on the left is a lens whose 35 mm focal length is about 28 mm (with complete camera module, including the image sensor) from a cellphone, and the lens on the right is a 28 mm DSLR lens.
The optical resolution of a lens determines how close two line-objects or point-objects be placed before the objects cannot be distinguished from each other when viewing through the lens. The minimum resolvable separation, , is the inverse of . The larger the value of (usually measured in line-pairs-per-mm), the better is the resolving ability of the lens. So if the f-number, , of a cellphone lens matches the of a DSLR lens, then the equation (1) seems to suggest that they have the same optical resolution! However, as it is shown in the following paragraphs, the ability to resolve fine details of a F/2.0 DSLR lens is in fact much better than a F/2.0 cellphone camera lens. Concretely, if the focal length and the aperture diameter of the cellphone lens is 1/k (k>1) times the respective parameters of the DSLR lens, then the of the two systems are equal but the resolving ability of the cellphone lens is times that of the DSLR lens. For example, a 50 mm, F/2.0 lens (D = 25 mm), which is a first order approximation of a 50 mm DSLR lens, can resolve details as fine as 54 microns focused at a distance of 2 meters. Whereas a 5 mm, F/2.0 lens (D = 2.5 mm), a close approximation of a typical cellphone camera lens, can resolve details only up to about 540 microns focused at the same distance. This is essentially a manifestation of the difference in magnifications (or angular resolution) of the lenses.
ZEMAX, a leading software tool for design and analysis of optical systems, provides an in-built DDE server that enables access to ZEMAX’s features externally using any Windows application. The ability to access and control ZEMAX externally allows it to be used in many interesting and powerful ways, some of which has been documented in the “ZEMAX Extensions” chapter of the ZEMAX manual. An excellent toolbox called MZDDE, developed by Derek Griffith at CSIR, already exists for users of MATLAB. When I tried to look for an equivalent toolbox in Python, I couldn’t find one, so I decided to write one myself.
PyZDDE is a toolbox, which is written in Python, is used for communicating with ZEMAX using the DDE messaging protocol. It is similar to MZDDE and very much inspired by it. Currently PyZDDE is not as extensive as MZDDE as it is a work in progress. However, it has some distinguishing features — it can be used with regular Python scripts and also in an interactive environment such as an IPython shell, QtConsole or IPython notebook. The ability to interact with ZEMAX from an IPython notebook using PyZDDE can be a powerful tool for both teaching and documentation. Please visit the github repository for downloading and using the code. The github repository also contains an accompanying wiki page which describes briefly on how to use the PyZDDE toolbox.
Here I would like to briefly document the communication process between ZEMAX and Python using PyZDDE.
Using macros, written in the Zemax Programming Language (ZPL), is a powerful way to extend the functionality of ZEMAX. Zemax doesn’t provide a special editor for writing ZPL macros, and it recommends using text editors such as the NOTEPAD editor.
I love editors with syntax highlighting. Since there are no standard editors (with syntax highlighting) for writing ZPL codes, I decided to use Notepad++. It also allowed me to create a style-file which enabled syntax highlighting and support minimal code folding as shown below. The style-file contains the latest keyword, numeric function and string function definitions (as of April 2013). I have shared the style-files here in the post.
In order to download the files and see the quick instructions to use them, please continue reading.