[SLS-DC] 123.0-B-3 Red Book v4 uploaded

[Miguel Hernández Cabronero]

Dear Working Group,

Thank you Aaron for the updated draft. I agree the document is at a point where developing implementations can be useful.

Still, there are a couple of corner cases that might need to be addressed before the ROI part can be fully implemented. I just uploaded a brief report to the CWE that identifies those, it is available at  https://cwe.ccsds.org/sls/docs/SLS-MHDC/CWE Private/123.0-B-3/20241201_report_notes_on_fall2024_red_book.pdf .

Should you have any comments or questions, please don't hesitate to contact me.

Best regards,

Miguel Hernández-Cabronero
https://deic.uab.cat/~mhernandez
Universitat Autònoma de Barcelona (UAB)
________________________________
From: SLS-DC <sls-dc-bounces at mailman.ccsds.org> on behalf of Kiely, Aaron B (US 332B) via SLS-DC <sls-dc at mailman.ccsds.org>
Sent: 12 December 2024 22:01
To: Wong, Englin (GSFC-5670) via SLS-DC <sls-dc at mailman.ccsds.org>
Subject: [SLS-DC] 123.0-B-3 Red Book v4 uploaded

Dear Working Group,

I have uploaded to the CWE a revised draft of CCSDS-123.0-B Issue 3 Red Book: SLS-MHDC / CWE Private / 123.0-B-3 /  123x0b3_red_v4_2024Dec.

The biggest change is to create a new section 3.6 that defines a classification map, granularity, and the term "class definition table". This new section includes much of the stuff that used to be in 4.8.2.5 and 5.3.3.4.8.2.

I looked at the proposed header change. The proposal was to remove the bit in Table 5-3 that indicates whether ROI compression is used, and instead re-design the Error Limit Update Period block structure (Table 5-9, section 5.3.3.4.2) to indicate whether ROI compression is used, and if used, encode the number of classes Nc (but using only 4 bits, thus limiting Nc to 16).

I'm in favor of not making this change:

  *
Using (or not using) ROI is a pretty basic piece of information about the compressed image, and I think using a bit in the Essential Subpart header to indicate this is a more natural approach.
  *
The current approach makes it more straightforward to use up to 256 classes.
  *
Not changing the Error Limit Update Period block section (and the name of this block to reflect that it would be serving an additional purpose) makes it less confusing for implementers already familiar with Issue 2.

I think that the ROI compression procedure is sufficiently firm that producing software implementations for cross-verification would be time well spent.

Some remaining issues that could affect an implementation:

  *
We don't yet have a decision on varying sample damping parameter as a function of y (section 4.9.1). JPL will work on collecting some data and making a recommendation.
  *
We could consider allowing a classification map to be encoded after the image body. (I.e., a compressed image could have a header, body, and trailer.) An implementer could store the map in a buffer and send it (perhaps compressed) at the end of the image, facilitating compression in a single pass. (5.2.1)
  *
We could incorporate the Xie & Klimesh method of compressing classification maps.
  *
JPL would like to propose a "diagonal" scan order that facilitates high-speed hardware implementation without affecting compression performance (at least for sample-adaptive and hybrid entropy coders). I expect we'll have draft text for this before the next meeting.

Regards,
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-dc/attachments/20241216/31b79b39/attachment.htm>