From eaa73732cf8a8a7b64354f7a8f2b81b814e644e0 Mon Sep 17 00:00:00 2001 From: Dmitry Pentin Date: Sun, 21 Nov 2021 09:10:44 +0300 Subject: [PATCH] Comments --- src/ImageSharp/Formats/Jpeg/Components/ZigZag.cs | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/ImageSharp/Formats/Jpeg/Components/ZigZag.cs b/src/ImageSharp/Formats/Jpeg/Components/ZigZag.cs index f52cb6c105..ab80b3ae67 100644 --- a/src/ImageSharp/Formats/Jpeg/Components/ZigZag.cs +++ b/src/ImageSharp/Formats/Jpeg/Components/ZigZag.cs @@ -36,6 +36,19 @@ namespace SixLabors.ImageSharp.Formats.Jpeg.Components 63, 63, 63, 63, 63, 63, 63, 63 }; + /// + /// Gets span of zig-zag with fused transpose step ordering indices. + /// + /// + /// When reading corrupted data, the Huffman decoders could attempt + /// to reference an entry beyond the end of this array (if the decoded + /// zero run length reaches past the end of the block). To prevent + /// wild stores without adding an inner-loop test, we put some extra + /// "63"s after the real entries. This will cause the extra coefficient + /// to be stored in location 63 of the block, not somewhere random. + /// The worst case would be a run-length of 15, which means we need 16 + /// fake entries. + /// public static ReadOnlySpan TransposingOrder => new byte[] { 0, 8, 1, 2, 9, 16, 24, 17,