<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Dear Working Group,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thank you Aaron for the updated draft. I agree the document is at a point where developing implementations can be useful.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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
.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Should you have any comments or questions, please don't hesitate to contact me.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Best regards,</div>
<div style="color: inherit;" id="Signature">
<div style="background-color: rgb(255, 255, 255); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="background-color: rgb(255, 255, 255); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 137, 63);">
<b>Miguel Hernández-Cabronero</b></div>
<div style="background-color: rgb(255, 255, 255); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<a href="https://deic.uab.cat/~mhernandez" id="OWA3d15f77a-3fea-45c8-8d54-e80b030a9e58" class="OWAAutoLink" title="https://deic.uab.cat/~mhernandez">https://deic.uab.cat/~mhernandez</a></div>
<div style="background-color: rgb(255, 255, 255); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Universitat Autònoma de Barcelona (UAB)</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> SLS-DC <sls-dc-bounces@mailman.ccsds.org> on behalf of Kiely, Aaron B (US 332B) via SLS-DC <sls-dc@mailman.ccsds.org><br>
<b>Sent:</b> 12 December 2024 22:01<br>
<b>To:</b> Wong, Englin (GSFC-5670) via SLS-DC <sls-dc@mailman.ccsds.org><br>
<b>Subject:</b> [SLS-DC] 123.0-B-3 Red Book v4 uploaded</font>
<div> </div>
</div>
<style type="text/css" style="display:none">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
Dear Working Group,</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
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.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
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.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
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).</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
I'm in favor of not making this change:</div>
<ul data-editing-info="{"applyListStyleFromLevel":true}" style="list-style-type:disc">
<li style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<div>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.</div>
</li><li style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<div>The current approach makes it more straightforward to use up to 256 classes.</div>
</li><li style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<div>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.</div>
</li></ul>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
I think that the ROI compression procedure is sufficiently firm that producing software implementations for cross-verification would be time well spent.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
Some remaining issues that could affect an implementation:</div>
<ul data-editing-info="{"applyListStyleFromLevel":true}" style="list-style-type:disc">
<li style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<div>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.</div>
</li><li style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<div>We could consider allowing a classification map to be encoded <i>after </i>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)</div>
</li><li style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<div>We could incorporate the Xie & Klimesh method of compressing classification maps.</div>
</li><li style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<div>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.</div>
</li></ul>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
Regards,</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
Aaron</div>
</div>
</body>
</html>