A big +1 on this.  I’d rather default to *.zmx format and only use *.zos when working with proprietary files.  I’m sticking with 21.2.2 until this can happen.

+1 from me also, not everyone has switched yet.

Is there anywhere (knowledge base article, forum thread) an explanation of the reasons to move away from a human readable format ? The release notes just “This provides better file security when stored on disk, for archiving purposes, and when sharing files” but don’t explain how/why.

+1 from me as well.

I’ve already run into a situation where a colleague created a file without realizing the change in file format had even been implemented. The file then could not be opened by a customer. It took a large number of emails before the problem was solved. Lots of time wasted.

+1 for me.  Please allow the user to decide which default format to use.  I’ve been a Zemax customer for over 25 years, and never once had a problem with the .zmx format being “insecure,” which seems to be the primary justification for introducing the .zos format.  There are plenty of ways to secure a .zmx file if needed.  

OK, I’ll say it right out.  The new file format seems to be a deliberate means of forcing us to stay pregnant, by having to renew subscription licenses or never reading our files created after 21.2.2 again.  I’m staying with my permanent license, hardware key and 21.2.2.  Code V and FRED are always alternatives if Zemax doesn’t re-implement *.zmx files again.

I was just pushing back against the stated rationale for the change, but I agree it’s a fairly blatant move to undercut the utility of existing perpetual licenses.  Zemax (the company) of old is long gone…

Thank you to everyone who offered their feedback about the new ZOS file format and the challenges that you experienced in trying to collaborate with colleagues and make the most of your OpticStudio software.

We’re happy to share that our acquisition by Ansys prompted a re-evaluation of the OpticStudio product roadmap, and in OpticStudio 22.2, the ZOS and ZMX file saving options have been equalized! This means that each software user will be able to set your own default file type and that both file types will be capable of saving all aspects of your system. More details are available in the Release Notes.  

That’s good news Alissa, thanks. Will there ever be a point to the .ZOS format? Some purpose that helps users create better optical designs faster?

Great question Mark!  I would love to start seeing some “meta-data” added to the ZOS so we don’t have to open an optical design and load it into OpticStudio just to get some basic information.  Saving the first-order paraxial values as meta-data so you can more quickly query past designs would be a really cool feature.  Also pulling the COATING or GLASSCAT values directly into the ZOS would be great so you won’t overwrite other coating or material values (Zemax is attempting to solve this with Project Directories, but having the material information directly in the design file like CodeV’s private glass catalog would be really useful).

I agree on the metadata, and this can be implemented in the text version too (to better effect, as you could just query it directly). AFAIK, the ZOS structure is not documented so you wouldn’t be able to access the metadata without opening the file, which kinda defeats the purpose.

I was hoping that files saved in binary format would open quicker, but that doesn’t seem to be the case.

I suspect that if the ZOS format died, no users would turn up to the funeral 

• Mark

Good point Mark.  And I guess for non-optical metadata (spec sheets, external Excel files, etc), the Project Directory could be utilized.  I know CodeV has both a binary LEN file and a text based SEQ file.  I wonder if the ZOS file was implemented simply because CodeV has both.  

But I agree that without any significant benefit of the ZOS format that cannot also be implemented in the ZMX format, no one would care if the ZOS format disappeared.

You know, that just gave me an idea. Imagine an XML formatted text file that gave all the data for the file in a structured, easy to parse text format. It could also have a <meta> data section that writes out all the system data from the Prescription report (f/numbers, etc).

Then also imagine a button on all the Layout plots that saves a layout plot with a name like {filename}-thumbnail.png. 

Then, you could have an updated File Open dialog that shows the filename, the thumbnail, the lens title&notes and the meta data. That would be genuinely useful, and save users a lot of time in finding the file they want. In addition, Pythonistas, ZOS-API users and other programmers would find it much easier to program against.

Also, it would give users a genuine reason to upgrade, rather than a genuine reason to not upgrade. Everyone wins!

• Mark

Can I upvote more than once?  Also, Pythonistas?  I like this new term 

THANK YOU MARK for backing all of us up on this!  The *.zos format is (and I hope “was” soon) the New Coke of Zemax:

https://www.coca-colacompany.com/company/history/the-story-of-one-of-the-most-memorable-marketing-blunders-ever

Interesting ideas guys, thanks for sharing.