Invalid test files using CleanApertureBox (clap) transformation

[baumanj]

All 5 of the files under https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles which use the CleanApertureBox (clap) are invalid.

Per ISOBMFF (ISO 14496-12:2020) § 12.1.4.1

Considering the pixel dimensions as defined by the VisualSampleEntr width and height. If picture centre of the image is at pcXandpcY, then horizOffandvertOff` are defined as follows:

pcX = horizOff + (width  - 1)/2
pcY = vertOff  + (height - 1)/2;

Typically, horizOff and vertOff are zero, so the image is centre
about the picture centre. The leftmost/rightmost pixel and the
topmost/bottommost line of the clean aperture fall at:

pcX ± (cleanApertureWidth - 1)/2
pcY ± (cleanApertureHeight - 1)/2;

Applying these formuæ show that the lines of the clean aperture do not fall on integer pixels. Take
testFiles/Microsoft/Chimera_10bit_cropped_to_1920x1008.avif. Loading this file in MP4Box.js shows the relevant inputs: ImageSpatialExtents (ispe) and CleanApertureBox (clap) under meta::iprp::ipco:

ispe

• image_width | 1920
• image_height | 1080

clap

• cleanApertureWidthN | 1920
• cleanApertureWidthD | 1
• cleanApertureHeightN | 1008
• cleanApertureHeightD | 1
• horizOffN | 1
• horizOffD | 2
• vertOffN | 1
• vertOffD | 2

Calculating the vertical clean aperture lines:

pcX = horizOff + (width  - 1)/2
    = ( 1/2  ) + (1920   - 1)/2
    = ( 1/2  ) + (1919      )/2
    = 1920/2
    = 960

pcX ± (cleanApertureWidth - 1)/2
960 ± (1920               - 1)/2
960 ± 1919/2
960 ± 959.5
(1919.5, 0.5)

A quick test is that if the length of the image dimension and the crop dimension have the same parity, the offset in that dimension must be a while number. If they have opposite parity, the offset must be a half pixel value. The above example fails because 1920 and 1920 are both even, but 1/2 is not a whole number.

There are similar issues with the rest of these files as well:

• testFiles/Microsoft/Chimera_10bit_cropped_to_1920x1008_with_HDR_metada: Same as above
• testFiles/Microsoft/Chimera_8bit_cropped_480x256.avif: 480 and 480 both even, but 1/2 is not a whole number
• testFiles/Link-U/kimono.crop.avif: 722 and 385 have different parity, but 103/1 is a whole number
• testFiles/Link-U/kimono.mirror-vertical.rotate270.crop.avif: same as above

[leo-barnes]

This should now be fixed.