[Sls-mhdc] Final Steps for CCSDS-123.0-B-2 White Book

Fri Mar 23 08:58:00 UTC 2018

Dear all,

CNES approves submitting the CCSDS-123.0-B-2 White Book to CCSDS management and requesting agency review.

Best regards,

Roberto

De : SLS-MHDC [mailto:sls-mhdc-bounces at mailman.ccsds.org] De la part de Raffaele.Vitulli at esa.int
Envoyé : vendredi 23 mars 2018 08:47
À : Kiely, Aaron B (332B) <aaron.b.kiely at jpl.nasa.gov>
Cc : sls-mhdc at mailman.ccsds.org
Objet : Re: [Sls-mhdc] Final Steps for CCSDS-123.0-B-2 White Book

Dear Working Group,

ESA approves submitting the White Book to CCSDS management and requesting agency review.

R. Vitulli

[Inactive hide details for "Kiely, Aaron B (332B)" ---20/03/2018 16:28:05---Dear Working Group, Thank you for your edits to the]"Kiely, Aaron B (332B)" ---20/03/2018 16:28:05---Dear Working Group, Thank you for your edits to the White Book for CCSDS-123.0-B-2.

From: "Kiely, Aaron B (332B)" <aaron.b.kiely at jpl.nasa.gov<mailto:aaron.b.kiely at jpl.nasa.gov>>
To: "sls-mhdc at mailman.ccsds.org<mailto:sls-mhdc at mailman.ccsds.org>" <sls-mhdc at mailman.ccsds.org<mailto:sls-mhdc at mailman.ccsds.org>>
Date: 20/03/2018 16:28
Subject: [Sls-mhdc] Final Steps for CCSDS-123.0-B-2 White Book
Sent by: "SLS-MHDC" <sls-mhdc-bounces at mailman.ccsds.org<mailto:sls-mhdc-bounces at mailman.ccsds.org>>

________________________________

Dear Working Group,

Thank you for your edits to the White Book for CCSDS-123.0-B-2.

I have uploaded to the CWE a revised draft addressing the comments received:
CWE Private / 123.1-B / WhiteBook / 123x0w2-2108.03.19.{doc, pdf}

Track changes are used to help you spot revisions since the last draft. Unfortunately, all cross-references appear as though they have been changed even though almost none of them have.

Important next steps:

(1) ***** For everyone representing a CCSDS member agency ***** please send me an email to confirm that you approve submitting the White Book to CCSDS management and requesting agency review. (Note that we can still make revisions — in fact, any working group member can request a revision as part of the agency review process — so please don’t withhold your approval over a minor issue.)

(2) Please check to see if I have satisfactorily addressed your remarks (I think I covered everything except for a few remarks that I’ve addressed below, but it’s possible I missed something). Let me know if you have suggestions for further refinements.

(3) Please note the following tentative changes and let me know your opinion:

- The Working Group has reached consensus that periodic error limit updating will not be used under BSQ encoding order. But when band-dependent error limits are used with BSQ encoding, there is not universal agreement on whether error limit values will be encoded (a) with each band or (b) in the header. The current draft assumes (b), but this is subject to change pending further discussion.

- The general practice in the White Book has been to omit pieces of the header in cases where we know that they’ll convey no information. Following this practice, I have eliminated the Error Limit Update Period block when BSQ encoding is used. This change is a nuisance for those of us who have produced an implementation, but hopefully a minor one.

- We had defined an optional 2D supplementary information table to span the X-Z plane. Roberto suggests that we also allow an X-Y table. This seems reasonable, and it’s not hard to add, so I’ve revised the White Book to define both types of 2D tables. If you have objections, let me know, it’s easy to revert to the previous version.

Finally, there are a few remarks that I did not address in this revision. Here’s a list of those remarks and my rationale:

- Section 2.3 “Would it be possible to also have a similar table specifying which sections contain the “extra” material needed to upgrade 123.0 to the new standard?”  — I think this is covered by the first column of Table 2-1. Perhaps I’m not understanding this comment.

- Section 4.1 “If I recall it well, we reached consensus about imposing (or at least advising) reduced mode with “narrow”. I think this is important for implementors, so shouldn’t we say it more clearly (here or somewhere else)?” — I’m not sure that we have the experimental data to make a strong recommendation that narrow + full mode is bad. I’m reluctant to suggest that this combination is a bad idea without more confidence. This might be something we save for the Green Book.

- Section 4.7.3 (equation 37) “Should we add here a note saying that this formulation is equal to that of equation (29) in [C2]?” I’m reluctant to start going into details about how the new equations replace the old ones (there are a lot of places where we might do this).

- Section 5.1: (on sample encoding order having “virtually” no impact on compressed image size under the hybrid coder) “This is a bit vague… For the sample adaptive encoder it is written that the coding order does not affect coding efficiency, which is very clear. The explanation for the block-adaptive encoder is also rather detailed.” This is a valid point. Unfortunately, I can’t see how to make this less vague without going into a lot more detail than is really appropriate for this overview subsection. I suggest that we cover this in the Green Book.

Regards,
Aaron
_______________________________________________
SLS-MHDC mailing list
SLS-MHDC at mailman.ccsds.org<mailto:SLS-MHDC at mailman.ccsds.org>
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-mhdc

This message and any attachments are intended for the use of the addressee or addressees only.

The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its

content is not permitted.

If you received this message in error, please notify the sender and delete it from your system.

Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-mhdc/attachments/20180323/4116f82e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
URL: <http://mailman.ccsds.org/pipermail/sls-mhdc/attachments/20180323/4116f82e/attachment.gif>