all_zero cdf ctx: No need to clamp top and left

[wantehchang]

My colleague Vignesh Venkatasubramanian suggested this change.

In the procedure for computing the 'ctx' variable for the all_zero cdf, the following two lines can be omitted:

    top = Min( top, 255 )
    left = Min( left, 255 )

'top' and 'left' are the maximum of AboveLevelContext[ plane ][ x4 + k ] and LeftLevelContext[ plane ][ y4 + k ], respectively. The value we store in AboveLevelContext and LeftLevelContext are less than or equal to 63, because of the following line in the coeffs( plane, startX, startY, txSz ) function in Section 5.11.39:

    culLevel = Min( 63, culLevel )

[peterderivaz]

Good spot! This looks like a good simplification to me, but I don't know how much the working group want to modify the specification at this point.

I suggest you ask Adrian Grange if he wants it to be merged.

[imoccaga]

I do not see anything broken.
If my understanding is correct, it seems this is a low level change that is not needed.

[alexismt73]

@imoccaga actually this, at first look, seems purely an editorial change and as the proponents suggest the values are already bounded by the process in 5.11.39. Can you clarify why we need to retain the two clipping operations that do nothing? It might actually be helpful if you could check your own implementations to see what is done there, but we should also note that we should be friendly to implementers and not to confuse them with not necessary steps. Unfortunately not all implementers may see that this is not necessary and especially for SW decoders this could add a penalty for no reason.

Btw, simplifications like these, assuming that indeed there is nowhere else that AboveLevelContext[] and LeftLevelContext[] are set that could be above 255, are commonly included in other specs if they help implementers. I do not see why we need to be more strict. What is also important is ensuring that the process results in identical output under all conditions.

Note that our spec does not say that a decoder needs to implement any steps exactly as specified in the specification. Conformance is based on the output, not on the operations. For reference, this is text from other specifications where the same is expected:

"Any decoding process that produces identical cropped decoded output pictures to those produced by the process described herein (with the correct output order or output timing, as specified) conforms to the decoding process requirements of this Specification."

[imoccaga]

As I said before, there is nothing broken in the current spec, and this is a low level change, so risky by nature.
We should be able to convey this using a note.