Results 1 to 3 of 3

Thread: CIRC3D in DCS

  1. #1
    OptiBoard Novice
    Join Date
    Apr 2017
    Location
    Italy
    Occupation
    Frame Manufacturer
    Posts
    2

    CIRC3D in DCS

    Very obscure and technical question - Does anyone have any insight into paragraph 5.4.9.4. and 5.4.9.5. of the Vision Council's Data Communication Standards?

    "5.4.9.4 In the particular case where BSIZ and CSIZ are absent or unknown and a single side tracing and two CIRC orCIRC3D values which differ are received, the CIRC or CIRC3D for the eye sent should reflect the shape. CSIZ isimplied to be the difference between the two circumferences and the shape for the eye not sent shall be modifiedaccording to the implied CSIZ.

    5.4.9.5 When CIRC3D is present, either z-data, or a FCRV value, shall be included. If z-data is included, the value ofCIRC3D shall be calculated using the z-data; if only FCRV is included, the value of CIRC3D shall be calculated basedon the FCRV value."

    It explains the requirements for a "CIRC3D" tag in an .oma shape file but does not go into detail as to the function of the tag. I understand the basic concept of a 3D vs. 2D shape, but it is not clear to me how data should flow from Tracer to Edger using that tag and the frame curve/Z data.

    Any help at all would be greatly appreciated!

  2. #2
    Objection! OptiBoard Gold Supporter shanbaum's Avatar
    Join Date
    May 2000
    Location
    Manchester, CT USA
    Occupation
    Other Optical Manufacturer or Vendor
    Posts
    2,977
    Quote Originally Posted by ccraddoc View Post
    Very obscure and technical question - Does anyone have any insight into paragraph 5.4.9.4. and 5.4.9.5. of the Vision Council's Data Communication Standards?

    "5.4.9.4 In the particular case where BSIZ and CSIZ are absent or unknown and a single side tracing and two CIRC orCIRC3D values which differ are received, the CIRC or CIRC3D for the eye sent should reflect the shape. CSIZ isimplied to be the difference between the two circumferences and the shape for the eye not sent shall be modifiedaccording to the implied CSIZ.

    5.4.9.5 When CIRC3D is present, either z-data, or a FCRV value, shall be included. If z-data is included, the value ofCIRC3D shall be calculated using the z-data; if only FCRV is included, the value of CIRC3D shall be calculated basedon the FCRV value."

    It explains the requirements for a "CIRC3D" tag in an .oma shape file but does not go into detail as to the function of the tag. I understand the basic concept of a 3D vs. 2D shape, but it is not clear to me how data should flow from Tracer to Edger using that tag and the frame curve/Z data.

    Any help at all would be greatly appreciated!
    Your first question appears to be about the use of an implied circumference difference between two sides of a tracer's packet when one side is sent together with two circumference values. Note that this refers only to the scenario in which only one side of trace data is sent, but it's implied that both sides were measured (otherwise, the tracer wouldn't know two distinct circumference values). The protocol allows for one or two sides' data to be conveyed. It was anticipated that in some cases, tracers would afford the option of sending one shape, but two sizes. The more normal case is that tracers trace both sides and send the two sides unmodified. Some users prefer for the shapes for the two sides to more closely mirror each other, and yet allow for (presumably small) size variation between the two sides. Obviously, a bit of reshaping - hopefully, a very small bit - is implicated at the mounting stage. Tracers may do this modification of the raw data; some software systems definitely do it after-the-fact. The point of 5.4.9.4 is to provide a concise way for a tracer to indicate that the two sides should differ in size but not shape, and an indication to edger manufacturers that they should respect this convention, and in effect construct a CSIZ value for the eye-not-sent from the two CIRC or CIRC3D values.

    5.4.9.5 requires that when a CIRC3D value is sent, it's necessary to send either a frame curve value, or "z-data" (the plate height of the shape above the tracer table), so that a recipient of the data can make sense of it - one can't know the significance of a "bent" shape without knowing the degree to which the shape is "bent." "Z-data" is better, in that it's higher-resolution information, but FCRV can get you close.

    Note that there can be some ambiguity about the state of a tracing, which ambiguity can be eliminated by the use of the TNORM record. TNORM affords the tracer a way of indicating whether the radius data supplied is "raw" (the data actually measured) or "normalized" (where the effect of tilt and/or curve has been removed). I haven't seen a tracer manufacturer use this record. So far as I know, all of them send normalized data presently; years ago, there used to be one notable exception (Nidek).

  3. #3
    OptiBoard Novice
    Join Date
    Apr 2017
    Location
    Italy
    Occupation
    Frame Manufacturer
    Posts
    2
    Sorry I'm late to reply, but thank you so much for this information- it was exactly what I was looking for!

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
OptiBoard is proudly sponsored by:
Younger Optics and Vision Equipment