open source optical design software
max reason
Does any open-source optical design software exist?
If so, please provide links and brief comments. Thanks.
Acme Optics
>
> Does any open-source optical design software exist?
> If so, please provide links and brief comments. Thanks.
>
The only design code for which source is available is our program,
Roadrunner. It is not free but is available as a yearly subscription
for $129.00 which covers our time and trouble to distribute it.
We are in Windows now and Linux later this year.
Everyone else in the optical design software business is either too
greedy or too short sighted to make their source available.
ACCOS-V was once (pre 1985) available as a long term lease for $50,000
and Synopsis was once available with source for VAX machines as part
of the $10,000/year distribution (pre-1990).
Kidger's code in Quick Basic and Don Small's program in Quick Basic
were also once available but not for many years.
OSLO was once in source on HP 9000's in interpreted HP Basic but that
too was pre-1984.
If you need source, we are the only option and you won't see source
for ACCOS-V, CODE-V, OSLO or ZEMAX (unless it is bootleg) as far as I
have been able to gleen.
Sincerely,
Acme Optics
>
OpticsNotes.Com
I am curious, what language would you choose for an open source lens
design program?
In favor of having an open source program is that the ray tracing
calculator is well known. (Ref. Allen Nussbaum, Am. J. Phys 47 April
1970 and others. Long ago I coded up Nussbaums treatment in Basic and
it agreed with Code V ). Program "modules" for whatever analysis need
only access to that module to do their function.
The difficulty is for an open source program is the critical mass
needed of programmers that are interested in optical engineering. Open
source would seem to need very good coders to produce broadly portable
and useful code.
The other stumbling block is the complete spectrum of quality and price
of optical design code that exists today.
Still, its a neat idea. If it's of interest, (If I can find it) I'll
be happy to post my simple raytracer on opticsnotes.com and would
invite others to add theirs to the list.
Bruce
--
http://www.OpticsNotes.Com
Optics & Photonics Tutorials, References & Resources
In article <t5imte1...@corp.supernews.com>,
"max reason" <maxr...@maxreason.com> wrote:
>
> Does any open-source optical design software exist?
> If so, please provide links and brief comments. Thanks.
>
>
--
http://www.OpticsNotes.Com
Optics & Photonics Tutorials, References & Resources
Sent via Deja.com
http://www.deja.com/
Acme Optics
>Max,
>
>I am curious, what language would you choose for an open source lens
>design program?
I'd be willing to bet that no one would agree on a language. I'd pick
Fortran so the code could be ported to LINUX as well as Windows. Using
Winteracter and X/Winteracter the interface ports well too. I'm sure
some jerk would vote for Ada and I bet someone would cast a vote for
assembler.
>
>In favor of having an open source program is that the ray tracing
>calculator is well known. (Ref. Allen Nussbaum, Am. J. Phys 47 April
>1970 and others. Long ago I coded up Nussbaums treatment in Basic and
>it agreed with Code V ). Program "modules" for whatever analysis need
>only access to that module to do their function.
With very few exceptions, there is nothing that this calculator
program has in common with CODE-V except that they both run on a
computer.
As I have said many times before. The level of complexity involved in
optical design calculations is simple compared with many other braches
of science and engineering. The big nut to crack is managing the
database. There is almost no science to implementing PICKUPS and
SOLVES but make them work reliably in the presence of a flexible
optimization scheme and multiple zoom positions and you have a
complexly connected code that is non-trivial to write, expand and
debug and it is difficult, without extreme resources, to support more
than a one man project.
I am one person who wrote a full optical design code in 12 years and
I'm still adding to it. If there had been two of us, it would have
taken 20 years. With 4, it would take 30 years.
Quality of code? Bullshit! I have never seen good code in all my years
in the aerospace business. Just different code. I've seen the ASAP
source since as we had a legal copy of the DOS version in 1991.
There were few comments and airithmetic IFs and GOTOs. It was better
than spagetti. It was more like linguini with a good clam sauce and
bread sticks thrown in. Its a powerful code but it reflects the mental
processes of the genius (Al Greynolds) who wrote it. The mind of a
genius is a wonderously complex thing reflected in the code written by
the genius but it bears little relationship to the code used as
examples in books written on "how to write code".
>
>The difficulty is for an open source program is the critical mass
>needed of programmers that are interested in optical engineering. Open
>source would seem to need very good coders to produce broadly portable
>and useful code.
>
>The other stumbling block is the complete spectrum of quality and price
>of optical design code that exists today.
Sure, everybody agrees that no one could ever possibly write a program
to surpass ZEMAX so don't even try.
>
>Still, its a neat idea. If it's of interest, (If I can find it) I'll
>be happy to post my simple raytracer on opticsnotes.com and would
>invite others to add theirs to the list.
>
>Bruce
I've offered my entire source code, free to anyone who would port it
to a Mac. No strings. The offer has been open for 5 years. No takers
yet. People love to bullshit eachother about OPEN SOURCE. It is still
a hughe job to work on code, even if you get it for free.
Like Criswell would say
" I predict that by 2020, CODE-V and Light Tools will merge and pretty
much put everyone else out of business unless Alan Greenspan mucks it
all up.
ZEMAX will get sold to some poor slob with more money than sense and
Ken will live out his life on the Riviera (not the sofa).
ACCOS will be like an old soldier. It won't die. It will just fade
away.
OSLO will be alive and well in Argentina.
I'll still be doing Roadrunner and I'll be older and crankier than
ever.
Everyone else will be dead and they will take their codes with them."
Acme Optics
max reason
>
> I am curious, what language would you choose for an open source
> lens design program?
>
> In favor of having an open source program is that the ray tracing
> calculator is well known. (Ref. Allen Nussbaum, Am. J. Phys 47 April
> 1970 and others. Long ago I coded up Nussbaums treatment in Basic
> and it agreed with Code V ). Program "modules" for whatever analysis
> need only access to that module to do their function.
>
> The difficulty is for an open source program is the critical mass
> needed of programmers that are interested in optical engineering.
> Open source would seem to need very good coders to produce broadly
> portable and useful code.
>
> The other stumbling block is the complete spectrum of quality and
> price of optical design code that exists today.
>
> Still, its a neat idea. If it's of interest, (If I can find it)
> I'll be happy to post my simple raytracer on opticsnotes.com and
> would invite others to add theirs to the list.
> Bruce
> --
> http://www.OpticsNotes.Com
> Optics & Photonics Tutorials, References & Resources
Yeah, I suspect any answer to your question "what language" may
create an instant furor. Given no pre-existing situations or
conditions, my personal answer would be C++. Of course that
raises the question of how to program any graphics and/or GUI.
If the software is only to run on UNIX and Linux, that might be
a solvable problem, except co-programmers might be unwilling to
pay for any graphics or GUI packages - unless it's freeware.
My reason for asking about open-source optical design software
may be the opposite of what it appears. I asked because I was
wondering whether I should release my optical design software
as open-source freeware. I figured that would be pointless or
counterproductive if something similar is already available.
I wrote the original version of my optical design software
30 years ago. Over the years I've made umpteen special-purpose
variations to address special projects, but all are based upon a
common set of fundamental routines. I have given the source-code
to a few people over the years, but it has never been a product.
It has been my own tool for designing optics.
Currently I have two "variants" of my optical design software.
The C++ variant is simply the core routines without any real
input or output - it just loads optical designs and prints
some results so I can verify it with the more complete variant.
The more-complete variant is written in XBasic, which is an
open-source freeware 32-bit compiler with IDE and GuiDesigner.
XBasic has a two obvious upsides - free and multiplatform.
Two compatible implementations of XBasic are available,
Linux and Windows95/98/NT/2000. One nice consequence is,
the exact same source code runs on both implementations,
including graphics and GUI. XBasic is reasonably fast,
not as fast as super-optimized C++, but with a factor of 2x.
XBasic itself is written in XBasic - it's a capable language.
So that's what exists now. If a few capable programmers with
optical expertise want to get involved, then the open-source
software could be C++ or XBasic (or I suppose something else).
I should note that I just noticed the optics newsgroup and
therefore have NO IDEA how many people are "out there" that
might have interest in such software, and whether two or three
skilled programmers might oversee and coordinate any ongoing
development efforts. I'm a busy guy and cannot guarantee any
specific amount of time to support the software, so it's
probably important one or more energetic programmers are
involved on an ongoing basis. Also, since this software
has been for ME, to support my optical design processes,
(not commercial sale), it is not documented. So someone
should take on that job too. I'm willing to help a core
team get up-to-speed on the software, but after that how
much time I'll have is simply unpredictable.
Comments and suggestions are welcome.
Brian Blandford
"OpticsNotes.Com" <bruce_...@my-deja.com> wrote in message
news:93ctbo$skd$1...@nnrp1.deja.com...
> Max,
>
> I am curious, what language would you choose for an open source lens
> design program?
...Excellent question. I am (almost) sole curator of the teaching/optimising
software written at Imperial College by Charles Wynne, Mike Kidger and Pru
Wormell in the 70s/80s. It is called "Version 15" and ran in HP BASIC on
what was then a very fast desktop (9845 with go-faster stripes). Transferred
to an HP300M under BASIC-UX, and now onto a PC in TransEra HPBASIC I find
it's still a valuable resource. But the HPBASIC is company property, and I'm
looking for a shareware language route to keeping it alive - and shared as
it was intended to be. It is the precursor to the Kidger SIGMAs. In my view
it has the best optimisation kernel anywhere, and has a long pedigree of
optimising designs which were subsequently manufactured successfully. It
does aspherics, but it's lacking in all the fancy holograms, tilts,
tolerances etc. of the grown-up packages.
Max Reason's suggestion of XBASIC seems promising - anyone else have any
ideas?
Brian
brian.b...@baesystems.com
OpticsNotes.Com
To be successful, I think the language need be capable, open source,
and be understandable to more than computer scientists. Xbasic would
seem to qualify.
I would think that an open source software application can be written
in many parallel threads. If a moderator steps up to formalize a set
of software, all the better, but it would not be necessary. A message
board would develop to communicate related information.
I think an open source code would aid those folks who need to learn
something or perform highly specialized tasks. Many of those same
folks also own various other packages, or will. I bet most folks who
use linux and perl also use windows and excel.
In think an open source code would fly. .. OK .. walk. .. crawl? but
it would definately breathe.
Bruce
--
http://www.OpticsNotes.Com
Optics & Photonics Tutorials, References & Resources
Steve Eckhardt
>software written at Imperial College by Charles Wynne, Mike Kidger and Pru
>Wormell in the 70s/80s. It is called "Version 15" and ran in HP BASIC on
>what was then a very fast desktop (9845 with go-faster stripes).
>
>brian.b...@baesystems.com
Brian,
I've got a collection of old optical design programs (Grey's LensII and
POSD among them), and would love to add your code to my collection. Version
15's pedigree does sound good, but I'll bet Grey's orthonormalization
optimization kernel would give it a run.
The kernel I want to get my hands on is Juan Rayces', which implements
his flavor of Glatzel's method. The advantage of it is that it is capable of
dealing with Lagrange multiplier constraints that are out of bounds without
ruining the design, and as the constraints come within bounds, it gracefully
transitions to DLS. Anybody out there know if Juan is still around and could
be sweet-talked into sharing his code? (Lan Lebich could also be a source.)
--
Best Regards,
Steve Eckhardt (skeck...@mmm.com)
Opinions expressed herein are my own and may not represent those of my employer.
Sead Doric
College from early eighties might have something that originated from Version
15. I definitely do. I translated the code from HP basic to Powerbasic, removed
lots of spagetti looking code reach with "go to line number" statements and
added whole new set of gradient-index features.
I see the common nomenclature, surface representation etc as a biggest problem
to building one open optics code where everyone can add new features while
keeping common threads as the basic ray trace program.
I hope someone will have energy to do something about that issue, or all codes
will probably follow the faith of Version 15 as soon as their author/owner
retires or loose interest for optics.
Sead Doric, DIC
max reason
> Talking of Version 15 I guess many members of Optical Design Groupe at Imperial
> College from early eighties might have something that originated from Version
> 15. I definitely do. I translated the code from HP basic to Powerbasic, removed
> lots of spagetti looking code reach with "go to line number" statements and
> added whole new set of gradient-index features.
>
> to building one open optics code where everyone can add new features while
> keeping common threads as the basic ray trace program.
I understand. For at least the obvious things, it should be possible to
make the interface configurable. I can think of two obvious examples from
the optics program I am talking about releasing as open-source:
1: My program assigns a POSITION to each surface. Most optical design specs
I've seen over the years specify a SEPARATION [from the previous surface].
2: My program specifies conic surfaces with what I call "shape", or variable
name "q" in the program itself. q = 1 - (e * e) where e = "eccentricity".
I prefer q because it can specify oblate spheroids, while e cannot because
they'd be imaginary numbers.
In both these cases, especially in program with a GUI, the program could
accomodate whichever convention each optical designer prefers. Can you
think of important nomenclature and conventions that cannot be addressed
in such a way?
Doug Sinclair
programming language, similar in structure to Java, both standalone and
runtime compilers, a library that consists of about 100 general purpose
functions for strings, math, graphics, and database needs commonly
encountered in technical programming, and somewhat more than 1000 functions
specifically related to optical design.
The CCL language used by OSLO was developed to overcome the major
limitations imposed by C while remaining compatible with it. For example,
CCL uses a pass-by-reference scheme for handling function parameters that
removes the need for pointers in the language. Various other enhancements
make CCL much easier for non-programmers to deal with than C. The output of
CCL is run on a virtual machine that interprets its byte codes. When
necessary, it is possible to call fully-compiled routines for maximum speed,
but the general experience these days is that is seldom required, even for
many optimization tasks.
There are two major requirements for source-code access in optical design.
The first is to understand what the software does; the second is to adapt it
to a particular purpose. These requirements are not easy to solve, and it
took us many years to develop what I consider a reasonably satisfactory
solution. The problem with all of the "raw" source code that I have seen is
that it is very hard to comprehend, let alone modify.
If you would like to know more about CCL, you can download OSLO LT from
www.sinopt.com and look in the Help system. If would like to see what CCL
looks like and can accomplish, there are about 700 Kbytes of CCL source code
included with OSLO LT.
You should not group OSLO with Code V and Zemax in this area. They are not
in the same parish. Nor should you group CCL with Java or C#, although they
are similar in many ways. CCL is intended to provide a Windows programming
language that can be used by engineers and scientists. Java and C# seem more
suited to computer programmers.
-Doug Sinclair
"max reason" <maxr...@maxreason.com> wrote in message
news:t5imte1...@corp.supernews.com...
Acme Optics
I think you will need to be 100% compatible with ZEMAX, CODE-V and
ACCOS-V with respect to the specification of optical systems and with
respect to the metrics which your program calculates.
You will need translators to and from these three programs as well.
This means RD or CV, conic, aspherics, anamorphics etc. The rotation
angles will need to be the same signs. This means at least two sign
conventions because alpha and beta are positive right handed in ZEMAX
and positive left handed in CODE-V and ACCOS-V.
Only our program, Roadrunner, has the option of using either sign
convention in each prescription.
Do you have solves, pickups, tilt rev, tilt dar, tilt ben, rtilt, tilt
auto? What glass catalogs do you have? How about zoom positions
(alternate configurations)? How about diffraction gratings and HOEs?
You need to do HOEs like CODE-V does them at a minimum.
Can you or will you be doing non-sequential ray tracing? Polarization
ray tracing? GRIN materials? Illumination. Do you do diffraction PSF
and MTF now? Do you correctly handel cases of pupil distortion?
Does your gaussian beam prop model work for decentered systems? Do you
do narcissus delta temp for IR systems?
Do you have a macro programming language? Will you?
The list is essentially never ending.
What ever you add on top of these features will be the cream on top.
You will be distributing all of the software tools, correct? Even
though I have made the source for Roadrunner available at near free
prices, you would not believe some of the whining about the need to
buy a compiler and a graphics package to rebuild it.
People attracted by open source are some of the cheapest people I have
ever met in my life. They whine and they are almost all talk and no
code.
Then there is advertising. You would not believe the number of people
in the optics world who have no idea what sci.optics is or any news
group for that matter.
A lot of technical companies don't even let their employees connect to
a news server for fear of the employee downloading an obscene
photograph of a duct taped hamster in a leather bondage suit. That
means they don't have access to you postings.
If they are not here, you must go to them. How do you support an
advertising budget with a free program? Others have tried and died.
I'm soon moving to ads in magazines myself.
How will all of the changes from all of the developers be managed from
a configuration management standpoint? Who will drive the code
architecture?
I'm working a medium sized software project now with a team of
engineers, scientists and programmers. We have CM, we have more
meetings than IBM and it is still a towel of Babel.
Oh, how old are you? If the answer is >50, you probably won't live
long enough to see the project take off.
In the best of all worlds, your code will threaten ZEMAX and they will
buy you out to shut you down.
The above was the optimistic stuff I thought of.
Acme Optics.
>
jaca...@my-deja.com
You know, how software objects can create analogs of real world
objects? How software objects embody data and code so that the code
can be used to manipulate the data (model) in valid ways (methods)
that constrain the data object to represent real world (realizable)
properties?
A surface (lets leave solids and volumes alone for now...) exists
in space (global) and can be described by a set of points that is
UNIQUE. We don't need a sign convention. The rays of light that
interact at or with this surface can be descibed by coordinates,
direction cosines, wavelength (and other physical optics qualities)
that are also unique. These are unambiguous but perhaps lengthy and
calculation intensive constrtucts. We sacrife these and use
approximations (like radius, thickness, glass sequential databases)
to achieve calculation speed. Unfortunately these approximations have
given us the sorry state of optical design software that we get today:
several manually crafted, colossal FORTRAN codes that are almost
impossible to manage or extend.
If you want the new (young blood) code warriers to support and extend
optical modeling software, it will have to have a lot more potential
than the huge chunk_o'_code approaches we have to date. The only way to
do that is to embody object oriented programming and have a modular
approach to the optical model (you know, like we do in the lab where we
have lenses and mounts and detectors... you get the picture). The
modules should be able to exchange optical fields using rays (or maybe
even physical optics descriptions of phase and amplitude).
For example, a lens object would describe the physical analog of a
lens. It would describe not only the refracting surfaces but the edges
and non-clear aperature faces. It would occupy a set of points that is
positioned within the modeling software by the user in six axes. It
interacts with the rest of the model by claiming volume in a global
space (that is tracked by the container), accepting ray data (arrays),
calculating where they exit (creating new arrays) and passing those to
the next object in the list (database) or searching where (what object)
they should be passed to next (for non-sequential modes of operation).
All of the geometrical (or diffraction) calculation is handled by the
lens object internally. IT CAN USE ITS VERY OWN SIGN CONVENTION!!! As
long as all of the objects interact externally to a well documented and
controlled interface, each of the optical component models can be
independent. Some smart cookie can even implement a whole geomtrical
trace program for very complex optics (like a monochromater),
encapsulate it in a software object, and publish this to work in the
open source modeling framework.
Is this the fastest way to analyse optical systems? Not by a long shot.
But the extensibility makes it much more powerful.
Does this preclude optimization? Not at all. A given optical module can
be written to optimize performace for the rays it accepts and passes.
These can even be adaptive if we are smart enough to include the
possibility of temporal data and dynamics in our framework.
Does this throw away all of the "good" code that we have? No, this can
be encapsulated as well (with perhaps a loss in speed).
Does this eliminate the use of FORTRAN as the choice in modeling
language? Yes, thank God! - and basic too :)
Does this enforce code and interface standards in an environment that
can be created, added to, and revised by community of stewards and
contributors? Yes it most certainly does!
As for the language to use, I propose Java as it provides the object
oriented paradigm in a language that will run on almost any machine.
While this isn't the fastest choice, it is the most inclusive as
anybody can download very powerful Java development tools for free.
I expect computers will catch up on the speed issue long before we
develop the open source optical software to commercial application
levels of performance.
There, I've said this again... This is probably the fourth year that
I have tried to describe this vision. Someday, someone will go
"Oh, that makes some sense." and pursue it. I really hope it's soon.
I am not getting any younger...
James Carter
In article <t5ns3e5...@corp.supernews.com>,
Steve Eckhardt
I definitely agree with your idea of using an object oriented
programming language. Most of what you describe is really just modular
programming. I started translating David Grey's program into Modula 2 (Wirth's
modular successor to Pascal) in the 80's, but lost interest when Ken Moore
released his program that had a user interface as good as the one I was
planning.
Another interesting point you make is regarding the "huge chunk" codes
and the young blood programmers. I agree. The best implementation I've seen
of this concept is Adobe, where they rewrite every one of their programs from
the ground up every three years. Just imagine what CodeV would be like if they
had rewritten it once every 10 years! (I'm just going through the painful
process of relearning CodeV after 10 years of Zemax. The GUI still stinks! I
still believe that CodeV is the best lens design program there is, but I'll be
glad to return to Zemax after my short term lease runs out.)
Maybe I can talk my son into rewriting a lens design program in a
modern language.
Bob May
if you are going up or down. The whole problem with the differing
programs (and the lens designers that started the process) is that one
guy says up and the other says down for the same number and sign.
This can be confusing enough but then, on top of that, they may both
agree as to what left and right are. Mix up the directions and you
may make some optics that only a southpaw can use.
As to Object Oriented Programming, OOP is just the sooper dooper,
ultraclever wizzbang, impressive to the managers, reinvent the wheel,
fancy name applied to modular programming. Been doing things like
that for many years with straight libraries and it's nothing new under
the sun. Actually P code is an early version of doing things like
that.
--
Bob May
Remember that computers do exactly what you tell them to do, not what
you think that you told them!
Bob May
Abyssmol_Unit_#3_
is critical for any "open ended" effort to achieve any real progress without
redesigning everything each new generation. (aka linguine/spagetti)
perhaps a breakout of what the geniuses think is essential should be hashed
over first.
esoteric named individual methods and approaches should be broken down to some
basic math functionals.
path nomenclature/frequencies/material characteristics and so forth should be
categorized into easily recognizable units with descriptors that mean something
( i cant stand these single letter identifiers for variables!) anyway,
resulting compiled code wont care, but programmers do need readable text, not
everyone loves browsing through hex/binary codes!
GUI and visually appealing representations can be adapted as long as the
initial nomenclature is coherent enough to truly reflect the process, (it will
be an add-on, like tentacles sucking the process out into the light for all to
see)
speed, ha! as computer clock rates quickly approach 1 Gigahertz for home owned
PC's it is less a factor to concern with. (if your gonna do virtual
simulations, then get a super unit to begin with) memory is dirt cheap too.
let's get a "standards group" off the ground for this effort.
--
best regards,
hapticz
max reason wrote in message ...
Alessandro Del Bianco
"Bob May" <bob...@nethere.com> wrote:
> As to Object Oriented Programming, OOP is just the sooper dooper,
> ultraclever wizzbang, impressive to the managers, reinvent the wheel,
> fancy name applied to modular programming. Been doing things like
> that for many years with straight libraries and it's nothing new under
> the sun. Actually P code is an early version of doing things like
> that.
Aren't you forgetting inheritance and built-in parameters checking?
In any case OOP approach in writing a program is completely different
from the old sequential way of thinking, just have a look at the unified
modelling language. In a way is more "natural", in another makes things
much easier to mantain. I guess that Java will get more and more space
in the next few years.
Alessandro
--
Dr Alessandro Del Bianco
Carinthian Tech Research (CTR), Phone+43 (0)4242 56300-206
Badstubenweg 40 A-9500 Villach. Fax: +43 (0)4242 56300-400
Brian Blandford
downloads is actually run by ...Max Reason!
http://www.maxreason.com/software/xbasic/share.html
Brian
brian.b...@baesystems.com
"max reason" <maxr...@maxreason.com> wrote in message
news:t5imte1...@corp.supernews.com...
>
Acme Optics
software project into a tower of Babel and this one is already there.
Most of the posters have already become lost in the program style
details.
If Max releases his code as open source with the xbasic compiler, that
is what you're all gona get. It won't be OOP. It won't be C++. It
won't be Fortran.
As Doug mentioned, OSLO is already almost open source and he has an
uphill battle with ZEMAX because ZEMAX has cornered the user interface
piece of the pie and many of the ZEMAX users are not smart enough to
recognize they are using the LCD of optical design codes. A large
number of former ZEMAX uses I have spoken with have some of the
strangest stories about their experiences with ZEMAX or its company.
Things I almost can't believe so I won't repeat them here as they
would just make Ken madder at me than he probably already is.
I feel for Doug. I wish Lambda Research the best but I doubt they or
anyone else will end up besting ZEMAX in the market place in the US.
OSLO is hands down so much better than ZEMAX (and has been since day
1) that it is unbelievable to me how it has taken over but I shall try
to explain why I think it happened.
1. Every ZEMAX user who I have spoken to and who is still a ZEMAX user
has said things similar to:
We don't need all the fancy stuff in OSLO and CODE-V. We do simple
designs and the interface is easy to learn.
2. People who use CODE-V or OSLO are either considered rich or (God
forbid) really smart professional designers.
3. ZEMAX is a uniquly American entity. There are more Roadrunner users
in Europe than in the US because is is not a badge of honor in Euorpe
to be stupid.
If you are a technically oriented, intelligent, well read person in
Europe or Asia, you are honored as such. In the US you are a geek, an
egghead, a nerd. I guess nerds use OSLO and CODE-V. Jocks must use
ZEMAX.
As I have said before, most Americans are the offspring of genetically
inferior people who were either too stupid, too lazy or too dishonest
to have made it in the countries of their origin so they came here.
Half of the swiss side of my family were petty crooks and one of my
aunts relatives was hung in Oklahoma as a horse thief near the turn of
the century.
If what I said is true, how do I explain the sharp folks we have. I
like to think is is just random mutation.
Now let's all write the next great program using assembler. I have a
whole bunch of 8086 processors and 8" floppy drives we can use.
Acme Optics
Abyssmol_Unit_#3_
it come to utilty.
& agreed, too much effort is made into realms of extravagance and narrow scoped
realities, it is better to stick with the building blocks of usefulness rather
than seek the path that too many ultra-intellectuals find and ultimately end up
as obscure and unknown individuals (often dying with all their efforts going to
their grave with them!)
PS: if only them spaniards hadn't obliterated what the Mayans and others had
developed as far as mathematics. too much reliance on strict and "godly"
approved methods!
--
best regards,
hapticz
Acme Optics wrote in message ...
jaca...@my-deja.com
When one talks about "open source" one must admittedly speak about
source code which means language and and program styles...
If Max releases is source code, there are utilities that can translate
it into different source languages and syntax. I have done this with
Pascal from Brown University professors and FORTRAN into c And as you
have so copiously (and gently) reminded us, this aint rocket science,
it's just geometry. So what we want is a better and more flexible way of
manipulating the concepts. If we can't do this in an extensible manner
(with no known horizon limit), then why bother. We can use the same
chunk o' codes we got. Occaisionally, we can look at the very powerful
and flexible applications for electronics and mechanical design and sigh
wistfully...
Instead, I would rather propose and support something with a little more
potential. Something that can grow and won't rely completely on one guy
to champion and nuture the developemnt. in this case, what matters is
how to take a project to a community and benefit from combined effort
while being somewhat immune to individual incompetencies. I think you
know what I mean...
An academic question, how many source code users have ever really
modified and changed RoadRunner as opposed to tacking some user define
surface routines to the complete package? I know I looked into that fine
old program (wiping tears now..) called KDP and its source and gave up
even trying to create a road map of the main module and primary modules
in order to see where I might break in and add c routines to do the
nasty ol' file I/O. I gave up after 2 days of reading FORTRAN (I was
getting cross-eyed and couldn't submit disability or workman's comp).
And I applaud OSLO as anyone who has read my post will know; but it is
hardly open source when I have to pay over $2000 to run it. While I
really WISH that I had the ability to justify that very wothwhile
investment (from a profit motive based on booked consulting contracts),
I must also wish I could use that very well thought out and very
powerful CCL language. I have been "pining" for OSLO for a several
years now. On the other hand, I have configured, modified and recompiled
my own Linux kernels using GNU compilers for less than $50. That's open
source...
When it comes to writing the "next" generation optical code, I guess I
am still way ahead of my time...
Additional: Road Runner is great. I got the needed file and installed it
easily. Do you think that you could license CCL for RoadRunner. I quit
complaining if you did ;>
James Carter
In article <uqgr5tcelo8n3c4v7...@4ax.com>,
Bob May
"concurrent" processing isn't an option in reality. The thing that
OOP does is to formalize a method of writing programs with premade
modules that have well defined operations. Depending upon the scale
of the operation, that sort of applies to all programming - the chunks
of OOP are just a bit larger than other operations.
Acme Optics
One as far as I know and he got it to run on UNIX without the
graphics.
>
>And I applaud OSLO as anyone who has read my post will know; but it is
>hardly open source when I have to pay over $2000 to run it. While I
>really WISH that I had the ability to justify that very wothwhile
>investment (from a profit motive based on booked consulting contracts),
>I must also wish I could use that very well thought out and very
>powerful CCL language. I have been "pining" for OSLO for a several
>years now. On the other hand, I have configured, modified and recompiled
>my own Linux kernels using GNU compilers for less than $50. That's open
>source...
>
>When it comes to writing the "next" generation optical code, I guess I
>am still way ahead of my time...
>
>Additional: Road Runner is great. I got the needed file and installed it
>easily. Do you think that you could license CCL for RoadRunner. I quit
>complaining if you did ;>
If they agreed, I bet the price would go way up.
(We fired Tony Clifton last week by the way. He wasn't downloading
porno, as we first thougt. He was trying out a ZEMAX demos on company
time.) :-)
Acme Optics
devon_gr...@my-deja.com
OK, Jim, or whatever pseudonym you're using this week to avoid
the taxman, you're pushed me to the point where I am going
to have to give some factual response to your rants.
I used OSLO at Arizona when I took Lens Design from Bob
Shannon. Towards the end of the semester, we were given
an MTF-based assignment. The three of us who were using OSLO
got an "answer" very easily; those using CODE-V were stymied
for quite some time. Some never got an "answer." After the
assignment was due, we compared the OSLO answer to the CODE-V
answer and found that OSLO was not correctly computing the MTF.
This fact was mentioned to a Sinclair employee when he visited
the department and HE DID NOT CARE. Something about a well-known
bug with well-known workarounds.
Later on, I was working on a polychromatic telecentric system.
As I worked with the program, I really didn't believe my answers.
I kept trying to figure out what the problem was but couldn't.
Finally, I got an update from Sinclair that said something to
the effect that OSLO had not previously correctly calculated data for
white light telecentric systems but that the bug had been fixed.
Guess what I did? I upgraded, reloaded the lens, and got the
same wrong response. It was due to an error calculating OPD.
As Shannon used to tell us in class, always question the output,
no matter what code produced the result. Now the kicker: Zemax
gave me the correct answer both times. The answers were carefully
analyzed in order to be able to make that statement. Zemax does
an awful lot of stuff correctly which is why I use it. Sure,
I have to pay a bit but that buys me INSTANT tech support talking
to a living person. It also gives some assurance that the
infrastructure exists to support the code if someone were to
get hit by a car or meet a similar unforunate end.
By the way, Kider's program was offered to Focus Software because
his widow did not have the technical expertise to support the
users.
I'm tired of reading the rantings of a bitter, grouchy old man.
Could you please find somewhere else to vent your spleen? If you
have specific examples of Zemax doing something wrong, maybe we
could discuss that and everybody could learn something. Otherwise,
please quit using bandwidth to be nasty.
DeVon Griffin
>
snip
Acme Optics
>In article <uqgr5tcelo8n3c4v7...@4ax.com>,
> Acme Optics <acmeo...@earthlink.net> wrote:
>> snip
>
>
>OK, Jim, or whatever pseudonym you're using this week to avoid
>the taxman, you're pushed me to the point where I am going
>to have to give some factual response to your rants.
>
>I used OSLO at Arizona when I took Lens Design from Bob
>Shannon. Towards the end of the semester, we were given
>an MTF-based assignment. The three of us who were using OSLO
>got an "answer" very easily; those using CODE-V were stymied
>for quite some time. Some never got an "answer." After the
>assignment was due, we compared the OSLO answer to the CODE-V
>answer and found that OSLO was not correctly computing the MTF.
>This fact was mentioned to a Sinclair employee when he visited
>the department and HE DID NOT CARE. Something about a well-known
>bug with well-known workarounds.
Then that is BAD and it should have been fixed by Doug. I am quite
sure Doug would have taken it seriously. Maybe it was less than an
ideal employee.
How long ago was it? I'm curious.
>
>Later on, I was working on a polychromatic telecentric system.
>As I worked with the program, I really didn't believe my answers.
>I kept trying to figure out what the problem was but couldn't.
>Finally, I got an update from Sinclair that said something to
>the effect that OSLO had not previously correctly calculated data for
>white light telecentric systems but that the bug had been fixed.
>Guess what I did? I upgraded, reloaded the lens, and got the
>same wrong response. It was due to an error calculating OPD.
That is also very very bad. No program should have unresolved errors
like that in it.
When a bug is reported in Roadrunner, we drop literally everything and
fix the bug as soon as possible (usually within a day or two at the
most). Then we upload the fix and post an announcement on sci.optics
stating exactly why the new fix and exactly what the bug was. If we
don't state how we fixed it and someone asks, we tell them via email
or another post.
I take bugs seriously. I pride myself at not having a list of known
bugs. Only a list of fixed bugs (the NEWSTUFF.PDF file distributed
with Roadrunner).
>
>As Shannon used to tell us in class, always question the output,
>no matter what code produced the result. Now the kicker: Zemax
>gave me the correct answer both times. The answers were carefully
>analyzed in order to be able to make that statement. Zemax does
>an awful lot of stuff correctly which is why I use it. Sure,
>I have to pay a bit but that buys me INSTANT tech support talking
>to a living person. It also gives some assurance that the
>infrastructure exists to support the code if someone were to
>get hit by a car or meet a similar unforunate end.
That is important. The bus thing is exactly why I make the source for
Roadrunner available. It is no way as good as an infrastucture, but it
is my attempt to address the problem till we get an infrastructure.
Comparisons of MTF between CODE-V and ZEMAX and Roadrunner on one IR
system agreed pretty well but not exactly. Then again anyone who
believes an MTF to better than 0.05 probably also literally believes
in Santa Claus delivering toys and not the fact that Santa Claus is
the nice guy that lives inside most of us.
>
>By the way, Kider's program was offered to Focus Software because
>his widow did not have the technical expertise to support the
>users.
And he killed it! That was a loss to everyone in the community. Anyone
(and unfortunately this includes Doug) should be ashamed of themselves
for buying an optical design program just to kill it off and take over
the users. Maybe good business but shitty science.
>
>I'm tired of reading the rantings of a bitter, grouchy old man.
>Could you please find somewhere else to vent your spleen? If you
>have specific examples of Zemax doing something wrong, maybe we
>could discuss that and everybody could learn something. Otherwise,
>please quit using bandwidth to be nasty.
I'm sure if I listed them I'd just get a better stomping than I
usually get. Try MTF of an off axis parabolic reflector. Clear
aperture 5 units. EFL 2.5 units. This give an f/0.5 parabola.
Now off-set the aperture by 2.5 units and compare the MTF in CODE-V
with that of ZEMAX. If they agree, Ken fixed the pupil distortion
problem. If not he didn't. CODE-V gives the correct answer. I have not
run a test in OSLO.
One designer uses Roadrunner because he said that pupil distortions
were not done correctly in ZEMAX. I did not verify it myself.
Two folks I know design with ZEMAX but will not use anything but
CODE-V for tolerancing. They just trust it.
The industry standard is CODE-V! All arguments to the contrary will
fail hard tests. Life is a bitch ain't it?
>
>DeVon Griffin
>
In an area like ours (optical design) with so few codes to choose from
and such detailed calculations, some of which are not doable by hand,
every optical design vendor owes it to all of the community to provide
the best bug free software which they possibly can provide. If profit
suffers, that is just part of living in an imperfect world.
I will not be quiet when I know that if I can fix all of the known
Roadrunner bugs as soon as they are reported and hold down a real job
to boot, then Ken and Doug and ORA and anyone else you want to add to
the list can do it to and when they don't, they cheat their customers.
Sincerely,
Acme Optics
max reason
> As I mentioned to Max Reason before. It does not
> take much to turn a software project into a tower
> of Babel and this one is already there.
>
> Most of the posters have already become lost in
> the program style details.
>
> If Max releases his code as open source with the
> not a badge of honor in Euorpe to be stupid.
>
> If you are a technically oriented, intelligent, well
> read person in Europe or Asia, you are honored as such.
> In the US you are a geek, an egghead, a nerd. I guess
> nerds use OSLO and CODE-V. Jocks must use ZEMAX.
>
> As I have said before, most Americans are the offspring
> of genetically inferior people who were either too stupid,
> too lazy or too dishonest to have made it in the countries
> of their origin so they came here.
>
> Half of the swiss side of my family were petty crooks and
> one of my aunts relatives was hung in Oklahoma as a horse
> thief near the turn of the century.
>
> If what I said is true, how do I explain the sharp folks
> we have. I like to think is is just random mutation.
>
> Now let's all write the next great program using assembler.
> I have a whole bunch of 8086 processors and 8" floppy drives
> we can use.
> Acme Optics
I just checked this newsgroup after a couple days and
I also wonder if open-source optical design software
will work in practice. My guess is, like many things,
it mostly depends on how skilled, diligent and serious
the few people are who decide to become involved in it.
So many issues were raised in the many messages posted,
I cannot prevent this reply from being a scattershot.
So here goes.
I may not have said this explicitly, but subconsciously
I assumed the software would be substantially enhanced
after it is made open-source before it is acceptable to
a large majority of people for a large majority of work.
It works now, but understand that wrote the first version
of the software in 1970 or thereabouts, and have developed
dozens of specialized versions over the years to solve
specific problems. Unfortunately, not everything useful
from all those versions has remained in the core, and
digging through old 8" floppy disks to find these nuggets
is almost certainly unwise - better to just add them anew.
The software works, and I would probably enjoy working
with a few straightforward, results-oriented people to
restore axed capabilities, add new capabilities, make it
support more universally accepted conventions, and make
the GUI more friendly - unless the consensus is anti-GUI.
I have two versions. The XBasic version has a mix of
keyboard/command/console and GUI interface. I was part
way through adding the GUI interface when I had to put
it aside to work on other projects - quite a while ago.
The C++ version is only the core routines - it loads
a glass-database and catadioptric design from disk,
runs it, and prints results to a console so I could
verify its results against the XBasic version.
An open-source project could start from either version.
The XBasic version:
+: XBasic is open-source freeware compiler.
+: XBasic and XBasic programs run on Windows AND Linux.
+: XBasic source-code runs unmodified, including GUI/graphics.
+: XBasic graphics is very easy to code, and GUI isn't bad either.
The C++ version:
+: Super-optimized C++ is 10% to 100% faster than XBasic.
+: C++ is more "politically correct" - read "object oriented".
+: Opens up software to other CPUs (XBasic is only Pentium CPUs).
-: Some people will need to buy C++ compiler/IDE/graphics/GUI packages.
-: Difficult to find graphics/GUI packages portable between Windows/Linux.
Other versions:
-: Java is politically correct, but SLOW.
-: I don't know PASCAL or PASCAL variations.
-: I haven't programmed in FORTRAN for 20 years.
Disclaimer: The above is MY list, and therefore
not implied to be the same as anyone else's list.
All these years I've been designing optics with my software.
Therefore I haven't been exposed to the "usual conventions"
of other optics software, so that's where the process starts.
From what I've read, I think the only way this project would
have a chance is to "start small, start well". What I mean is,
start with myself and 2-4 other skilled programmers who also
understand optics and optics-programs, and spend a few weeks
to make an "initial release" ready for first comments.
Understand, not knowing the needs/activities/inclinations
of the people in this newsgroup, I'm not even sure the whole
idea isn't futile. Others need to comment on that, because
I only ran into this newsgroup a few days ago.
Another disclaimer: I myself have no interest in ever turning
this software into commercially sold software. If it covered
by the usual GPL open-source license, others could sell software
based on the existing and subsequently-developed source-code,
but only if they supplied ALL source-code (our code and any
code they added) to everyone the gave/sold the software too.
I may occasionally design optics for $$$, but have absolutely
zero interest in ever selling optical design software.
Also, I'm probably "genetically inferior" and surely a mutant.
I have not yet looked at RoadRunner or ZEMAX or OSLO or any
of the other optics software people have mentioned. I have
other irons in the fire, and I'm one of those people who can
invent and make something faster than learn from documentation.
Anyone who "invents-and-makes" knows how much better you KNOW
the tool - when you created it. :-) Well, usually. :-o
I'll try to take a look at some of them in the near future.
I am not anti-profit, anti-business or anti-commercial.
But I'm not against open-source or freeware either.
I have no axes to grind in those fights.
A few basic facts. Someone (?maybe Acme?) mentioned a whole
slew of features the software must/should have (I recall/infer).
Well it ain't gonna start out with everything, understand that.
I didn't even understand a bunch of the terminology, though
I'm sure I just have different names (or no names at all)
for some of the mentioned items. I'm perfectly willing to
hear "the whole effort ain't worth the effort in that case".
No skin off my nose (where did THAT expression come from?).
All depends on people being interested in "doing/using this".
Optical surfaces supported: conics including oblate-spheroids,
schmidt-plates, zonal-figuring of conics (somewhat clunky).
Glasses in glass database: 672 glasses including fluorite,
quartz, plus three major glass catalogs from ~10-15 years ago.
More glasses/info easily added - fixed-format ASCII file.
Colors in glass database (more can be added easily):
3200A 3650A 4047A 4358A 4861A 5461A 6563A 6893A 7065A 10140A
Note: currently no data for 3200A.
Computes and displays:
optical layout
vignette in-out
aberration curves
spot and plot diagrams
optical path difference
image wavefront/interference
A few old versions had the ability to be driven by what some
would call macro/command files, but not the current version.
The program saves the position/direction of every ray
in every color at every skew-angle at every surface.
When my computer was 1000 times slower, this let me
move/bend a surface and only need to trace subsequent
surfaces to the new focal surface, not the whole design.
That efficiency became so much less important in recent
years (as CPUs got faster) that I switched back to the
simpler "always trace everything" code. But the data
is still saved, so the old "fast way" can be reinstated
if someone has the need.
I'll just watch messages for a while and see whether any
consensus arises. Question to those of you who would enjoy
open-source optics design software. What features/capabilities
do you need - and which do you want.
Martin Euredjian
news:t5sb7c8...@corp.supernews.com...
> Try as you want to, this ol' PC still only does one thing at a time so
> "concurrent" processing isn't an option in reality. The thing that
> OOP does is to formalize a method of writing programs with premade
> modules that have well defined operations. Depending upon the scale
> of the operation, that sort of applies to all programming - the chunks
> of OOP are just a bit larger than other operations.
All C++ compilers translate the code to C before anything else.
-Martin
Doug Sinclair
> devon_gr...@my-deja.com wrote:
>
> >In article <uqgr5tcelo8n3c4v7...@4ax.com>,
> > Acme Optics <acmeo...@earthlink.net> wrote:
> >> snip
> >
> >
> >OK, Jim, or whatever pseudonym you're using this week to avoid
> >the taxman, you're pushed me to the point where I am going
> >to have to give some factual response to your rants.
> >
> >I used OSLO at Arizona when I took Lens Design from Bob
> >Shannon. Towards the end of the semester, we were given
> >an MTF-based assignment. The three of us who were using OSLO
> >got an "answer" very easily; those using CODE-V were stymied
> >for quite some time. Some never got an "answer." After the
> >assignment was due, we compared the OSLO answer to the CODE-V
> >answer and found that OSLO was not correctly computing the MTF.
> >This fact was mentioned to a Sinclair employee when he visited
> >the department and HE DID NOT CARE. Something about a well-known
> >bug with well-known workarounds.
>
> Then that is BAD and it should have been fixed by Doug. I am quite
> sure Doug would have taken it seriously. Maybe it was less than an
> ideal employee.
>
> How long ago was it? I'm curious.
This was 5-10 years ago, about the time we were switching the old OSLO MTF
over to the GENII covolution-based MTF. There was no bug. What happened is
that apparently some students got low answers because they were
undersampling the aperture. We reviewed what happened with Prof. Shannon and
changed our default aperture division factors to make it less likely for
this to happen to inexperienced users. We showed to his satisfaction that
the change fixed the problem, while retaining the ability of OSLO to handle
complicated apertures correctly.
> >
> >Later on, I was working on a polychromatic telecentric system.
> >As I worked with the program, I really didn't believe my answers.
> >I kept trying to figure out what the problem was but couldn't.
> >Finally, I got an update from Sinclair that said something to
> >the effect that OSLO had not previously correctly calculated data for
> >white light telecentric systems but that the bug had been fixed.
> >Guess what I did? I upgraded, reloaded the lens, and got the
> >same wrong response. It was due to an error calculating OPD.
>
> That is also very very bad. No program should have unresolved errors
> like that in it.
>
Again, there was no error. Our answer was that OSLO had not previously
calculated OPD for white light. The reason that it hadn't is that the
concept of OPD for white light is problematical. You can't measure it in the
lab. Nevertheless, you can construct something that is sort of like what it
might be if it existed, so ultimately we did add it, and OSLO gets results
similar to Code V. I think its sleight of hand that does not promote
understanding, myself.
>
>By the way, Kider's program was offered to Focus Software because
>his widow did not have the technical expertise to support the
>users.
> And he killed it! That was a loss to everyone in the community. Anyone
> (and unfortunately this includes Doug) should be ashamed of themselves
> for buying an optical design program just to kill it off and take over
> the users. Maybe good business but shitty science.
>
I would like some explanation of this. A major part of OSLO consists of
extensions of GENII code, including the above-mentioned MTF, the
optimization, and several other features. I view our merging of OSLO and
GENII as a contribution to the world of optical design. Maybe you're talking
about something else.
-Doug
Acme Optics
I admire your attitude after all the posts. Th think I would have been
discouraged. It you're not, then this project is a possibility.
I don't have time to be involved in another code at the CODE level but
if any of the folks working it get stuck with how to calculate
someting or need a comparison case run in Roadrunner or anything else
I currently have access to, just email or call me and I'll help all I
can.
Best of luck,
Acme Optics
Acme Optics
>>
>I would like some explanation of this. A major part of OSLO consists of
>extensions of GENII code, including the above-mentioned MTF, the
>optimization, and several other features. I view our merging of OSLO and
>GENII as a contribution to the world of optical design. Maybe you're talking
>about something else.
>
>-Doug
>
>
same can't be said for ZEMAX and Kidger's code but if I am wrong I'd
like to know.
Acme Optics
>
Acme Optics
I found it hard to believe you would have left known bugs. You're too
careful and conscientious a scientist for that.
It is amazing how 10 year old bugs never seem to die in the minds of
the user. I have had similar experiences. People who say my first DOS
interface, still hold it against me and probably always will.
Acme Optics
Acme Optics
SAW
Acme Optics <acmeo...@earthlink.net> wrote:
>Hi Doug,
>
>I found it hard to believe you would have left known bugs. You're too
>careful and conscientious a scientist for that.
>
>It is amazing how 10 year old bugs never seem to die in the minds of
>the user. I have had similar experiences. People who saw my first DOS
Acme Optics
Complaining about 10 year old bugs without finding out if they were
ever fixed was bad form on your part.
Falling into the trap was bad form on my part.
Acme Optics
Bob May
> porno, as we first thougt. He was trying out a ZEMAX demos on
company
> time.) :-)
9-(,)
devon_gr...@my-deja.com
"Doug Sinclair" <d...@sinopt.com> wrote:
>
> "Acme Optics" <acmeo...@earthlink.net> wrote in message
> news:v8ms5t4pf1sd2rqqu...@4ax.com...
> > devon_gr...@my-deja.com wrote:
> >
> > >In article <uqgr5tcelo8n3c4v7...@4ax.com>,
> > > Acme Optics <acmeo...@earthlink.net> wrote:
> > >> snip
> > >
> > >
> > >
This was before the OSLO/Genii merger. If someone made
Professor Shannon happy, he never told us about it. I checked
with a student who took the class when I did.
> > >
> > >Later on, I was working on a polychromatic telecentric system.
> > >As I worked with the program, I really didn't believe my answers.
> > >I kept trying to figure out what the problem was but couldn't.
> > >Finally, I got an update from Sinclair that said something to
> > >the effect that OSLO had not previously correctly calculated data
for
> > >white light telecentric systems but that the bug had been fixed.
> > >Guess what I did? I upgraded, reloaded the lens, and got the
> > >same wrong response. It was due to an error calculating OPD.
> >
> > That is also very very bad. No program should have unresolved errors
> > like that in it.
> >
>
> Again, there was no error. Our answer was that OSLO had not previously
> calculated OPD for white light. The reason that it hadn't is that the
> concept of OPD for white light is problematical. You can't measure it
in the
> lab. Nevertheless, you can construct something that is sort of like
what it
> might be if it existed, so ultimately we did add it, and OSLO gets
results
> similar to Code V. I think its sleight of hand that does not promote
> understanding, myself.
>
The OPD error cropped up in monochromatic traces and that
propagated to the polychromatic stuff.
DeVon Griffin
devon_gr...@my-deja.com
Acme Optics <acmeo...@earthlink.net> wrote:
> devon_gr...@my-deja.com wrote:
>
> >
>
> I'm sure if I listed them I'd just get a better stomping than I
> usually get. Try MTF of an off axis parabolic reflector. Clear
> aperture 5 units. EFL 2.5 units. This give an f/0.5 parabola.
OK, here's the problem. You are trying to use Zemax for
an F/0.5 system. Quoting from the manual for 9.0, it says
on p. 84, "Because Zemax does not account for vector diffraction,
the MTF data may not be accurate for systems faster than about
F/1.5."
While you can quibble about whether or not vector diffraction
should be included in a lens design code, saying that a feature
is not included is dramatically different than saying that
an error is present. In this case, the fact that the field
is being incorrect propagated, as stated in the manual, makes
any further statements about comparisons meaningless.
I think answers for this type of a system probably ought to be
compared against GLAD or DIFFRACT.
DeVon Griffin
Acme Optics
>In article <v8ms5t4pf1sd2rqqu...@4ax.com>,
> Acme Optics <acmeo...@earthlink.net> wrote:
>> devon_gr...@my-deja.com wrote:
>>
>> >
>>
>> I'm sure if I listed them I'd just get a better stomping than I
>> usually get. Try MTF of an off axis parabolic reflector. Clear
>> aperture 5 units. EFL 2.5 units. This give an f/0.5 parabola.
>
>
>OK, here's the problem. You are trying to use Zemax for
>an F/0.5 system. Quoting from the manual for 9.0, it says
>on p. 84, "Because Zemax does not account for vector diffraction,
>the MTF data may not be accurate for systems faster than about
>F/1.5."
You have got to be kidding!
This can be corrected for by accounting for the distortion in the exit
pupil. In many programs when rays are aimed, they go to a uniform grid
in the stop surface. If that does not map to a uniform grid in
direction cosine space in the exit pupil, you don't get the right MTF
answer if the MTF is based on the complex aperture function. You also
don't get the correct PSF!. I fixed it in Roadrunner in a manner
equivalent to CODE-V's fix (remapping the pupil to represent a unifom
grid in direction cosine space either at the entrance or exit pupil
considering in which space the calc is being performed) and it has
nothing to do with VECTOR DIFFRACTION. It has to do with writing a
decent optical design program. This also corrects the fact that even
if the entrace pupil is uniformly illuminated, the exit pupil may not
be. (For those smart enough, this is called apodization). Can we all
spell APODIZATION? Let's have that be your new word for the day.
I personally think anyone who would spend $1000 or $2000 or $3000 on
an optical design program that does not give correct MTF answers for
systems faster than f/1.5 is a complete idiot and anyone who would
charge this much for a code with these difficulties is not interested
in optics or science. They are just interested in how well they can
line their pockets with your money.
>
>While you can quibble about whether or not vector diffraction
>should be included in a lens design code, saying that a feature
>is not included is dramatically different than saying that
>an error is present. In this case, the fact that the field
>is being incorrect propagated, as stated in the manual, makes
>any further statements about comparisons meaningless.
>
>I think answers for this type of a system probably ought to be
>compared against GLAD or DIFFRACT.
You, sir are an idiot! Then, I guess you need to tell yourself
anything necessary to keep from seeing a donkey every time you look in
a mirror considering how much of your money or your company's money
you have thrown away on an optical design program that can't do
correct MTF's on systems faster than F/1.5.
Acme Optics
Brian Blandford
would be for XBASIC rather than for C++, since that is all I can access at
work, and BASIC is all
I (and my colleagues) are fluent in.
brian.b...@baesystems.com
Optical Engineering Department
BAE SYSTEMS, Basildon.
"max reason" <maxr...@maxreason.com> wrote in message .....