Is it possible to calculate the 'field Type' 'Angle' (Code 0) from the 'field Type' 'Real Image Height' (Code 3) with a ZPL script?
It is basically what the Zemax 'Field data editor' offers with the 'Convert to' option. However, I do not need to *convert* the field type, but just have to determine the value.
With 'Single Ray Trace' as well as with the operand 'RAID', I only get one angle. But I need the two angles as defined for the 'field Type' 'Angle'
Thank you and best regards,
Christof.
+2
Hello Christof,
Thanks for your question here!
The easiest way to get the angles in Object Space is to insert a Dummy surface before all surfaces and use the RAID Merit Function Operand with the normalized field heights. In order to get the two angles, you have to use the RAID operand with two different Hx,Hy parameter pair.
If the Field Normalization type is Rectangular, you have to use RAID with Hx=1 and Hy=0 to get the X-Angle, and for the second time use RAID with Hx=0 and Hy=1 to get the Y-Angle.
If the Field Normalization type is Radial, you can use the real image height values and normalize them with the maximum radial field value returned by the MAXF() numeric function. In this case, you have to use RAID with Hx=Real-X-Height/MAXF() and Hy=0 to get the X-Angle, and for the second time use RAID with Hx=0 and Hy=Real-Y-Height/MAXF() to get the Y-Angle.
I hope this helps! If you have any further questions please let us know and we will be happy to help!
Best,
Csilla
Hello Csilla,
Thank you for your message.
You are assuming, that the X-Angle is a function of the X-position in the image field *alone* and the Y-Angle of Y only. Right?
This is unfortunately not the case here due to distortions in my wide angle off-axis system.
This means, I have the complete 2-dimensional image plain and need a two dimensional array of corresponding angles.
Is it the CNAX, CNAY operands in this case?
And is (Hx,Hy) really the exact normalized position of the *image* space? I am confused because there seems to be no distinction between normalized object space and normalized image space. Both seem to be associated with (Hx,Hy). But again, there is no easy linear mapping between them.
I would prefer to use a field number and set the field to its physical coordinate in the image space in mm.
Best, Christof.
+1
Hi Christoph,
I think you could use CNAX and CNAY effectively for your needs. You could also, if relevant for your calculations, the direction cosines in X and Y via the REAA and REAB operands.
For Hx and Hy, they are the normalized positions in the object space, ranging from -1 to 1.
Best regards,
Kevin Scales
'Hx and Hy, they are the normalized positions in the object space'
My system has an afocal object space. How are Hx, Hy defined in this case? As the normalized object space incidence angles? But the incidence angles are exactly what I do not know. I have to determine them from the spot positions in the image plain. There is no trivial relation between incidence angle and spot position in my system.
+1
Hi Christoph,
When you say you have afocal object space, do you mean that it is telecentric? If that is the case, it is not possible to use angles for field definitions. Hx and Hy are in distance units, not angle. If not, then how exactly do you have your system set up?
If you like, it might be beneficial to start a portal case on MyZemax so you can share screenshots or whole systems with us.
Hi Kevin,
No, it is not telecentric.
It is a space telescope (with a subsequent spectrometer and photometer).
As the object space in a telescope is in infinity, the angles of incidence are a common way to define the field positions.
Another way is to define the spot locations on the image sensor. This is more useful for the sensor simulations (outside of Zemax).
Therefore, I want to define the fields as the locations in the sensor plain (image plain). This is actually the input I get from the sensor people (it is a space telescope with many people working on different parts.)
But then I need to calculate the incidence angle. This is actually what the Zemax 'Field data editor' offers with the 'Convert to' option. However, I do not want to convert, but just to know these angles. And I want to do it inside of a ZPL flow. It has to be completely automated.
I think that Hx, Hy are normalized field positions in the *object* space. So in my case these are probably the normalized angles of incidence. Is this correct?
Therefore, CNAX, CNAY are not useful here, as they require the incidence angles in turns of Hx, Hy as input. This means: The input for CNAX, CNAY is just what I need as output.
I only have the image plain positions as input. And they can not be used to calculate Hx, Hy due to image distortions (and in case of the specrometer, it is even more than normal distortion).
Best regards,
Christof.
+1
Hi Christof,
I think I have better grasp on what you're asking now. And to start, I want to correct myself. The Hx,Hy are in terms of field units. Usually they are in object space, but if you are using Real Image Height or Paraxial Image height, then they will be image space values.
For your situation, it looks like the answer is to use a slightly different set of operands. RAID returns a single angle, the ray deviation from the normal, but you can also use X and Y specific operands. RETX,Y return a signed tangent value (slope) of the angles in X and Y, and you can get the angles back with ATAN. Or, if you have a preference, REAA,B return the X and Y direction cosines, to which you can then apply ACOS to get an angle. It will be close to 90, so you'll need to subtract from 90 to get the deviation (define 90 with CONS and then use DIFF to subtract). The answer is the same, so I prefer RETX,Y for having fewer lines.
The advantage is that if you are using Image Size as your field, then you can just plug in these Hx,Hy values into the operand and the surface number (probably 1 or something low, depending on how you've set it up) and OpticStudio will know to apply the measure to the correct location for the correct output. These are all doable with the ZPL, so you should be able to automate as needed.
Of course, please let us know if this is still not what you need.
Kevin
Hi Kevin,
What do you mean with 'The Hx,Hy are in terms of field units.' They should be in units of a maximum field and dimensionless.
So Hx and Hx are always defined in the space which is set in the 'field type', right? This is really very very nice to know. It seems to be missing in the manual?
Suppose, I am using the 'field type' 'Real Image Height'.
And suppose I use the Field Normalization type 'Radial'.
Then I get from (X,Y) in image space in [mm]
Hx = X/MAXF()
Hy = Y/MAXF()
(This actually what Csilla already explained)
Now, I can use ATAN(RETX,Y)
Why shouldn't I use CNAX,Y which returns the angle directly?
'This operand computes the X angle in radians relative to the local Z axis of the centroid of rays from any field point. The centroid accounts for apodization and apertures, and optionally polarization.'
I think the difference is that RETX uses a single ray (e.g. the chief ray), while CNAX uses a cone of rays.
The 'Real Image Height' is defined with the chief ray. So I guess that your approach with ATAN(RETX,Y) and based only on the chief ray is more consistent. Although definitions that are based on single rays are always problematic, especially with measured surfaces... A disadvantage of 'Real Image Height'.
So thank you Kevin and Csilla, for your support. It was a bit complicated, but I think I got the required information from you. I feel relieved that it works at all within ZPL.
Take care,
Christof.
And then we should note, that we always need to define a field larger in radius than the one defined with Hx = X/MAXF()
Hy = Y/MAXF(). Otherwise it gets wrong w/o warning 
.
Hi Kevin,
I found a certain problem:
I am working with a rather complex off axis configuration and with a binary type surface.
For this file, everything works ok as long as I use the field type 'angle'.
But as soon as I use 'real image hight', Zemax is almost all the time blocked due to calculations. But I need this field type to get the incidence angles from the image positions.
I tried it with a script (using CNAX that calculates with a whole ray cone), but the resulting angles (after a long calculation) are often wrong. Often simply (0,0). So I guess this is an iteration that does not converge correctly, right?
With a similar design without binary surface, it is still slowed down, but the final results are correct.
Do you know, if there are any settings ore something to improve the convergence?
Thank you,
Christof.
PS: Could you delete my empy posts below?
+1
Hi Christof,
I'm puzzled at what you are describing. I put together a simple system using Binary 1 and CNAY with real image height fields and it works just fine. Odds are it is some setting that is causing this, but it might be hard to figure out. If you would like to make a formal case on the Portal and share your actual system with us, we can take a closer look and see what might be going on. Would that work for you?
More successfully, I did delete your empty posts.
Best,
Kevin
Thanks for this offer! I am trying to find out if I am allowed to pass on the optical design.
For the moment I found a workaround: With field type 'angle' I use the meret function to find the field positions. This way, it converges quite well. Amazing, isn't it?
Best, Christof.
+3
Hi Christoph,
I have to admit to not understanding the problem. As you said in your first post, you can use 'Convert to' to get the field definition in object field, and then just use it again to go back to image height. What's wrong with that?
Also, the field of view is ultimately set by just one ray: the primary wavelength chief ray. Whether you define by angle, object height, paraxial image height, real image height or theodolite angle, it's the same ray with the same data. What's wrong with just raytracing the chief ray and extracting the data you need?
Sorry to be dense,
- Mark
The chief ray is not necessarily the best representation of the spot position. It can be defined with the chief ray, but the COM is physically more usefull. Especially with measured surfaces, a single ray is a bad choise. in Zemax, we have often the choise between Chief ray and COM for references.
The problem is that the 'real image hight' blocks the tool and after long calculations frequently converges to wrong positions. I think it is a specific problem of my rather complex design.
I think I can send it to you, provided it is treated confidential, because it is at this point in time not public.
Best regards, Christof.
+3
Ah, I think I get it now. The Field and Aperture tabs in the System Explorer define the primary wavelength chief and marginal rays, and we can easily convert between the various definitions of them (chief ray angle to real image height, for example). But you get that, and that's not the problem. Is that correct?
I think your problem is that you have a spot with a centroid location and some shape on the image surface, and you want to know what the corresponding angles and locations measured from the object are. Is that right?
+1
Hi Christoph,
If Mark's expertise hasn't gotten you through yet, we do treat all files as confidential. They are never shared and they are disposed of after some length of time (or sooner if you like). If you wish, you can open a case on the portal and attach whatever you wish to share, preferably in a .ZAR archive format.
Ok, I'll open a case case. I think so it will immediately become clearer .
Thanks!
Christof.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.