Clone wiki

Fourier Optics / Home


Welcome to the Fourier Optics project. The goal of this project is to generate a library that can be used to model how 'light' propagates through various media in a fast and accurate manner. Accuracy means that the following problems (and others!) need to be addressed:

  • Diffraction - This is important when the objects you're illuminating are about the same size as the wavelength of the light you're illuminating them with. If you're confused by this, think about radio waves; if you have a 3 GHz source, then your wavelength is about 10 cm. That means that if you have something that is about the size of a soda can, it will cause diffraction.
  • Interference - Waves interfere with themselves. If you have an object that the waves diffract around, or if one ray takes a different path than another to reach a particular location, then they will constructively and destructively interfere with themselves. This leads to bright and dark spots. This can be important for a radio, or for computer-generated holography
  • Multipath - Although multipath is related to interference, it adds in echoing because the assumption is that you're modeling something that is carrying information, like how radios carry data.
  • Polarization - Polarization means that you can have a perfectly good illuminator/sensor pair, but the sensor just can't get the illuminator's signal. This can happen with dipole antennas if they are rotated 90 degrees to one another. It can also happen if the signal is reflected off of water, or passed through certain materials.
  • Attenuation - Perhaps the simplest phenomenon to model, all materials (a perfect vacuum is not a material!) sap the power of the spectrum passing through them. The problem is that they don't necessarily absorb all frequencies at the same rate, so you end up with things like color filters.
  • Dispersion - The speed of light is not the same for all frequencies through the same material. This is the reason why prisms work.
  • Refraction - Refraction occurs for similar physical reasons as for dispersion, but the result appears different.
  • Others?

Diffraction can be calculated in Fourier space via the math for Fourier Optics. The others require more work and more thought. All suggestions are welcome!


This wiki uses the Creole syntax. More information is at

At the current time, there is only one developer (Cem Karan). Once I have a reasonable API laid out, I will open up the project for others to add in code. If you want to contribute, look through the code (ESPECIALLY the public API!), and make suggestions on how to improve it. The goal is make certain that the API is 100% C99 compatible, and to keep it simple and efficient. The public API can be arbitrarily changed up through release 1.0, at which point I will only extend API functionality. If for some reason I remove functionality, I will increase the major version number as a warning to end users.

A note about myself. I am NOT a radio or optics expert. I am going to collect what I understand about EM propagation on these pages, to outline what I'm going to develop. If you are interested in this project, and are an expert in optics, I could use your help. Look over my math and my models. Let me know if what I'm doing is right. Over time, I'd like to construct a reasonable explanation of how light propagates that anyone can use, and more importantly for me, a model that I can use! :)


  • The publicly visible API will always be in standard C. Right now, the standard for C is ISO/IEC 9899:1999, but that standard may be updated in the future. As updates occur, if the changes affect the public API, the API may be changed.
  • The private internals require the following:
    • CUDA - This is necessary for the Fast Fourier Transform (FFT), which is what is needed for doing Fourier optics. If OpenCL becomes mature enough at some point, then I may switch to using it instead. That will ensure that more GPUs can be used. But, for the time being CUDA is more mature. This means you MUST have a GPU from NVIDIA! My apologies for anyone with a chipset from someone that doesn't support CUDA, but that's the way it is for right now. If you want me to switch, push the vendors out there to support OpenCL better (faster runtimes!), and for more OpenCL libraries (specifically, a really good 3D FFT library).
    • Thrust - This is similar to Boost, but for the GPU. Note that I may remove this once CUDA 4.0 becomes freely available, as it will be a part of CUDA 4.0. Also, if you are an OpenCL fan, get something with the same API up and running so I can use it.
    • OSSP uuid - This library generates UUIDs. All references between the library and user code involve Universally Unique Identifiers (UUIDs). This is for the following reasons:
      • Improves debugging - When an object is created, it is assigned its own UUID. When it is freed, its UUID is retired. If you pass in a retired UUID to the library, the library will know that the UUID is dead, and will report an error.
      • Improves compression - Common objects have the same UUID. Thus, the client can pass in a complex object as a template, and then do rubber-stamping operations, passing in a UUID and an affine transform. This would be useful to specify something like a brick, and then specify every brick in a building. This can also significantly increase the speed of communication, which is important across a slow network. Which brings up the next point...
      • Allows networking - I am considering adding support for ZeroMQ, or some other messaging framework at some point in the future, to permit multiple processes access to the same library of objects. This would allow a full client-server platform, where small, weak clients ask powerful servers to do work on their behalf. The server would provide a library of objects that are fixed, and the clients would make requests by referring to the ID of the objects. I do not want to limit what the objects are, but I also don't want different servers to have name conflicts (different objects with the same name). UUIDs solve this problem fairly nicely; each server generates its own UUIDs, and if several servers have common objects, they can be configured to share the same UUIDs, making it possible to have a server farm.

Design document

There is a design document at, which should give you an overview of how the library is constructed and planned. Until the library hits 1.0, that document will likely be in constant flux; use it as a useful guide in what I'm thinking, but don't count on it being perfect at any time.

Papers and Presentations