I see the 21.3 release in the Software Downloads section.  Will let you know how it looks to me inside OpticStudio.

Now for my question...I see a link to the Release Notes on the Software Downloads page where it has always been, but it is now a link to a post in this Community displaying the release notes . (post by William Massey)

• Community >
• Zemax Product Updates >
• Zemax Product Updates >
• OpticStudio Release Notes >
• OpticStudio 21.3 Release Notes

Are Release Notes no longer available as a PDF for download??

Mark’s right, in my 21.2.2 version of Professional, Check For Updates brings up the message, “You are running the current version of OpticStudio.”

I’ll download and install 21.3 anyway...

-- Greg

Hi Greg,

We’re now posting the Release Notes on the Community rather than as PDFs. This change means that the search can be used to find content within the current and previous Release Notes which wasn’t possible with the PDFs.

For example, you can now easily find when a particular feature was added or search for details on a specific bug fix. 

Thanks for the explanation, William.

Good reasoning, but I’d like a PDF to download, too.  That way I can look things up when working offline.

-- Greg

Hi William,

OS now recognizes that the latest release is available, thank you. I’m still curious about the new file format. Does the .ZOS include all the .cfg etc? So how is it different to the ZAR? It doesn’t seem any faster on loading from my limited tests.

Also, how do I access the new Project Preferences? I had a look in Preferences but couldn’t see it. I’m probably just missing it...but where is it?

• Mark

Hi Mark, 

Hope all’s well! To you questions about the new binary file format, for the time being, you can think of the .ZOS file as a 1:1 replacement for the .ZMX file. That said, going forward, the .ZOS format provides the foundation on which we can build potential future improvements like more granular undo/redo or version control. Right now, though, the main benefits of the .ZOS file format are:

1. File Security: the files are not human readable, so lens prescription data is more secure.
2. Load Times: there’s a modest speed improvement (roughly 5-10%) over .ZMX files.
3. File Size: for files that contain a Merit Function (MF) or Multi-Configuration Editor (MCE) of any significant size, the .ZOS file is significantly smaller than .ZMX files; however, if the file doesn’t contain a MF or MCE, there isn’t a significant difference in size between the file types.

Regarding your question on the Project Preferences, I’m guessing you mean the Project Directory functionality. This is actually managed in File Tab and the System Explorer. You can convert a file to the Project Directory structure using File...Convert to Project Directory, and then confirm whether this is set for a given file under System Explorer...Files...Is a Project Directory. 

Let us know if you have any other questions here!

Cheers,

Nick

Hi Nick,

Thanks for that. So with .ZOS files, do we still have .CFG files? That’s important for ZPL and ZOS-API control of Analysis features.

Ah, so the IsProjectDirectory flag overrides the normal placement of supporting files, I get it. I presume any updates to say glass catalogs in the Project Directory must be made by hand, and that OS will only update the files in /documents when a later version comes out?

Last, I am really pleased that the project directory uses text-based .ZMX and not .ZOS files. Since the overwhelming majority of your users are human, a human-readable file format has its uses, not least for basic file versioning. Could I make a suggestion? If you do update the Project Directory to use ZOS files, consider also writing out a {filename}_manifest.txt file than contains the Prescription Report. That way there is something that is easily readable by the mortal users and that can be picked up easily for file versioning. I can see lots of people wanting to use GitHub for versioning, so creating the helper files for GitHub would be great.

Thanks again,

• Mark

Hi all,

I am happy to see this thread which is mostly about the new file format. I understand the interests of it - even if I have my doubts about the security argument but why not…

My worry is more that with the old file format, it was easy to write an external parser. We use it to scroll quickly through design iterations, for example. Is there some file format documentation that would allow this with the new .zos file format? I suppose Mark’s suggestion above is also a way out of this :)

Thanks,

Raphael

Hey @Raphael.Proux, the File Comparator in OS does that for you already, no need for an external parser

@PhGeek - Even though we aren’t publishing them directly as PDFs any longer, You could also print the release notes web page to PDF. It makes a very readable file. 

@Mark.Nicholson - Note that if the lens file you are working with is already a ZOS file, converting it to a project will still include a ZOS file. So you can choose which file format you want in your project.  

I just installed 21.3 and have the same concerns about file format as above:  What setting can I enter that will save ONLY in *.ZMX text format?  I don’t anticipate ever wanting or needing to use the ZOS binary file format.  Like Raphael above, I want to be able to directly parse ZMX files with or without starting up Zemax.

Mike

Hi @Mark.Nicholson 

Thanks for the tip, the file comparator does a complementary job to what I want and is quite different. In any case, I have many other examples of usage where we use the Zemax file as input for other stuff. A quick list: costing model, tolerancing, shape correction in prototyping... Cases where I don’t want to use Zemax, whether it is because it is not installed or because it is too slow…

I am not saying there are no workarounds (the most obvious being exporting a text file from zemax everytime it is needed). However, having documentation on the binary format to be able to parse it is probably the ideal solution for me :)

Thanks,

Raphael

My concern with 21.3 and onward is that I fear Zemax may become ransomware for my lens files.  We all MUST continue to have text versions of our future lens files.

From what they say, the ability to produce ZMX files will be retained. But I’m not sure I agree with you Mike. The vast majority of the programs I use do not use text files. While it can be handy, I can’t think of any reason we ‘must’ have a text file. And TBH, the text version of a non-sequential file is pretty unreadable in any case.

What I would personally love to see is file opening speeds improving. The new ZOS format doesn’t appear to offer any benefit to users right now. The team at Zemax say that it will be the basis of future developments that will give benefits. Lets see what the future holds.

• Mark

You know what would help Zemax immensely is to have a seat of CODE-V right there with them.  CODE-V has always had the option to write all lens file data to either binary *.len files or *.seq text files.  Everything.  No holding back anything whatsoever in the *.seq text file.  And CODE-V has not threatened to cancel or limit *.seq files.  Zemax should do the same in future ZMX text files.  Text lens files are essential in reconstructing lost files, and especially in creating or editing files when limited access to Zemax exists due to insufficient licenses.  And, I find the ZMX text files quite readable and parse-able, especially in MATLAB.  I’ll state it again: I don’t want Zemax to become ransomware for lens files created at significant labor costs.  Zemax is better than that.

Hey all,

I agree with Mike. What do you think of documenting the format so we can make our own parsers? I can see the interest of an improved file format and possible future functions you don’t want to disclose.

However, many of us have developed tools around Zemax and the .ZMX format. Changing the file format is a clearly negative signal. To me, it also looks quite contradictory to the philosophy behind amazing functionalities like ZOS-API, which open the software to the outside. ZOS-API is one of the main features that make me work with Zemax rather than Code-V.

Hi Zemax staff,

Can you inform us on your plans about documenting or not the ZOS format?

Thanks,

Raphael

Hi Raphael, 

To answer your question, at this point, Zemax does not intend to publicly document the structure of the .ZOS file format. That said, as you mention, our publicly documented API (ZOS-API) is a really great tool for interfacing with external software, and it can be used to directly read both .ZOS and .ZMX files. So, if you need to pull prescription information directly from an OpticStudio model, you can still do so using ZOS-API.

Thanks,

Nick

This sounds promising, Nicholas.  Can you post the ZOS-API code to do this, with output from say the standard double Gauss you use?  I haven’t had time to dig down into API yet, so this would be a good introduction as well as practical and useful.

Mike

Hi Mike, 

Sure thing, it’s not with the Double Gauss, but we walk through the process of accessing LDE and System Explorer data for the “Cooke 40 degree field.zmx” sample file in the following article: How to convert any sequential surface to a Grid Sag Surface using the ZOS-API. The section you’ll want to check out is titled, “Open and investigate the "Cooke 40 degree field.zmx" sample file.” Code is also included inline and in the attachments.

I’d also recommend taking a look at the Getting Started with ZOS-API tutorial. This is a collection of articles that will walk you through a broader introduction to the API. 

I’m sure you’ll find that as you get into the API, you’ll start using it more and more. It’s really powerful for extending the capabilities of OpticStudio, and we highly recommend that everyone builds some familiarity with it. We can, of course, also help coach you up on it through the community, private support inquiries, and formal training. Let me know if you have any questions here, and we can discuss more, as appropriate. 

Cheers,

Nick

Thanks for your answer Nicholas, at least we can take action to mitigate the consequences of the new format. I find this to be a pity though. This means we will need to be processing the lenses on a machine which has Zemax before using it elsewhere, which adds complexity. It was very useful to not depend on Zemax to know what the lens inside the file was… Please consider this in the future.

Best regards,

Raphael