[Sls-mhdc] Proposed modification to White Book for CCSDS-123.0-B-2

[Kiely, Aaron B (332B)]

Dear Working Group,

Now that we have worked through some cross-verification tests, I’d like to propose a technical change to the White Book.

Specifically, after discussions with Ian and Matt Klimesh, I propose that we prohibit the use of periodic error limit updating when BSQ encoding order is used.

It’s clumsy to implement, it somewhat complicates the text in the standard, and it’s not easy to come up with plausible examples where a user would really need both BSQ encoding order and periodic updating. (Push-broom imaging applications will want BIL or BIP encoding anyway. For frame-based imaging, changing fidelity settings in the middle of a frame seems unlikely unless a user is going to buffer the whole image anyway, in which case BIL or BIP would probably be acceptable.)

Under this proposed simplification, when periodic error limit updating is not used, the error limit would appear in the header, regardless of encoding order.

If the WG does reach consensus to eliminate periodic updating under BSQ encoding, a remaining question is: when band-independent error limits are used under BSQ encoding, where should the error limit values occur in the bitstream?
(a) Each band error limit precedes the band (as it is now), or
(b) The vector of error limits appears the header (as it is for BI encoding order).

Option (b) is simpler, and this would be my preference. The drawback is that if you want to select the fidelity for band N based on what you’ve seen through the first N-1 bands then you would have to buffer the whole image. But it’s not clear that anyone would need this capability (frame-based imagers tend to produce lower data volumes and as we learned at the last OBPDC, RAM is practically free), so we would be complicating things for the sake of supporting something that no one might ever use.

Please let me know your opinion, and if you prefer the more complicated option, I hope you’ll describe the use case that motivates the added complexity.

Regards,
Aaron



> On Feb 28, 2018, at 1:52 PM, Kiely, Aaron B (332B) <aaron.b.kiely at jpl.nasa.gov> wrote:
> 
> Dear Working Group,
> 
> I have uploaded to the CWE a revised draft of the White Book for CCSDS-123.0-B-2:
> 	CWE Private / 123.1-B / WhiteBook / 123x0w2-2018.02.28.{pdf, doc}
> 
> I have used “notes” to call attention to all of the changes since the previous major revision in November, apart from inconsequential small changes in wording, typo fixes, etc.
> 
> I thank Ian, Mark, and new WG member Brenton Sundlie, from University of Dayton Research Institute, for their careful reading of the White Book. They caught some minor issues (that would have affected things like backwards compatibility) that have now been fixed.
> 
> The latest draft also includes new low-entropy component codes and flush tables (Annex F). These tables are also available in ASCII format on the CWE at:
> 	CWE Private / 123.1-B / CodeTableDesign-2018.Jan.zip
> 
> This completes part (a) of action item MHDC-A-1711-4. The next step is (b) final review by the working group and (c) delivery to Area Director and Editor. We had hoped to complete (b) by March 9, and (c) by March 23, so that the document could be submitted in advance of the Spring Meeting (with the idea that we might get into the Editor’s queue ahead of documents that might be delivered at or shortly after the Spring Meeting).
> 
> 
> ** Please let me know if you are able to conduct a final review and deliver your comments to me by March 16 (and if not, please suggest a date that works for you). I’m still hoping to deliver this to the Editor before the meeting.
> 
> 
> I am aware that there are lots of cosmetic issues, most notably with the size and appearance of mathematical symbols and equations. Often when I fix such a problem, Microsoft Word re-creates the problem. I trust that our document editor will spot these issues and can fix them more efficiently, and hopefully more permanently, than I can. (In other words, I don’t plan on fixing them before delivering this document, and I don’t think it’s a good use of your time to try to identify them.)
> 
> Mark, Ian, and I have been doing some cross-verification tests on some initial small test images and I’m happy to report that we’ve been making good progress so far.
> 
> Regards,
> Aaron
>