New release 21.3

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

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 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 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

@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.  

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

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

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 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

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