Yaron [LaserOp]

  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Yaron [LaserOp]

  • Rank
  1. 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.
  2. 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.
  3. 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.