Ray Diagram: Now with Measurements

I’ve continued to work on the optical ray diagram tool prototype. I added a way to measure the effective focal length (EFL) of the lens system. It isn’t automatic, but by adjusting the parameters you can align an intersection at the optical axis and read off the EFL. Obviously this should be a one button click sort of thing, but it is kind of interesting to see how the various parameters affect EFL.

The UI is still very rough and the code is even worse. But I’ve actually been using it!

My main area of interest before going to automation is identifying and coding all the various measurements that you want of a lens. To identify these, I’ve been reading the excellent Applied Optics and Optical Engineering edited by Rudolf Kingslake. Chapter 3, Photographic Objectives, traces the history of the development of lenses from the development of photography to the book’s publication in the 1960s. I would recommend either starting there if you have some familiarity with optics already. If you’re new to optical design, start with Chapter 1, Lens Design. I got my copy from the public library but you can also borrow a digital copy from the Open Library on archive.org.

I realized I should change the example lens configuration in my prototype to a Cooke Triplet after reading Chapter 3. As the book points out, a lot of modern lens designs can be traced to or analyzed as variants of the Cooke Triplet. It is also unique in being only three elements but having performance that is good enough to warrant doing the work of designing one yourself. It is also non-trivial enough that you want an automated tool to design one, so it makes a good example.

The next step will be to add proper measurements of the various aberrations and distortions. I’ll be using worked examples from Applied Optics and Optical Engineering to check the calculations of my tool. The current default configuration is from this student project in MIT OpenCourseWare by Choi, Cooper, Ong, and Smith. I think I’ve already found a discrepancy in my results so my work is cut out for me.

Another source for a worked example is Dennis Taylor’s original patent from 1985. While Taylor invented it, the design is named after the company he was working for at the time – T. Cooke & Sons of York.

More ray diagrams

I’ve dug into this ray diagram sketch on CodePen because it’s pretty satisfying to twiddle the properties of the simulation and see how things change. I’ve added some sliders, but beware of the code – it isn’t pretty. I’d say it’s about reached the point of unmaintainability.

Screenshot as of this post

The UI is a total wreck, but you can currently alter all the major parameters. There aren’t any measurements yet, which is probably the next most important feature. It’s fine and dandy to move these virtual lenses around and see how the rays refract, but without the proper measurements it’s not actually a useful tool. Also there isn’t a way to change the lens type or order, and once you can do that, you’ll really want to be able to save and load a given configuration.

And this hasn’t even gotten into the optimization part! That’s the whole purpose!

WIP: Ray diagram in Javascript

During lunch I whipped up a software sketch based on that notebook entry I posted earlier. I thought I’d start with actually drawing the shapes required for a ray diagram, and then make it more data-driven over time. I should be able to then make a clean seam in the code where the diagram is controlled either by a human or a robot – maybe both at once!

Screen shot of where the ray diagram software sketch is so far.

Also I obviously need to write the actual solver, but that’s “just” a bunch of geometry and shouldn’t be too hard. I think I’m okay to assume that each ray will hit each boundary in order. If a ray doesn’t hit it’s next boundary, it gets dropped from the list.

This is pretty software-oriented compared to what I’ve been working on lately, but it’s the easiest thing to write up and very recent work.