All Activity

This stream auto-updates     

  1. Last week
  2. Lens Description Standard 2.2

    The poll has been closed. The new version was approved.
  3. Earlier
  4. Lens Blank Groups

    We should also consider the various new "blue" technologies that is coming out and the impact that it's is having on product setups for various systems. Having a standard could help all upstream and downstream technologies.
  5. What is the future for IT infrastructure at TVC

    Has there been any further discussion regarding this point? I like the idea of having TVC use its neutrality to speed up processes and innovation for the industry as a whole.
  6. Lens Description Standard 2.2

    Nicely done and I like the new format. It is definitely easier to find the new additions/changes.
  7. Lens Description Standard 2.2

    I too like the new formatting. I also like the "callout by highlighting", this allows much quicker review.
  8. Lens Description Standard 2.2

    The section describing changes from prior versions is much clearer now. Should the Data Type for field 8 on page 10 now read "3-4 characters" since the new HEV literal is 3 characters?
  9. Lens Description Standard 2.2

    I like the new formatting of the changes from version to version and agree with the current changes proposed.
  10. Lens Description Standard 2.2

    Attached to this post please find version 2.2 of the Lens Description Standard. After review, please vote accordingly and be sure to post any comments below. From Mike Vitale: The only changes that have been made are listed below. I have highlighted the changes made on page 3. 10 and 27 of the document. Category Literal Abbreviation Filter High Energy Visible HEV Color Violet VIOn In addition I revised the revision paragraph (1.3) to more clearly identify changes in each version since 2.0. This mirrors what we've started doing with the Data Communications Standard. THE DOCUMENT IS LINKED BELOW TVC Lens Description Standard 2.2 Draft_pw.pdf
  11. This is a recording of our web meeting from 12/7/17. https://drive.google.com/open?id=1O2Zj7-b4RhEIEVa6cJF-9tY9XhBj60mi Conclusion: We will build the outline based on the combined UML diagram provided by CZV and edited by Essilor. I will update the document on Google Drive with the appropriate changes and the group will reconvene after the holidays.
  12. Lens Blank Groups

    Steve, I agree with with you. if we can get an agreement on blank group category it will be great. Typically I have seen what you describe: Material Index / SF vs SL / Surface Coating Attributes (No Coat/ HC / AR) / Phototropic characteristic (clear/photo-trans/polarized) / color....One thing to consider will be some of the tint/sun color also....I believe some of the existing tables on different LMS can be a good start.....
  13. Lens Blank Groups

    What was throwing me on the blank families discussion was that I had planned a similarly named element, but for a different purpose. The blank group I'd envisioned would hold the elements common to a collection of blanks, such as the material, class (semifinished/finished), and possibly other features like Intrinsic Treatments. But, I do understand the goal of this other blank group now. Maybe it would be good to have both? A shared-characteristic grouping, as well as a product-availability grouping?
  14. DCS data tag for Segment radius on Multifocal curve top lenses

    Well - we can't describe a Panoptic seg either, or any number of features of various kinds of segments (radius of an Ultex?) .
  15. Hi Everyone, The minutes of the most recent working group have been uploaded to Google Drive: https://drive.google.com/open?id=105q6TCC4kglChPrCbOTwpSgjLj9ecFG2 Special thanks to Sebastien Piraube for putting these together. Thanks-P P.S. If you guys would prefer documents like this be uploaded as attachments on the forum instead of put on Google Drive please let me know. I have no preference.
  16. until
    Dear Colleagues, This is the date the majority said was acceptable. I realize some of you indicated you could not attend on this day but I’ve included you just in case. Additional information will be forthcoming. NOTE: Please be sure you have registered for the forums. The majority of information will be shared via the forums. Daniel Simonetta has recently posted some items from our meeting at VEW 2017. Best Regards, Paul Meeting Details LPDS Working Group Tue, Oct 31, 2017 8:00 AM - 9:00 AM PDT Please join my meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/356811141 You can also dial in using your phone. United States: +1 (646) 749-3131 Access Code: 356-811-141 First GoToMeeting? Let's do a quick system check: https://link.gotomeeting.com/system-check
  17. DCS Document Review - 3.12 Major Revamp

    Hi Yaron, Your feedback regarding the revision history section is noted and the section with appropriate annotations will be added to the document prior to the next round of review. The current round of review, intended to identify inadvertent errors that may have been introduced during the reformatting process, is approximately 0% complete.
  18. DCS Document Review - 3.12 Major Revamp

    Paul, I fully agree that there shouldn't be a detailed list of all these changes. That's not only impractical but also not useful to any reader. (And as a side note, wow, that seems like a lot of hard frustrating work, so kudos for taking this on) But there still should be a new section in the revision history for the version, even if only with a few generic items like "Various formatting corrections", "Corrections of multiple typos", "Multiple paragraph numbering corrections", "Various phrasing changes for increased clarity" and such. Because a large purpose of the revision history section is to show what changed, and these things did change. So it should be there to answer the "What happened between 3.11 and 3.12" question, even if it can't/shouldn't provide existing details. The mere information that all changes were such minor ones is still important to a reader if someone tries to check the document, over not seeing anything so not knowing if there is a need to invest time checking everything manually.
  19. DCS Document Review - 3.12 Major Revamp

    Hi Yaron, Yes, there are literally thousands of changes (over 7,000) and the vast majority (6,000 or so) are simply formatting. No content changes were intended other than corrections to existing issues (paragraph numbering corrections, typos, etc.). There may have been a couple of very small changes that inadvertently have been added already but once we finish this review will get listed in the revision area like normal. There will not be a list of these formatting changes or corrections since it's simply not practical. Once we have a good document for editing again we will proceed with actual content changes as normal. This was the decision of the group at VEW. It is also not possible to provide a Word document comparison review just in case that is the next question. Word cannot properly handle the number of changes and it can be very confusing trying to go through a compare when there are a lot of paragraph numbering changes as there are in this revision. I did that prior to turning this document over to the group to try and identify and correct the most egregious of mistakes. Let me know if you have any other questions or concerns regarding this process. It's definitely fluid at the moment since we've never attempted a review of this scale before.
  20. DCS Document Review - 3.12 Major Revamp

    Paul, The Revision History section seems to not have been changed since 3.11, despite some changes that (of course) did occur in the rest of the document. I expect that this would make it harder for people to find the rest of the changes to review.
  21. Handling of CRIBFMT and CRIB/ELLH

    CRIBFMT is essentially a more accurate / higher-resolution presentation for the same data from CRIB/ELLH. As such the basic expectations should be, I think, as in all such cases: CRIBFMT takes precedence if it exists. CRIB/ELLH, if existing together with CRIBFMT, should still be as correct/accurate as possible, for machines that can handle them and don't handle CRIBFMT. In this case I think meaning that the CRIBFMT shape is contained inside the circle/ellipse defined by CRIB/ELLH (I'm assuming here that in general case for things that handle it more roughly it would be better to consider more of the lens as "important" rather than less, since the worse thing would be to remove/damage area that should be inside the crib). That seems the natural way to handle all such differing presentations of the same data, regardless of specifics. Higher resolution takes precedence if both available and known/supported, lower resolution should still be accurate and err on the side of less severe consequences (when relevant). ( As an aside, I'm also not seeing how a device would have problem with both being present. At least not in cases when connecting to a VCA Host, rather than reading a file, after Initialization. CRIBFMT is only sent if explicitly asked for, and usually also CRIB/ELLH. If a device asks for both during initialization then it should be able to handle both. This means that you shouldn't have to suppress CRIB/ELLH because if a device didn't explicitly ask for them then you probably shouldn't send them anyway. But it also means it should be usually very safe to suppress then, since if a device asked for CRIBFMT then it should be able to handle it and would probably prefer it anyway. ) It would be a good idea to slightly modify the standard to explicitly state the priorities/relationship if an ambiguity is possible. Obviously I think based on the same ideas. But in any case it shouldn't be a restriction on both being present, that would be unlike anything else (AFAIK) in the DCS, and the DCS does have other cases of different resolution/accuracy presentations of the same data. From a *correctness* aspect it should always be possible to send *everything*, and so even more so when it's everything that a device explicitly asked for.
  22. VEW 2017 MES Presentation

    I've attached a copy of the presentations from Dennis Brandl given at VEW 2017. 2017-09-12 Two Hour ISA 95 Tutorial.pptx Dennis Brandl - OPC-UA and Deep Domain Knowledge.pptx
  23. What is the future for IT infrastructure at TVC

    Yes, they hired an I.T. director several months ago. https://www.thevisioncouncil.org/canan-abayhan
  24. What is the future for IT infrastructure at TVC

    Michael, Has there been any progress by the TVC in hiring the IT Manager? I may have missed the press release.
  25. LPDS Lens Catalogue

    Here is the submission from Christophe Lafay and his team. Posted with his approval. ProductDefinitionDraft.xml
  26. LPDS Lens Catalogue

    Hello Marcos and group, I am attaching the materials provided by Zeiss which we referenced during the VEW 2017 meeting. I want to acquire permission before I post the Essilor materials. Base selection charts Document.pdf BaseCharts Presentation.pdf LPDS Catalogue Working Draft Submission for input. Sep 12, 2017pdf.pdf
  27. LPDS Lens Catalogue

    I was wondering if after our last DCS meeting in Las Vegas in Sept 2017 we would have the Essilor and Zeiss proposals for LDPS lens catalogue available here in the forums so we can start the discussion from there.
  1. Load more activity