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!

Quote:

Originally Posted by ccraddoc

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

Sorry I'm late to reply, but thank you so much for this information- it was exactly what I was looking for!