Patent Description:
The present document relates generally to images. More particularly, an embodiment of the present invention relates to video coding using reference picture resampling (RPR) with support for region of interest (ROI).

As used herein, the term 'dynamic range' (DR) may relate to a capability of the human visual system (HVS) to perceive a range of intensity (e.g., luminance, luma) in an image, e.g., from darkest grays (blacks) to brightest whites (highlights). In this sense, DR relates to a 'scene-referred' intensity. DR may also relate to the ability of a display device to adequately or approximately render an intensity range of a particular breadth. In this sense, DR relates to a 'display-referred' intensity. Unless a particular sense is explicitly specified to have particular significance at any point in the description herein, it should be inferred that the term may be used in either sense, e.g. interchangeably.

As used herein, the term high dynamic range (HDR) relates to a DR breadth that spans the <NUM>-<NUM> orders of magnitude of the human visual system (HVS). In practice, the DR over which a human may simultaneously perceive an extensive breadth in intensity range may be somewhat truncated, in relation to HDR.

In practice, images comprise one or more color components (e.g., luma Y and chroma Cb and Cr) wherein each color component is represented by a precision of n-bits per pixel (e.g., n=<NUM>). For example, using non-linear luminance coding (e.g., gamma YCbCr), images where n ≤ <NUM> (e.g., color <NUM>-bit JPEG images) are considered images of standard dynamic range (SDR), while images where n > <NUM> may be considered images of enhanced dynamic range. HDR images may also be stored and distributed using high-precision (e.g., <NUM>-bit) floating-point formats, such as the OpenEXR file format developed by Industrial Light and Magic.

Currently, distribution of video high dynamic range content, such as Dolby Vision from Dolby laboratories or HDR10 in Blue-Ray, is limited to <NUM> resolution (e.g., <NUM> × <NUM> or <NUM> × <NUM>, and the like) and <NUM> frames per second (fps) by the capabilities of many playback devices. In future versions, it is anticipated that content of up to <NUM> resolution (e.g., <NUM> x <NUM>) and <NUM> fps may be available for distribution and playback. It is desirable that future content types will be compatible with existing playback devices in order to simplify an HDR playback content ecosystem, such as Dolby Vision. Ideally, content producers should be able to adopt and distribute future HDR technologies without having to also derive and distribute special versions of the content that are compatible with existing HDR devices (such as HDR10 or Dolby Vision). As appreciated by the inventors here, improved techniques for the single layer and scalable distribution of video content, especially HDR content, are desired.

<NPL>, discloses syntax and semantics to support additional functionality and coding efficicnecy for reference picture resampling in VVC.

An embodiment of the present invention is illustrated by way of example, and not in way by limitation, in the <FIG> of the accompanying drawings the other figures disclosing information useful for understanding the claimed invention and in which like reference numerals refer to similar elements and in which:.

Example embodiments that relate to canvas size resizing for video coding are described herein. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments of present invention. It will be apparent, however, that the various embodiments of the present invention may be practiced without these specific details. In other instances, well-known structures and devices are not described in exhaustive detail, in order to avoid unnecessarily occluding, obscuring, or obfuscating embodiments of the present invention.

Example embodiments described herein relate to canvas size resizing or resampling in video coding. Basis for the claims may be found in the first to fourth variations set out below.

<FIG> depicts an example process of a conventional video delivery pipeline (<NUM>) showing various stages from video capture to video content display. A sequence of video frames (<NUM>) is captured or generated using image generation block (<NUM>). Video frames (<NUM>) may be digitally captured (e.g. by a digital camera) or generated by a computer (e.g. using computer animation) to provide video data (<NUM>). Alternatively, video frames (<NUM>) may be captured on film by a film camera. The film is converted to a digital format to provide video data (<NUM>). In a production phase (<NUM>), video data (<NUM>) is edited to provide a video production stream (<NUM>).

The video data of production stream (<NUM>) is then provided to a processor at block (<NUM>) for post-production editing. Block (<NUM>) post-production editing may include adjusting or modifying colors or brightness in particular areas of an image to enhance the image quality or achieve a particular appearance for the image in accordance with the video creator's creative intent. This is sometimes called "color timing" or "color grading. " Other editing (e.g. scene selection and sequencing, image cropping, addition of computer-generated visual special effects, judder or blur control, frame rate control, etc.) may be performed at block (<NUM>) to yield a final version (<NUM>) of the production for distribution. During post-production editing (<NUM>), video images are viewed on a reference display (<NUM>).

Following post-production (<NUM>), video data of final production (<NUM>) may be delivered to encoding block (<NUM>) for delivering downstream to decoding and playback devices such as television sets, set-top boxes, movie theaters, and the like. In some embodiments, coding block (<NUM>) may include audio and video encoders, such as those defined by ATSC, DVB, DVD, Blu-Ray, and other delivery formats, to generate coded bit stream (<NUM>). In a receiver, the coded bit stream (<NUM>) is decoded by decoding unit (<NUM>) to generate a decoded signal (<NUM>) representing an identical or close approximation of signal (<NUM>). The receiver may be attached to a target display (<NUM>) which may have completely different characteristics than the reference display (<NUM>). In that case, a display management block (<NUM>) may be used to map the dynamic range of decoded signal (<NUM>) to the characteristics of the target display (<NUM>) by generating display-mapped signal (<NUM>).

Scalable coding is already part of a number of video coding standards, such as, MPEG-<NUM>, AVC, and HEVC. In embodiments of this invention, scalable coding is extended to improve performance and flexibility, especially as it relates to very high resolution HDR content.

As known in the art, spatial scalability is used mainly to allow a decoder to create content at various resolutions. In embodiments of this invention spatial or canvas scalability is designed to allow extraction of different regions of the image. For example, a content producer may choose to frame content (that is, specify the viewing region) differently for a large display than for a small display. For example, the framed regions to display may depend on the size of the screen or the distance of the screen to the viewer. Embodiments of this invention allow an image to be split into overlapping regions (typically rectangular) or non-overlapping regions and encode them in such a way that a select number of sub-regions can be decoded independently from other sub-regions for presentation.

An example is shown in <FIG> where the various regions encompass and/or are encompassed by other regions. As an example, the smallest region (<NUM>) has a <NUM> resolution and the largest region (<NUM>) has an <NUM> resolution. The base layer bitstream corresponds to the smallest spatial region, while additional layers in the bitstream correspond to increasingly larger image regions. Thus, a <NUM> display will only display the content within the <NUM> region (<NUM>). A <NUM> display will display the content of both the <NUM> and <NUM> regions (area within <NUM>), and an <NUM> display will display everything within the border <NUM>. In another example, a <NUM> display may display a down-sampled version of a <NUM> content and a <NUM> display may display a down-sampled version of <NUM> content. Ideally, the base layer region can be decoded by legacy devices, while the other regions can be used by future devices to extend the canvas size.

Existing coding standards, such as HEVC, may enable canvas scalability using tiles. In a tile representation, a frame is divided into a set of rectangular, non-overlapping regions. A receiver can decide to decode and display only the set of tiles required for display. In HEVC, coding dependencies between tiles are disabled. Specifically, entropy coding and reconstruction dependencies are not allowed across a tile boundary. This includes motion-vector prediction, intra prediction, and context selection. (In-loop filtering is the only exception which is allowed across the boundaries but can be disabled by a flag in the bit-stream. ) In addition, to allow the base layer to be decoded independently, encoder-side constraints for temporal motion constrained tiles (MCTS) are needed and temporal motion-constrained-tile sets supplemental enhancement information (SEI) messaging is required. For bitstream extraction and conformance purposes, motion-constrained tile sets extraction information sets SEI message is needed. The drawback of tile definition in HEVC, particularly with independently decoding capability, is loss of coding efficiency.

In an alternative implementation, HEVC allows canvas scalability using a pan-scan rectangle SEI message to extract a region of interest (ROI). SEI messaging specifies the rectangle area, but it does not provide information or constraints that enable the ROI to be decoded independently from other regions. Typically, the decoder needs to decode the full image to get the ROI.

The latest specification of VVC (Ref. [<NUM>]) describes spatial, quality, and view scalability using a combination of reference picture resampling (RPR) and reference picture selection (RPS), as discussed in more detail in Ref. [<NUM>]. It is based on single-loop decoding and block-based, on-the-fly, resampling. RPS is used to define prediction relationships between a base layer and one or more enhancement layers, or, more specifically, among coded pictures which are assigned to either a base layer or one or more enhancement layer(s). RPR is used to code a subset of the pictures, namely those of the spatial enhancement layer(s), at a resolution higher/smaller than the base layer while predicting from the smaller/higher base layer pictures. <FIG> depicts an example of spatial scalability according to the RPS/RPR framework.

As depicted in <FIG>, the bitstream includes two streams, a low-resolution (LR) stream (<NUM>) (e.g., standard definition, HD, <NUM>, and the like) and a higher-resolution (HR) stream, <NUM>, (e.g., HD, <NUM>, <NUM>, <NUM>, and the like). Arrows denote possible inter-coding dependencies. For example, HR frame <NUM>-P1 depends on LR frame <NUM>-<NUM>. To predict blocks in <NUM>-P1, a decoder will need to up-scale <NUM>-I. Similarly, HR frame <NUM>-P2 may depend on HR frame <NUM>-P1 and LR frame <NUM>-P1. Any predictions from LR frame <NUM>-P1will require a spatial up-scaling from LR to HR. In other embodiments, the order of LR and HR frames could also be reversed, thus the base layer could be the HR stream and the enhancement layer could be the LR stream. It is noted that the scaling of a base-layer picture is not performed explicitly as in SHVC. Instead, it is absorbed in inter-layer motion compensation and computed on-the-fly. In Ref. [<NUM>], the scalability ratio is implicitly derived using a cropping window.

ROI scalability is being supported in HEVC (Ref. [<NUM>]) as part of Annex H "Scalable high efficiency video coding," commonly referred to as SHVC. For example, in Section F. <NUM>, syntax elements related to scaled ref layer offset_present flag[i] and ref region offset_present flag[i] are defined. Related parameters are derived in equations (H-<NUM>) to (H-<NUM>) and (H-<NUM>) to (H-<NUM>). VVC does not yet support region of interest (ROI) scalability. As appreciated by the inventors, support for ROI scalability could enable canvas-size scalability using the same, single-loop, VVC decoder, without the need for scalability extensions as in SHVC.

As an example, given the three layers of data depicted in <FIG> (e.g., <NUM>, <NUM>, and <NUM>), <FIG> depicts an example embodiment of a bitstream that supports canvas-size scalability using the existing RPS/RPR framework. As depicted in <FIG>, the bitstream allocates its pictures into three layers or streams, a <NUM> stream (<NUM>), a <NUM> stream (<NUM>), and an <NUM> stream (<NUM>). Arrows denote examples of possible inter-coding dependencies. For example, pixel blocks in <NUM> frame <NUM>-P2 may depend on blocks in <NUM> frame <NUM>-P1, <NUM> frame <NUM>-P2, and <NUM> frame <NUM>-P1. Compared to prior scalability schemes that were using multiple-loop decoders, the proposed ROI scalability scheme has the following advantages and disadvantages:.

A key difference in enabling ROI scalability support between SHVC and proposed embodiments for VVC is that in SHVC the picture resolution is required to be the same for all pictures in the same layer. But in VVC, due to the RPR support, pictures in the same layer may have different resolutions. For example, in <FIG>, in SHVC, <NUM>-I, <NUM>-P1 and <NUM>-P2 require to have the same spatial resolution. But in VVC, due to RPR support, <NUM>-I, <NUM>-P1 and <NUM>-P2 can have different resolutions. For example, <NUM>-I and <NUM>-P1 can have a first low resolution (say, 720p), while <NUM>-P2 can have a second low resolution (say, 480p). Embodiments of this invention aim at supporting both ROI scalability across different layers and ROI for the pictures of the same layer within the existing the RPR framework. Another major difference is that in SHVC the motion vector from inter-layer prediction is constrained to be zero. But for VVC, such constraint does not exist, and a motion vector can be zero or non-zero. This reduces the constraints for identifying inter-layer correspondence. Next, example embodiments are presented on how ROI may be supported in a single layer bitstream within the existing RPR framework. Similar concepts are also applicable to scalable, multi-layer, coding.

<FIG> depict another example where support for single-layer bitstream with and without ROI may be desired. <FIG> depicts a low-delay coded bitstream, where each frame uses the previous frame as reference for motion estimation and compensation (ME/MC). Each picture is characterized by a picture order count (POC). Without loss of generality, as an example, pictures with POC <NUM>-<NUM> are coded with 1920x1080p spatial resolution. Pictures with POC4-<NUM> are coded with a <NUM>×720p spatial resolution, pictures with POC <NUM>-<NUM> are coded with a 960x540p resolution, and picture with POC = <NUM> is coded with a 1920x1080p resolution. For POC4, its reference picture (POC3) needs to use RPR in down-sampling mode to virtually generate a reference picture during motion compensation for proper prediction. For POC10, its reference picture (POC9) needs to use RPR in up-sampling mode to virtually generate a proper reference picture for proper prediction during motion compensation. However, the transition from POC6 to POC7 includes both resolution change and ROI cropping which, as depicted in the top row of <FIG>, it cannot be handled correctly and efficiently with scaling alone in the current RPR design. <FIG>, first row, shows how the scaling ratio is computed using the current RPR framework. Since RPR is only based on effective picture resolution, POC7 has a smaller resolution than POC6, thus, for POC7, it will assume its reference picture (POC6) needs to use RPR in down-sampling mode to generate a proper reference picture. But POC7 is actually an up-sampled version of a cropped ROI window in POC6. Therefore, the reference picture POC6 generation is not correct. As depicted in <FIG> (second row), to properly generate a reference picture for POC7, one needs to a) select a proper ROI (e.g., ROI <NUM>), and then scale that ROI to match the spatial resolution of POC7.

In an embodiment, instead of using the whole picture size, it is proposed to adjust the RPR scaling ratio according to a specified ROI area. An ROI window is specified by four parameters: leftOffset (LO), rightOffset (RO), topOffset (TO) and botOffset (BO). As shown in <FIG>, a set of (LOR, ROR, TOR, BOR) values is present in a reference picture (<NUM>), and a set of (LOc, ROc, TOc, BOc) values is present in the current picture (<NUM>). In the current RPR design, without ROI, the horizontal and vertical scaling ratios are calculated as: <MAT> where WR and WC denote the width of the reference and the current picture, and HR and He denote the height of the reference and the current picture. With ROI window support, in an embodiment, the scaling ratio calculation is modified as: <MAT>.

When the four ROI parameters (LOR, ROR, TOR, BOR) in the reference picture are equal to <NUM>, the whole reference picture corresponds to an ROI on the current picture. When the four ROI parameters (LOC, ROC, TOC, BOC) in the current picture are equal to <NUM>, the ROI area on the reference picture corresponds to the whole current picture; when both (LOR, ROR, TOR, BOR) and (LOC, ROC, TOC, BOC) are equal to <NUM>, then the mapping problem is reduced to the default RPR case.

Multiple reference pictures can be used for coding the current picture. Furthermore, different ROI offsets may present in different reference pictures of the same current picture. These different ROI window offset parameters can be signaled in a list using a high-level syntax, such as a sequence parameter set (SPS), a picture parameter set (PPS), an adaptation parameter set (APS), or any other high level syntax. If an ROI window does not change frequently, it is better to indicate its syntax in SPS; otherwise, it is better to indicate its syntax in APS. Table <NUM> depicts, without limitation, an example syntax signaled in SPS, based on the existing SPS syntax in Ref. [<NUM>] Section <NUM>. New syntax elements over Ref.[<NUM>] are highlighted. To save the number of overhead bits compared to the existing scaling window and conformance window offsets, a new parameter roi_offset_prec_shift is added so that the ROI window offsets parameters will be right shifted first by the value of roi_offset_prec_shift, before being encoded. This allows for using fewer bits for coding than coding the offsets parameters directly; however, this shifting is optional and can be removed, and in another embodiment the ROI offsets can be coded directly.

sps_rpr_roi_window_present_flag equal to <NUM> indicates that the lists of the reference picture resampling ROI window offset parameters follow next in the SPS. sps_rpr_roi_window_present_flag equal to <NUM> indicates that the lists of the reference picture resampling ROI window offset parameters are not present in the SPS. When not present, the value of sps rpr roi window_present flag is inferred to be equal to <NUM>.

num_roi_window_list_minus1 plus <NUM> specifies the number of roi_offset_list syntax elements that are present in the SPS. The value of num_roi_window_list_minusl shall be in the range of <NUM> to <NUM>, inclusive. When not present, the value of num_roi_window_list_minusl is inferred to be <NUM>.

roi_offset_prec_shift[ i ] specifies the left shift bit to the i-th roi_offset_list syntax elements. The value of roi_offset_prec_shift[ i ] shall be in the range of <NUM> to <NUM>, inclusive. When not present, the value of roi_offset_prec_shift[ i ] is inferred to be <NUM>.

roi_offset_list[ i ][ j ] left shifted by roi_offset_prec_shift[ i ] specifies the reference picture resampling ROI window offsets of the i-th roi_offset_list, in units of luma samples, which are applied for scaling ratio calcualtions, where j equals to <NUM> indicates the left offset, j equal to <NUM> indicates the right offset, j equal to <NUM> indicates the top offset, and j equals to <NUM> indicates the bottom offset. When no present, the values of roi_offset_list[ i ][ j ] are inferred to be <NUM>. The values of roi_offset_list[ i ][ <NUM> ] and roi_offset_list[ i ][ <NUM> ] shall be multiple of SubWidthC and the values of roi_offset_list[ i ][ <NUM> ] and roi_offset_list[ i ][ <NUM> ] shall be multiple of SubHeightC. The variable RoiOffsetList[ i ][ j ] is set equal to ( roi_offset_list[ i ][ j ] « roi_offset_prec_shift[ i ] ). The value of ( RoiOffsetList[ i ][ <NUM> ] + RoiOffsetList[ i ][ <NUM> ] ) shall be less than pic_width_in_luma_samples of the picture that the ROI window is associated with, and the value of ( RoiOffsetList [ i ][ <NUM> ] + RoiOffsetList [ i ][ <NUM> ] ) shall be less than pic_height_in_luma_samples of the picture that the ROI window is associated with.

In an embodiment, the exact ROI window used for each reference picture in the RPL (reference picture list) of the current coding slice can be specified at the slice header or other places where the reference picture list info is available. It can even be specified in the picture header too. Signaling in the slice header gives better flexibility because it needs to follow the exact reference picture signaling for each slice. Table <NUM> depicts an example of ROI signaling in the slice headers (see Ref.[<NUM>], syntax in <NUM>.

slice_rpr_roi_window_enabled_flag equal to <NUM> specifies that the ROI window offset parameters may be used for the scaling ratio calculations. slice_rpr_roi_window_enabled_flag equal to <NUM> specifies that the ROI window offset parameters may not be used for the scaling ratio calculations. When not present, the value of slice_rpr_roi_window_enabled_flag is inferred to be equal to <NUM>.

curr_roi_window_present_flag[ i ][ j ] equal to <NUM> specifies that a set of ROI window offset parameters is used in the current picture to derive the scaling ratio for the j-th entry of the i-th reference picture list. curr_roi_window_present_flag[ i ][ j ] equal to <NUM> specifies that a set of ROI window offset parameters is not used in the current picture to derive the scaling ratio for the j-th entry of the i-th reference picture list.

curr_roi_offset_idx[ i ][ j ], when present, specifies which set of ROI window offset parameters in the array roi_offset_list is used in the current picture to derive the scaling ratio for the j-th entry of the i-th reference picture list. The value of curr_roi_offset_idx[ i ][ j ] shall be in the range of <NUM> to num_roi_window_list_minus1, inclusive. The length of the syntax element is Ceil( Log2( num_roi_window_list_minus1+<NUM>) ) bits.

ref_roi_window_present_flag[ i ][ j ] equal to <NUM> specifies that a set of ROI window offset parameters is used in the reference picture to derive the scaling ratio for the j-th entry of the i-th reference picture list. ref_roi_window_present_flag[ i ][ j ] equal to <NUM> specifies that a set of ROI window offset parameters is not used in the reference picture to derive the scaling ratio for the j-th entry of the i-th reference picture list.

ref_roi_offset_idx[ i ] [ j ], when present, specifies which set of ROI window offset parameters in the array roi_offset_list is used in the reference picture to derive the scaling ratio for the j-th entry of the i-th reference picture list. The value of ref_roi_offset_idx[ i ][ j ] shall be in the range of <NUM> to num_roi_window_list_minus1, inclusive. The length of the syntax element is Ceil( Log2( num_roi_window_list_minus1+<NUM>) ) bits.

In the current VVC version, RPR is applied only when the scaling ratios in equation (<NUM>) are not both equal to <NUM> (e.g., the reference and the current picture have different sizes). When ROI is enabled, RPR could be activated even when both scaling ratios are equal to <NUM>. To support ROI when scaling ratios equal to <NUM>, one would also need to add a condition to check whether the current ROI window and reference ROI window have the same resolution. If they don't have the same resolution, then ROI offsets need to be taken into consideration during the motion compensation process.

In Ref. [<NUM>], the RPR condition to check if special handling is needed for a reference picture is given by: <MAT> In an embodiment supporting ROI, in an example, the test above can be adjusted as: <MAT> where fCurrPicWidth and fCurrPicHeight denote the width and height of the current picture, and fRefPicWidth and fRefPicHeight denote the width and height of the reference picture.

<FIG> depicts an example where ROI offsets need to be considered with scaling ratio equal to <NUM>. For example, as depicted in <FIG>, pictures PICO and PIC1 have different resolutions; however, picture POC1 uses as a reference ROI <NUM>. Assuming that ROI <NUM> has the same spatial resolution as picture POC1, no scaling will be required, but motion compensation in POC1 needs to take into consideration the ROI offsets in reference picture POC0. Picture POC2 has a different spatial resolution than picture POC1; however, when computing the reference picture for ROI <NUM>, if ROI <NUM> has the same spatial resolution as POC1, then no scaling will be required, but motion compensation in POC2 needs to take into consideration the ROI offset in the current picture POC2.

Appendix <NUM> provides examples on how the current VVC specification can be updated to support ROIs within the RPR framework. The updates on scaling ratio computation and scaled condition for each reference picture in each list are specified in Section <NUM>. <NUM> (Decoding process for reference picture lists construction), which includes equations (<NUM>) and (<NUM>). Updates on motion compensation or inter prediction are specified in Section <NUM>. <NUM> (Fractional sample interpolation process: General subsection), which replaces scaling_win_left_offset and scaling_win_top_offset with correct left offset (fCurrLeftOffset) and top offset (fCurrTopOffset) for the current picture. The key aspect is that the offset parameters need to be updated with the actual ROI parameters. Other changes to the existing decoding process are minimal. As before, examples of the proposed changes are depicted using a highlighted font.

<FIG> depicts an example dataflow of operations supporting reference picture resampling with support for ROI according to an embodiment. As an example, and without limitation, the data flow will be described with reference to the syntax parameters as described in Tables <NUM> and <NUM> and the highlighted operations described in Appendix <NUM> for each reference picture.

As depicted in <FIG>, in step <NUM>, a decoder receives and reads syntax parameters from a coded bitstream. The syntax parameters may include scaling window offsets, ROI window present flag and related offsets for a reference picture, and ROI window present flag and offsets for the current picture. If in Intra coding mode (<NUM>), the whole process is bypassed, otherwise (step <NUM>), the decoder initializes offset parameters according to the default VVC syntax, which, if needed, may be overwritten later on.

In step <NUM>, if slice_rpr_roi_window_enabled_flag = <NUM> (see Table <NUM> or Section <NUM>. <NUM> in Appendix <NUM>), then no ROI-related computations are needed at the slice level and the decoder can continue (in step <NUM>) to compute picture-wide scaling factors using the current version of VVC (Ref. [<NUM>]) (e.g., see equation (<NUM>)), with the offset parameters computed in step <NUM>. Otherwise, in step <NUM>, as noted also in Table <NUM>, the decoder checks the value of the curr_roi_window_present_flag to determine whether the current picture uses a set of ROI window offsets (e.g., <NUM>). If it does, in step <NUM>, it reads the offsets determining the ROI window in the current picture (e.g., by reading a pointer (e.g., curr_roi_offset_idx) to an array roi_offset_list[i][j], j= <NUM>, <NUM>, <NUM>, and <NUM>, as defined in Table <NUM> (or Section <NUM>. <NUM> in Appendix <NUM>). Next (step <NUM>), the decoder checks the value of the ref_roi_window_present_flag to determine whether the reference picture uses a set of ROI window offsets (e.g., <NUM>) to determine RPR scaling parameters. If it does, in step <NUM>, it reads the offsets determining the ROI window in the reference picture (e.g., by reading a pointer (e.g., ref_roi_offset_idx) to the array roi_offset_list[i][j], j= <NUM>, <NUM>, <NUM>, and <NUM>, as defined in Table <NUM> (or Section <NUM>. <NUM> in Appendix <NUM>). Given all these offsets, in step <NUM>, appropriate scaling factors are computed (e.g., see equation (<NUM>) and/or operations in Appendix <NUM>).

The current version of VVC (Ref. [<NUM>]) supports multi-layer scalability using the RPR framework, where the base layer is used as the long-term reference picture (LTRP) for an enhancement layer. As presented herein, the proposed solutions to support ROI within the RPR framework in a single layer are applicable to multi-layer scalability as well.

In another set of embodiments, a region of interest (ROI) window may be signaled in the picture header (PH) to override a scaling window which may be defined as part of the semantics in the Picture Parameter Set (PPS). Additional syntax parameters are used to denote whether the ROI scaling window is used in the current picture or the reference picture. Under such embodiments, instead of signaling multiple, but fixed, ROI windows in the sequence parameter set (SPS), there is a single, but variable-size, ROI window in each PH. Note that in Ref. [<NUM>], a "picture header" is denoted as a "syntax structure containing syntax elements that apply to all slices of a coded picture.

In an embodiment, in the slice header, for each active reference picture, it is signaled if the PH-scaling window is used or not for a pair of a current picture and a reference picture, and if used, if they override the current picture scaling window or the current reference picture scaling window. Compared to signaling the ROI scaling windows in the SPS, signaling in the PH allows for more flexibility. In addition, the proposed new designs minimize the number of proposed changes in the latest VVC working-draft specification (Draft <NUM>) (Ref. [<NUM>]).

In this disclosure four different embodiments of the invention are proposed. The first one will be discussed in full detail. The others will be discussed in comparison to the first one.

In the First variation, the PH scaling window is signaled using absolute offsets (e.g., see <FIG>), which override directly the scaling window. Tables <NUM> and <NUM> below correspond to Table <NUM>. <NUM> (Picture header structure syntax) and Table <NUM>. <NUM> (General slice header syntax) in Ref. [<NUM>]. As before, edits are highlighted. A more detailed syntax, semantics, and the decoding process are also described in Appendix <NUM>.

The variables PhScalingWinLeftOffset, PhScalingWinRightOffset, PhScalingWinTopOffset, and PhScalingWinBottomOffset, ares set equal to SubWidthC * ( ph_scaling win left offset « ph_scaling_win_offset_prec_shift ), SubWidthC * ( ph_scaling_win_right_offset « ph_scaling_win_offset_prec_shift ), SubHeightC * ( ph_scaling_win_top_offset « ph_scaling_win_offset_prec_shift ), and SubHeightC * ( ph_scaling_win_bottom_offset « ph_scaling_win_offset_prec_shift ), respectively.

The value of ( PhScalingWinLeftOffset + PhScalingWinRightOffset ) shall be less than pic_width_luma_samples of the picture which applies the scaling window in the PH. The value of ( PhScalingWinTopOffset + PicScalingWinBottomOffset) shall be less than pic_height_in_luma_samples of the picture which applies the scaling window in the PH.

The value of PhScalingWinLeftOffset shall be greater than or equal to SubWidthC * scaling_win_left_offset of the picture which applies the scaling window in the PH.

The value of PhScalingWinRightOffset shall be greater than or equal to SubWidthC * scaling_win_right_offset of the picture which applies the scaling window in the PH.

The value of PhScalingWinTopOffset shall be greater than or equal to SubHeightC * scaling_win_top_offset of the picture which applies the scaling window in the PH.

The value of PhScalingWinBottomOffset shall be greater than or equal to SubHeightC * scaling_win_bottom_offset of the picture which applies the scaling window in the PH.

Note: In this variation, with absolute offsets, the offsets need to be defined so that the ROI window is equal or smaller than the PPS scaling window. This constraint can be removed when defining delta offsets, as in the Second and Fourth variations to be discussed later.

slice_scaling_win_idc[ i ][ j ] equal to <NUM> specifies the scaling window offsets in PH is not used for scaling ratio calculation for the j-th entry in reference picture list i of the current slice. slice_scaling_win_idc[ i ][ j ] equal to <NUM> specifies the scaling window offsets in PH is used to override the offsets of the reference picture for scaling ratio calculation for the j-th entry in reference picture list i of the current slice. slice_scaling_win_idc[ i ][ j ] equal to <NUM> specifies the scaling window offsets in PH is used to override the offsets of the current picture for scaling ratio calculation for the j-th entry in reference picture list i of the current slice.

It is a requirement of bitstream conformance that for any active entry in a reference picture list for all slices of the current picture, which refers to the same reference picture, the value of slice_scaling_win_idc[ i ][ j ] shall be the same.

<FIG> depicts an example process flow for the First variation. As depicted in <FIG>, during decoding, in step <NUM>, the decoder needs to parse the Picture Header (PH). As noted in step <NUM>, the follow-up steps (e.g., <NUM>-<NUM>) are repeated over all slices in the reference pictures referred to by the PH. For Intra slices, there is no picture scaling or ROI-related processing and decoding proceeds as defined in VVC. For Inter slices, as noted in step <NUM>, the decoder repeats the follow-up steps (e.g., <NUM>-<NUM>) over all active reference pictures, thus, for each reference picture, first, it initializes the scaling windows using syntax elements defined in the corresponding PPS of the current picture and the reference picture. Next, in step <NUM>, the decoder checks if an ROI-related flag (e.g., ph_scaling_window_present_flag) is set. If not, decoding proceeds as in the existing (with no ROI) decoding process (step <NUM>), otherwise, in step <NUM> for each slice in the reference picture, the decoder checks an ROI-related parameter (e.g., slice_scaling_win_idc). If that parameter is <NUM>, again, no ROI-related processing is performed (step <NUM>), otherwise, depending on its value (e.g., <NUM> or <NUM>), the decoder overrides the scaling window offsets in either the reference frane (step <NUM>) or the current frame (step <NUM>). Finally, in step <NUM>, the decoder proceeds to compute the RPR factors for inter prediction taking into account the ROI syntax parameters decoded earlier.

As shown below and in Appendix <NUM>, given the above parameters, the existing VVC decoding process needs to be modified as noted below. Again, section numbers refer to sections in the VVC specification, and the proposed edits are highlighted.

This process is invoked at the beginning of the decoding process for each slice of a non-IDR picture.

Reference pictures are addressed through reference indices. A reference index is an index into a reference picture list. When decoding an I slice, no reference picture list is used in decoding of the slice data. When decoding a P slice, only reference picture list <NUM> (i.e., RefPicList[ <NUM> ]), is used in decoding of the slice data. When decoding a B slice, both reference picture list <NUM> and reference picture list <NUM> (i.e., RefPicList[ <NUM> ]) are used in decoding of the slice data.

At the beginning of the decoding process for each slice of a non-IDR picture, the reference picture lists RefPicList[ <NUM> ] and RefPicList[ <NUM> ] are derived. The reference picture lists are used in marking of reference pictures as specified in clause <NUM>. <NUM> or in decoding of the slice data.

The reference picture lists RefPicList[ <NUM> ] and RefPicList[ <NUM> ], the reference picture scaling ratios RefPicScale[ i ][j ][ <NUM> ] and RefPicScale[ i ][j ][ <NUM> ], the reference picture scaled flags RprConstraintsActive[ <NUM> ][ j ] and RprConstraintsActive[ <NUM> ][ j ] , and the reference picture resampling offsets RefRprLeftOffset[ i ][ j ], RefRprTopOffset[ i ][ j ], CurrRprLeftOffset[ i ][ j ], CurrRpfTopOffset[ i ][ j ], are derived as follows:
<IMG>
<IMG>.

The prediction block border extension size brdExtSize is derived as follows:.

The variable refWraparoundEnabledFlag is set equal to ( pps_ref_wraparound_enabled_flag && !refPicIsScaled ).

The variable fRefLeftOffset is set equal to ( ( RefRpfLeftOffset[ X ][ refIdxLX ]) « <NUM>),.

The variable fRefTopOffset is set equal to ( ( RefRprTopOffset[ X ][ refIdxLX ] ) « <NUM>)
The variable fCurrLeftOffset is set equal to CurrRprLeftOffset[ X ][ refIdxLX ].

The variable fCurfTopOffset is set equal to CurrRprTopOffset[ X ][ refIdxLX ].

The (sbWidth + brdExtSize)x(sbHeight + brdExtSize) array predSamplesLX of prediction sample values is derived as follows:.

Under this embodiment, the scaling window in the Picture Header is signaled with relative offset values (e.g., delta values), which need to be added to the absolute scaling window offset values. By constraining relative offset values to be larger than or equal to <NUM>, one can remove the bitstream conformance requirement in the First variation (see Note before Table <NUM>). The changes, compared to the First variation, are listed below.

ph_scaling_win_left_offset, ph_scaling_win_right_offset, ph_scaling_win_top_offset, and.

The variables PhScalingWinLeftOffset, PhScalingWinRightOffset, PhScalingWinTopOffset, and PhScalingWinBottomOffset, ares set equal to SubWidthC * ( ph_scaling win left offset « ph_scaling win offset_prec_shift ), SubWidthC * ( ph_scaling_win_right_offset « ph_scaling win offset_prec_shift ), SubHeightC * ( ph_scaling_win_top_offset « ph_scaling_win_offset_prec_shift ), and SubHeightC * ( ph_scaling_win_bottom_offset « ph_scaling_win_offset_prec_shift ), respectively.

The value of ( SubWidthC *scaling_win_left_offset + PhScalingWinLeftOffset + SubWidthC *scaling_win_right_offset + PhScalingWinRightOffset ) shall be less than pic_width_luma_samples of the picture which applies the scaling window in the PH. The value of ( SubHeightC * scaling_win_top_offset + PhScalingWinTopOffset + SubHeightC * scaling_win_bottom_offset + PicScalingWinBottomOffset) shall be less than pic_height_in_luma_samples of the picture which applies the scaling window in the PH.

<FIG> depicts an example process flow for the Second variation. As depicted in <FIG>, compared to the process in <FIG>, the only changes are in steps <NUM> and <NUM>, where the decoder needs to compute the ROI windows using the delta offsets instead of using the absolute offsets, as used in steps <NUM> and <NUM> of <FIG>.

Compared to the First variation, the decoding process then needs to be modified as follows. Underlined syntax elements denote differences over both the existing VVC version and the First variation.

In this embodiment, compared to the First variation, a new syntax element (e.g., switch ph_scaling_window_present_idc) explicitly specifies if the PH scaling window is used to override the current or the reference picture (see Table <NUM>). For example, without limitation, if its value is <NUM>, then there is no ROI scaling, if its value is <NUM>, then one uses the ROI offsets to override the scaling window in the reference picture, and if its value is <NUM>, then one uses the ROI offsets to override the scaling window in the current picture. In the slice header (see Table <NUM>), another syntax element (e.g., flag slice_scaling_win_flag[i][j]) signals whether ROI scaling is enabled in the slice, and if it does, it uses the value of the ROI switch in the Picture Header signal (e.g., SW = ph_scaling_window_present_idc) (that is, when SW is <NUM> or <NUM>) to adjust the scaling window either for the reference picture (if SW=<NUM>) or the current picture (if SW=<NUM>). Compared to the First variation, it saves bits in the slice header, but has less flexibility. For example, this approach uses two bits for ph_scaling_window_present_idc and forces all slices within a PH to override the default scaling window in either the reference picture or the reference picture. Then, at the slice level, a single bit helps identify whether an ROI window is used. Using fewer bits at the slice level, may reduce the bit-overhead when there are multiple reference pictures defined per slice.

The new syntax element ph_scaling_window_present_idc is defined as:.

The new syntax element slice_scaling_win_flag[ i ][ j ] is defined as:.

It is a requirement of bitstream conformance that for any active entry in a reference picture list for all slices of the current picture, which refers to the same reference picture, the value of slice_scaling_win_flag[ i ][ j ] shall be the same.

<FIG> depicts an example process flow for the Third variation. As depicted in <FIG>, compared to the process in <FIG>, the only changes are in steps <NUM> and <NUM>, where the decoder proceeds according to the newly defined syntax elements. Note that in step <NUM>, for "Yes", the values of "<NUM>" or "<NUM>" are inherited from the value of the ROI switch SW = ph_scaling_window_present_idc variable (see step <NUM>) and are used after step <NUM> to decide whether the ROI offsets are to be applied on the reference picture (step <NUM>) (e.g., when SW=<NUM>) or the current picture (step <NUM>) (e.g., when SW=<NUM>). Then, the decoding process is modified as follows. Compared to the First variation, the new syntax elements are underlined.

In Section <NUM>. <NUM> of VVC
<IMG>
<IMG>
<IMG>.

This variation combines the syntax elements of the Second variation (transmitting delta offsets) with the new syntax elements defined in the Third variation. <FIG> depicts an example process flow for the Fourth variation. As depicted in <FIG>, compared to the process in <FIG>, the only changes are in steps <NUM> and <NUM>, where the decoder proceeds according to the newly defined syntax elements, as discussed in relation to <FIG>. Then, the decoding process is modified as follows. Compared to the First variation, underlined elements denote the changes due to the Third variation and bold elements denote changes due to the Second variation.

From an implementation point of view, to reduce the required memory for motion compensation when an ROI window is used for the current picture, one can add an encoder constrain that for samples/blocks outside the ROI window only intra prediction is being used.

Embodiments of the present invention may be implemented with a computer system, systems configured in electronic circuitry and components, an integrated circuit (IC) device such as a microcontroller, a field programmable gate array (FPGA), or another configurable or programmable logic device (PLD), a discrete time or digital signal processor (DSP), an application specific IC (ASIC), and/or apparatus that includes one or more of such systems, devices or components. The computer and/or IC may perform, control, or execute instructions relating to canvas size resizing, such as those described herein. The computer and/or IC may compute any of a variety of parameters or values that relate to canvas size resizing described herein. The image and video embodiments may be implemented in hardware, software, firmware and various combinations thereof.

Certain implementations of the invention comprise computer processors which execute software instructions which cause the processors to perform a method of the invention. For example, one or more processors in a display, an encoder, a set top box, a transcoder, or the like may implement methods related to canvas size resizing as described above by executing software instructions in a program memory accessible to the processors. Embodiments of the invention may also be provided in the form of a program product. The program product may comprise any non-transitory and tangible medium which carries a set of computer-readable signals comprising instructions which, when executed by a data processor, cause the data processor to execute a method of the invention. Program products according to the invention may be in any of a wide variety of non-transitory and tangible forms. The program product may comprise, for example, physical media such as magnetic data storage media including floppy diskettes, hard disk drives, optical data storage media including CD ROMs, DVDs, electronic data storage media including ROMs, flash RAM, or the like. The computer-readable signals on the program product may optionally be compressed or encrypted. Where a component (e.g. a software module, processor, assembly, device, circuit, etc.) is referred to above, unless otherwise indicated, reference to that component (including a reference to a "means") should be interpreted as including as equivalents of that component any component which performs the function of the described component (e.g., that is functionally equivalent), including components which are not structurally equivalent to the disclosed structure which performs the function in the illustrated example embodiments of the invention.

Example embodiments that relate to canvas size resizing are thus described. In the foregoing specification, embodiments of the present invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention, and what is intended by the applicants to be the invention, is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

This Appendix includes an example embodiment for canvas resizing as implemented using the VVC video codec (Ref.[<NUM>]). Proposed edits to the existing VVC specification are highlighted.

sps rpr roi window_present flag equal to <NUM> indicates that the lists of the reference picture resampling ROI window offset parameters follow next in the SPS. sps_rpr_roi_window_present_flag equal to <NUM> indicates that the lists of the reference picture resampling ROI window offset parameters are not present in the SPS. When not present, the value of sps_rpr_roi_window_present_flag is inferred to be equal to <NUM>.

num_roi_window_list_minus1 plus <NUM> specifies the number of roi_offset_list syntax elements that are present in the SPS. The value of num_roi_window_list_minus1 shall be in the range of <NUM> to <NUM>, inclusive. When not present, the value of num_roi_window_list_minusl is inferred to be <NUM>.

roi_offset_list[ i ][ j ] left shifted by roi_offset_prec_shift[ i ] specifies the reference picture resampling ROI window offsets of the i-th roi_offset_list, in units of luma samples, which are applied for scaling ratio calcualtions, where j equals to <NUM> indicates the left offset, j equal to <NUM> indicates the right offset, j equal to <NUM> indicates the top offset, and j equals to <NUM> indicates the bottom offset. When no present, the values of roi_offset_list[ i ][ j ] are inferred to be <NUM>. The values of roi_offset_list[ i ][ <NUM> ] and roi_offset_list[ i ][ <NUM> ] shall be multiple of SubWidthC and the values of roi_offset_list[ i ][ <NUM> ] and roi_offset_list[ i ][ <NUM> ] shall be multiple of SubHeightC.

The variable RoiOffsetList[ i ][ j ] is set equal to ( roi_offset_list[ i ][ j ] « roi_offset_prec_shift[ i ] ).

The value of ( RoiOffsetList[ i ][ <NUM> ] + RoiOffsetList[ i ][ <NUM> ] ) shall be less than pic_width_in_luma_samples of the picture that the ROI window is associated with, and the value of ( RoiOffsetList [ i ][ <NUM> ] + RoiOffsetList [ i ][ <NUM> ] ) shall be less than pic_height_in_luma_samples of the picture that the ROI window is associated with.

ref_roi_offset_idx[ i ][ j ], when present, specifies which set of ROI window offset parameters in the array roi_offset_list is used in the reference picture to derive the scaling ratio for the j-th entry of the i-th reference picture list. The value of ref_roi_offset_idx[ i ][ j ] shall be in the range of <NUM> to num_roi_window_list_minus1, inclusive. The length of the syntax element is Ceil( Log2( num_roi_window_list_minus1+<NUM>) ) bits.

At the beginning of the decoding process for each slice of a non-IDR picture, the reference picture lists RefPicList[ <NUM> ] and RefPicList[ <NUM> ] are derived. The reference picture lists are used in marking of reference pictures as specified in clause <NUM>. <NUM> or in decoding of the slice data. NOTE <NUM> - For an I slice of a non-IDR picture that it is not the first slice of the picture, RefPicList[ <NUM> ] and RefPicList[ <NUM> ] may be derived for bitstream conformance checking purpose, but their derivation is not necessary for decoding of the current picture or pictures following the current picture in decoding order. For a P slice that it is not the first slice of a picture, RefPicList[ <NUM> ] may be derived for bitstream conformance checking purpose, but its derivation is not necessary for decoding of the current picture or pictures following the current picture in decoding order.

The reference picture lists RefPicList[ <NUM> ] and RefPicList[ <NUM> ], the reference picture scaling ratios RefPicScale[ i ][j ][ <NUM> ] and RefPicScale[ i ][j ][ <NUM> ], the reference picture scaled flags RefPicIsScaled[ <NUM> ] and RefPicIsScaled[ <NUM> ], the ROI offsets lists for the current picture CurrROIOffset[ i ][ j ][ <NUM> ], CurrROIOffset[ i ][ j ][ <NUM> ], CurrROIOffset[ i ][ j ][ <NUM> ], and CurrROIOffset[ i ][ j ][ <NUM> ] and the ROI offsets lists for the reference picture RefROIOffset[ i ][ j ][ <NUM> ], RefROIOffset[ i ][ j ][ <NUM> ], RefROIOffset[ i ][ j ][ <NUM> ], and RefROIOffset[ i ][ j ][ <NUM> ], relative to the reference picture RcfPicList[ i ][ j ], are constructed as follows:
<IMG>
<IMG>
<IMG>
<IMG>
<IMG>.

The prediction block border extension size brdExtSize is derived as follows: <MAT>.

The variable fRefLeftOffset is set equal to ( RefROIOffset[ X ][ refIdxLX ][ <NUM> ] « <NUM>).

The variable fRefLeftOffset is equal to ( RefROIOffset[ X ][ refIdxLX ][ <NUM> ] « <NUM>).

The variable fCurrLeftOffset is set equal to CurrROIOffset[ X ][ refIdxLX ][ <NUM> ].

The variable fCurrTopOffset is set equal CurrROIOffset[ X ][ refIdxLX ][ <NUM> ].

NOTE - Unlike the process specified in clause <NUM>. <NUM>, this process uses both sps_chroma_vertical_collocated_flag and sps_chroma_horizontal_collocated_flag.

This Appendix includes an example embodiment for ROI support as implemented using the First variation within the VVC video codec (Ref.[<NUM>]). Proposed edits to the existing VVC specification are highlighted.

scaling_win_left_offset, scaling_win_right_offset, scaling_win_top_offset, and.

The value of SubWidthC * ( scaling_win_left_offset + scaling_win_right_offset ) shall be less than pic_width_in_luma_samples, and the value of
SubHeightC * ( scaling_win_top_offset + scaling_win_bottom_offset ) shall be less than pic_height_in_luma_samples.

The variables PicOutputWidthL and PicOutputHeightL are derived as follows: <MAT> <MAT>.

Let refPicOutputWidthL and refPicOutputHeightL be the PicOutputWidthL and PicOutputHeightL, respectively, of a reference picture of a current picture referring to this PPS. It is a requirement of bitstream conformance that all of the following conditions are satisfied:.

ph_scaling_window_present_flag equal to <NUM> specifies that the scaling window offset parameters are present in the PH and may be applied for the scaling ratio calculation for all slices associated PH. ph_scaling_window_present_flag equal to <NUM> specifies that the scaling window offset parameters are not present in the PH. When not present, the value of ph_scaling_window_present_flag is inferred to be equal to <NUM>.

ph_scaling_win_offset_offset_prec_shift specifies the number of bits by which a left shift is performed for the calculation of the scaling window offsets. The value of ph_scaling_win_offset_prec_shift shall be in the range of <NUM> to <NUM>, inclusive.

ph_scaling_win_left_offset, ph_scaling_win_right_offset, ph_scaling_win_top_offset, and ratio calculation. When not present, the values of ph_scaling_win_left_offset, ph_scaling_win_right_offset, ph_scaling_win_top_offset, and ph_scaling_win_bottom_offset are inferred to be equal to <NUM>.

The variables PhScalingWinLeftOffset, PhScalingWinRightOffset, PhScalingWinTopOffset, and PhScalingWinBottomOffset, ares set equal to SubWidthC * ( ph_scaling_win_left_offset « ph_scaling_win_left_offset_prec_shift ). SubWidthC * ( ph_scaling_win_right_offset « ph_scaling_win_offset_prec_shift ), SubHeightC * ( ph_scaling_win_top_offset « ph_scaling_win_offfset_prec_shift ), and SubHeightC * ( ph_scaling_win_bottom_offset « ph_scaling_win_offset_prec_shift ), respectively.

slice_scaling_win_idc[ i ][ j ] equal to <NUM> specifies the scaling window offsets in PH is nor used for scaling ratio calculation for the j-th entry in reference picture list i of the current slice, slice_scaling_win_idc[ i ][ j ] equal to <NUM> specifies the scaling window offsets in PH is used to override the offsets of the reference picture for scaling ratio calculation for the j-th entry in reference picture list i of the current slice, slice_scaling_win_idc[ i ][ j ] equal to <NUM> specifies the scaling window offsets in PH used to override the offsets of the current picture for scaling ratio calculation for the j-th entry in reference picture list i of the current slice. It is a requirement of bitstream conformance that for any active entru in a reference picture list for all slices of the current picture, which refers to the same reference picture, the value of slice_scaling_win_idc_[ i ][ j ] shall be the same.

The reference picture lists RefPicList[ <NUM> ] and RefPicList[ <NUM> ], the reference picture scaling ratios RefPicScale[ i ][ j ][ <NUM> ] and RefPicScale[ i ][ j ][ <NUM> ], the reference picture scaled flags RprConstraintsActive[ <NUM> ][ j ] and RprConstraintsActive[ <NUM> ][ j ] and the picture resampling offsets RefRprLeftOffset[ i ][ j ], RefRprTopOffset[ i ][ j ], CurrRprLeftOffset[ i ][ j ], CurrRprTopOffset[ i ][ j ], are derived as follows:
<IMG>
<IMG>.

The variable fRefLeftOffset is set equal to ( ( RefRprLeftOffset[ X ][ refIdxLX ] ) << <NUM> ),.

The variable fRefTopOffset is set equal to ( ( RefRprTopOffset[ X ][ refIdxLX ] ) » <NUM> ).

The variable fCurrLeftOffset is set equal to CurrRprLeftOffset[ X ][ refIdxLX ].

The variable fCurrTopOffset is set equal to CurrRprTopOffset[ X ][ refIdxLX ].

Claim 1:
A method to decode a coded bitstream with region of interest (ROI) support, the method performed by a processor and comprising:
receiving a coded bitstream comprising coded pictures and syntax parameters for one or more regions of interest (ROI) within the coded pictures, wherein the syntax parameters comprise a picture header with ROI picture header parameters and a slice header with ROI slice header parameters, wherein the ROI picture header parameters comprise an ROI enabling flag and ROI offset parameters for a scaling window, and the ROI slice header parameters comprise an ROI switch parameter denoting whether ROI scaling is enabled at a slice level and whether the ROI offset parameters in the picture header are applied to a reference picture or a current picture; and
decoding a coded region in a current picture in the coded bitstream, wherein decoding the coded region comprises:
for the current picture and an active reference picture in an Inter slice:
initializing (<NUM>) a default scaling window in the Inter slice using values defined in a picture parameter set;
if detecting (<NUM>) that the ROI enabling flag is set to <NUM>:
overriding (<NUM>, <NUM>) the parameters of the default scaling window based on the ROI offset parameters and the ROI switch parameter to generate an ROI scaling window; and
applying reference picture resampling (<NUM>) using the ROI scaling window.