JVET-AL0067 AHG9: On the OMI SEI [J. Boyce, M. M. Hannuksela (Nokia)]

Chaired by S. Deshpande on 27 March 2025 at 16:25

Based on a study of the text of the OMI SEI message, a number of small changes are proposed to improve clarity of the design, summarized as follows.

• Item 1: Require non-zero width and height of bounding boxes:

It was commented that for AR SEI regions width and height could be 0 (e.g. for cursors or something similar). It was commented by proponent that this SEI may not be supporting such use cases. It was commented that cursor example may be a bounding box of size 1 instead of zero-sized bounding box.

Decision: Agreed

It was suggested to add an editorial note to AR SEI for zero-size bounding boxes.

• Item 2: Clarify that bounding box parameters are in units of chroma samples:

It is asserted that the mapping process does not use chroma sample units, but ranges of some syntax are considering chroma samples.

It was asked how the software implements this. It was commented that the original design intent was to do this in luma domain.

Instead of making the proposed change, the range values highlighted in cyan could be modified to do things in luma sample value units.

A non-proponent thought doing this in chroma sample units may be better.

Another participant commented that in multiple places in specification we have text defining things in units of luma sample and putting constraints in other places and so it was preferred to do it that way. This was supported by multiple participants. It was commented that AR SEI seems to use a multiplication by SubWidthC and SubHeightC.

An example text from AR SEI was:

The identified object rectangle contains the luma samples with horizontal picture coordinates from SubWidthC * ( ConfWinLeftOffset  + ar_bounding_box_left[ ar_object_idx[ i ] ] ) to SubWidthC * ( ConfWinLeftOffset  + ar_bounding_box_left[ ar_object_idx[ i ] ] + ar_bounding_box_width[ ar_object_idx[ i ] ] ) − 1, inclusive, and vertical picture coordinates from SubHeightC * ( ConfWinTopOffset + ar_bounding_box_top[ ar_object_idx[ i ] ] ) to SubHeightC * ( ConfWinTopOffset + ar_bounding_box_top[ ar_object_idx[ i ] ] + ar_bounding_box_height[ ar_object_idx[ i ] ] ) − 1, inclusive.

Also VVC cropping window may be doing it similarly.

Virtual boundaries were specified differently for a reason (of being divisible by 8).

Initially there was support to modify the change the cyan highlighted constraints instead to be consistent with using units of luma samples. Additionally add a constraint that relevant bounding box parameters mod width or height is equal to 0.

Subsequent discussion resulted in more support to make this consistent with AR SEI and cropping in VVC.

Decision: Agreed to make the change as proposed, but not to use the words “chroma samples”.

• Item 3: Clarify that the mask mapping process uses luma samples

Decision: Agreed, add word “luma” as proposed.

• Item 4: Require that cropped width and height of the auxiliary pictures be equal to those of the primary picture

About the first proposed constraint: It was asked if the first proposed constraint is too strict. The OMI SEI is associated with primary layer. Multiple auxiliary picture layers correspond to the use case of object overlap. It was agreed instead to add a language to say that the entire OMI SEI should be ignored if any of the auxiliary picture layers that are referred are not present.

About the second proposed constraint: It was asked if the second proposed constraint is too strict. It was asked if it is not sufficient that the mask is smaller the primary picture size. It was agreed to do this by requiring that the mask is within the auxiliary picture size and it can be smaller than primary picture size and exact wording is delegated to the editors.

• Item 5: Allow different luma bit-depths for the primary layer and the object mask auxiliary layers. Change it proposed to VSEI and VVC interface text. It was asked if it is allowed currently to have different bit depths for auxiliary and primary pictures. It was commented that this is only allowed if it is scalably coded. It was commented that currently the VSEI spec text does not explicitly prohibit having different bit depth values. It was suggested to define a higher value range for omi_mask_sample_value_length_minus8 instead in VSEI and to specify it to be less than BitDepthY in VVC interface text.

Discussed items 4 and 5 to review the text in v2 of the document on 1 April 2025 at 17:20.

For item 4: Agreed as per v2 with additionally changing “all values of i” to “any value of i”.

For item 5: In previous discussion constraint for item 5 was considered too strict and was relaxed in v2. Also interface variables related changes were made in v2. Agreed as per v2.