EP4670358A1

EP4670358A1 - TILE-BASED STREAMING OF 360 DEGREE VIDEO CONTENT

Info

Publication number: EP4670358A1
Application number: EP24711440.8A
Authority: EP
Inventors: Guan-Ming Su; Peng Yin; Taoran Lu; Sheng Qu
Original assignee: Dolby Laboratories Licensing Corp
Current assignee: Dolby Laboratories Licensing Corp
Priority date: 2023-02-22
Filing date: 2024-02-20
Publication date: 2025-12-31
Also published as: CN120814237A; WO2024178003A1

Abstract

Methods and apparatus for tile-based streaming of 360-degree video content. According to an example embodiment, a method of reconstructing a 360-degree image at an electronic decoder includes selecting subsets of received tile-image and tile-metadata bitstreams representing the 360-degree image and decoding those subsets to reconstruct corresponding overlapping tiles of the 360-degree image. The method also includes assembling the overlapping tiles into a viewable image by performing tile-fusion operations directed at forming portions of the viewable image corresponding to the overlap regions of the tiles. In some examples, the tile-fusion operations include computing a pixel value, for a pixel location in an overlap region of two overlapping tiles, as a weighted sum of the corresponding pixel values of those two tiles. In some examples, the weights for the weighted sum are determined based on the distance from the tile boundary to the pixel location.

Description

TILE-BASED STREAMING OF 360-DEGREE VIDEO CONTENT 1. Cross-Reference to Related Applications [0001] This application claims the benefit of priority from U.S. Provisional Patent Application No.63/486,322, filed February 22, 2023 and EP Patent Application No. 23169112.2, filed April 21, 2023, each of which are hereby incorporated by reference in their entirety. 2. Field of the Disclosure [0002] Various example embodiments relate to handling images and, more specifically but not exclusively, to streaming video content. 3. Background [0003] 360-degree videos, also referred to as surround, immersive, or spherical videos, are video recordings where a view in substantially every direction is recorded at the same time, e.g., shot using an omnidirectional camera or a collection of cameras. During playback on a flat or curved display, personal computer, mobile device, or head-mounted display, the viewer has control of the viewing direction, thereby viewing a selected subfield of view of the 360-degree recording. In some examples, the viewer can pan around the video by clicking and dragging. On some smartphones, internal sensors, such as the gyroscope, can also be used to pan the video based on the orientation of the device. Taking advantage of these features, stereoscope-style enclosures for smartphones are being developed to view 360-degree videos in an immersive format similar to virtual reality. BRIEF SUMMARY OF SOME SPECIFIC EMBODIMENTS [0004] Disclosed herein are various embodiments of methods and apparatus for tile-based streaming of 360-degree video content. According to an example embodiment, a method of reconstructing a 360-degree image at an electronic decoder includes (i) selecting subsets of received tile-image and tile-metadata bitstreams representing the 360-degree image and (ii) decoding those subsets to reconstruct corresponding partially overlapping tiles of the 360- degree image. The method also includes assembling the partially overlapping tiles into a viewable image by performing tile-fusion operations directed at forming portions of the viewable image corresponding to the overlap regions of the tiles. In some examples, the tile- fusion operations include computing a pixel value, for a pixel location in an overlap region of two partially overlapping tiles, as a weighted sum of the corresponding pixel values of those two tiles. In some examples, the weights for the weighted sum are determined based on the distance from the tile boundary to the pixel location. [0005] According to an example embodiment, provided is a method of encoding a 360- degree image, the method comprising: partitioning, with an electronic encoder, the 360- degree image into a plurality of first tiles; padding, with the electronic encoder, each of the first tiles to generate a corresponding plurality of second tiles, the padding being configured to add to each of the first tiles respective panoramically adjacent regions from respective other ones of the first tiles; generating, with the electronic encoder, a plurality of tile-image bitstreams and a plurality of corresponding tile-metadata bitstreams by applying video encoding to individual tiles of at least a selected subset of the plurality of second tiles; and generating, with the electronic encoder, a global metadata bitstream corresponding to the 360-degree image. [0006] According to another example embodiment, provided is an apparatus for encoding a 360-degree image, the apparatus comprising: at least one processor; and at least one memory including program code, wherein the at least one memory and the program code are configured to, with the at least one processor, cause the apparatus at least to: partition the 360-degree image into a plurality of first tiles; pad each of the first tiles to generate a corresponding plurality of second tiles, the padding being configured to add to each of the first tiles respective panoramically adjacent regions from respective other ones of the first tiles; generate a plurality of tile-image bitstreams and a plurality of corresponding tile- metadata bitstreams by applying video encoding to individual tiles of at least a selected subset of the plurality of second tiles; and generate a global metadata bitstream corresponding to the 360-degree image. [0007] According to yet another example embodiment, provided is a non-transitory computer-readable medium storing instructions that, when executed by an electronic processor, cause the electronic processor to perform operations comprising a method of encoding a 360-degree image, the method comprising: partitioning, with an electronic encoder, the 360-degree image into a plurality of first tiles; padding, with the electronic encoder, each of the first tiles to generate a corresponding plurality of second tiles, the padding being configured to add to each of the first tiles respective panoramically adjacent regions from respective other ones of the first tiles; generating, with the electronic encoder, a plurality of tile-image bitstreams and a plurality of corresponding tile-metadata bitstreams by applying video encoding to individual tiles of at least a selected subset of the plurality of second tiles; and generating, with the electronic encoder, a global metadata bitstream corresponding to the 360-degree image. [0008] According to yet another example embodiment, provided is a method of reconstructing a 360-degree image, the method comprising: based on an end-viewer viewport, selecting, with an electronic decoder, a first subset of a plurality of tile-image bitstreams and a corresponding second subset of a plurality of tile-metadata bitstreams representing the 360-degree image; decoding, with the electronic decoder, individual tile- image bitstreams of the first subset and the corresponding second subset to reconstruct a tile subset of a plurality of second tiles, each of the second tiles including a respective one of a plurality of first tiles of the 360-degree image and respective added portions having panoramically adjacent regions from respective other ones of the first tiles; and assembling, with the electronic decoder, the tile subset into a viewable image based on a global metadata bitstream representing the 360-degree image, said assembling including tile-fusion operations applied to the respective added portions in the tile subset and configured to form portions of the viewable image corresponding to boundaries between the first tiles. [0009] According to yet another example embodiment, provided is an apparatus for reconstructing a 360-degree image, the apparatus comprising: at least one processor; and at least one memory including program code, wherein the at least one memory and the program code are configured to, with the at least one processor, cause the apparatus at least to: based on an end-viewer viewport, select a first subset of a plurality of tile-image bitstreams and a corresponding second subset of a plurality of tile-metadata bitstreams representing the 360- degree image; decode individual tile-image bitstreams of the first subset and the corresponding second subset to reconstruct a tile subset of a plurality of second tiles, each of the second tiles including a respective one of a plurality of first tiles of the 360-degree image and respective added portions having panoramically adjacent regions from respective other ones of the first tiles; and assemble the tile subset into a viewable image based on a global metadata bitstream representing the 360-degree image, said assembling including tile-fusion operations applied to the respective added portions in the tile subset and configured to form portions of the viewable image corresponding to boundaries between the first tiles. [0010] According to yet another example embodiment, provided is a non-transitory computer-readable medium storing instructions that, when executed by an electronic processor, cause the electronic processor to perform operations comprising a method of reconstructing a 360-degree image, the method comprising: based on an end-viewer viewport, selecting, with an electronic decoder, a first subset of a plurality of tile-image bitstreams and a corresponding second subset of a plurality of tile-metadata bitstreams representing the 360-degree image; decoding, with the electronic decoder, individual tile- image bitstreams of the first subset and the corresponding second subset to reconstruct a tile subset of a plurality of second tiles, each of the second tiles including a respective one of a plurality of first tiles of the 360-degree image and respective added portions having panoramically adjacent regions from respective other ones of the first tiles; and assembling, with the electronic decoder, the tile subset into a viewable image based on a global metadata bitstream representing the 360-degree image, said assembling including tile-fusion operations applied to the respective added portions in the tile subset and configured to form portions of the viewable image corresponding to boundaries between the first tiles. BRIEF DESCRIPTION OF THE DRAWINGS [0011] Other aspects, features, and benefits of various disclosed embodiments will become more fully apparent, by way of example, from the following detailed description and the accompanying drawings, in which: [0012] FIG.1 depicts an example process for a video delivery pipeline. [0013] FIG.2 is a block diagram illustrating a 360-degree high-dynamic-range (HDR) video encoder that can be used in the delivery pipeline of FIG.1 according to an embodiment. [0014] FIG.3 is a block diagram illustrating a packager module according to an embodiment. [0015] FIG.4 is a block diagram illustrating an example selection operation implemented using the packager module of FIG.3 according to an embodiment. [0016] FIG.5 is a block diagram illustrating a 360-degree HDR video decoder that can be used in the delivery pipeline of FIG.1 according to an embodiment. [0017] FIG.6 is a block diagram illustrating bitstream-assembler operations in the 360- degree HDR video decoder of FIG.5 according to an embodiment. [0018] FIGS.7A-7D show example pseudocodes that can be used to implement some of the bitstream assembler operations of FIG.6 according to an embodiment. [0019] FIG.8 is a block diagram that pictorially illustrates a tiled image frame according to an embodiment. [0020] FIGS.9A-9B show a flowchart of a bitstream assembling method that can be used to implement some of the bitstream assembler operations of FIG.6 according to an embodiment. [0021] FIG.10 is a block diagram illustrating picture boundary padding according to an embodiment. [0022] FIGS.11-12 is block diagrams illustrating tile boundary padding according to an embodiment. [0023] FIG.13 is a block diagram illustrating a layout representing an expanded Cube- Map Projection (CMP) format according to one example. [0024] FIG.14 is a block diagram illustrating a tile partition of the layout of FIG.13 according to one example. [0025] FIGS.15-17 are block diagrams illustrating tile padding in the layout of FIG.13 according to various examples. DETAILED DESCRIPTION [0026] This disclosure and aspects thereof can be embodied in various forms, including hardware, devices or circuits controlled by computer-implemented methods, computer program products, computer systems and networks, user interfaces, and application programming interfaces; as well as hardware-implemented methods, signal processing circuits, memory arrays, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), and the like. The foregoing is intended solely to give a general idea of various aspects of the present disclosure and does not limit the scope of the disclosure in any way. [0027] In the following description, numerous details are set forth, such as optical device configurations, timings, operations, and the like, in order to provide an understanding of one or more aspects of the present disclosure. It will be readily apparent to one skilled in the art that these specific details are merely exemplary and not intended to limit the scope of this application. [0028] Some embodiments disclosed herein provide a tile-based, 360-degree, high- dynamic-range (HDR) video encoding/streaming/decoding architecture. Due to the continuing development and commercialization of Head-Mounted Device (HMD) technologies, 360-degree video formats are gaining in popularity, for example, because such technologies can provide improved immersive viewer experience. Support of the HDR and wide color gamut (WCG) are important features for further enhancement of the user experience. However, there are several challenges to bringing HDR/WCG into the corresponding codec/playback ecosystem. At least some embodiments disclosed herein address these challenges by extending certain existing workflows towards 360-degree HDR scenarios, thereby taking full advantage of the existing coding infrastructure as an alternative to a de novo development. [0029] 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 blacks (darks) 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 render, adequately or approximately, 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. [0030] As used herein, the term “high dynamic range” (HDR) relates to a DR breadth that spans 14-15 or more orders of magnitude of the 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. As used herein, the terms “enhanced dynamic range” (EDR) or “visual dynamic range” (VDR) may individually or interchangeably relate to the DR that is perceivable within a scene or image by a human visual system that includes eye movements, allowing for some light adaptation changes across the scene or image. Herein, EDR may relate to a DR that spans 5 to 6 orders of magnitude. While perhaps somewhat narrower in relation to the true scene-referred HDR, EDR nonetheless represents a wide DR breadth and sometimes may also be referred to as HDR. [0031] In practice, images comprise one or more color components (e.g., luma Y and chroma Cb and Cr) of a color space, where each color component is represented with a precision of n-bits per pixel (e.g., n=8). Using non-linear luminance coding (e.g., gamma encoding), images where n ≤ 8 (e.g., 24-bit color JPEG images) are considered images of standard dynamic range (SDR), while images where n > 8 may be considered images of EDR. [0032] Some approaches to encoding 360-degree videos rely on a geometric transform configured to map a full sphere onto a rectangle and then use a conventional video codec for compression of the resulting rectangular image frame(s). To support an enhanced viewing experience, the 8K or 16K resolution of the remapped rectangular image is typically desired. However, this kind of high resolution utilizes a relatively high bandwidth (> 100Mbps) to provide the expected video quality and, oftentimes, is associated with playback jitter. Some embodiments of a tile-based solution disclosed herein beneficially address these and some other related problems in the state of the art by implementing the following general approach: Since the end viewer does not typically view the whole 360-degree image frame at the same time and only watches, at any given time, a subset of pixels of the 360-degree image that are inside the viewport, the bandwidth usage is reduced by streaming only a part of the 360- degree video, e.g., the pixels inside and around the viewports. The viewport location information is fed back to the server (encoder) side. In some examples, based on this feedback, the server operates to adjust which part of the 360-degree video to transmit at a high bitrate. In some cases, the rest of the pixels are encoded at a relatively low bit rate, e.g., to handle situations in which the end-viewer suddenly changes the viewport, which otherwise may cause a partial blackout in the end-viewer’s field of view. [0033] In some examples, the 360-degree HDR video provides a wide Field of View (FOV) and exhibits greatly varying dynamic range in different spatial portions of the corresponding 360-degree image(s). Applying one set of global reshaping functions to the entire 360-degree HDR video, which typically causes each tile to be encoded with the same settings, does not provide an optimal way of addressing the local region’s needs. Hence, in some examples, application of the Tensor-Product B-Spline with Coordinate (TPBC) to the entire image is used for local adaptation. Although the TPBC can provide good reconstruction HDR quality and smooth transitions from one local area to another, incorporation of the TPBC processing into the codec pipeline triggers significant modifications to the encoder, metadata bitstream, and decoder. Accordingly, some embodiments disclosed herein, rely on a suitable existing codec ecosystem (such as, for example, Dolby Vision Profile 5) with targeted modifications/additions specifically directed at handling the 360-degree HDR video content. In such embodiments, tile-based encoding is applied, wherein each tile is pre-processed individually using an existing video codec (such as the above-mentioned Dolby Vision Profile 5). Then, a disclosed fusion process is deployed to smooth the transitions across the tile boundaries. Example Video/Image Delivery Pipeline [0034] FIG.1 is a block diagram illustrating an example process of a video/image delivery pipeline (100) and showing various stages from video/image capture to video/image- content display according to an embodiment. A sequence of video/image frames (102) may be captured or generated using an image-generation block (105). The frames (102) may be digitally captured (e.g., by a digital camera) or generated by a computer (e.g., using computer animation) to provide video and/or image data (107). Alternatively, the frames (102) may be captured on film by a film camera. Then, the film may be translated into a digital format to provide the video/image data (107). In some examples, the image-generation block (105) includes generating a 360-degree HDR video. [0035] In a production phase (110), the data (107) may be edited to provide a video/image production stream (112). The data of the video/image production stream (112) may be provided to a processor (or one or more processors, such as a central processing unit, CPU) at a post-production block (115) for post-production editing. The post-production editing of the block (115) may include, e.g., 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 part of post- production editing is sometimes referred to as “color timing” or “color grading.” Other editing (e.g., scene selection and sequencing, image cropping, addition of computer- generated visual special effects, removal of artifacts, etc.) may be performed at the block (115) to yield a “final” version (117) of the production for distribution. During the post- production editing (115), video and/or images may be viewed on a reference display (125). [0036] Following the post-production (115), the data of the final version (117) may be delivered to a coding block (120) for being further delivered downstream to decoding and playback devices, such as television sets, set-top boxes, flat or curved displays, personal computers, mobile devices, head-mounted displays, and the like. In some embodiments, the coding block (120) may include audio and video encoders, such as those defined by the ATSC, DVB, DVD, Blu-Ray, and other delivery formats, to generate a coded bitstream (122). After transmission through a delivery or distribution channel, the coded bitstream (122) is decoded in a decoding block (130) to generate a corresponding decoded signal (132) representing a copy or a close approximation of the signal (117). The decoding block (130) is communicatively connected to a target display (140) that may have somewhat or completely different characteristics than the reference display (125). In such cases, a display management (DM) block (135) may be used to map the decoded signal (132) to the characteristics of the target display (140) by generating a display-mapped signal (137). Depending on the embodiment, the decoding unit (130) and display management block (135) may include individual processors or may be based on a single integrated processing unit. [0037] A codec used in the coding block (120) and/or the decoding block (130) enables video/image data processing and compression/decompression. The compression is used in the coding block (120) to make the corresponding file(s) or stream(s) smaller. The decoding process carried out by the decoding block (130) typically includes decompressing the received video/image data file(s) or streams(s) into a form usable for playback and/or further editing. Example coding/decoding operations that can be used in the coding block (120) and the decoding unit (130) according to various embodiments are described in more details below. Tile-based 360-degree HDR Encoder [0038] FIG.2 is a block diagram illustrating a 360-degree HDR video encoder (200) according to an embodiment. Hardware of the encoder (200) includes an electronic processor (280) and a memory (270) operatively coupled to each other. The electronic processor (280) and the memory (270) enable various modules of the encoder (200) to perform various coding operations described herein below. An example input to the encoder (200) includes a 360-degree HDR/WCG image or sequence of images (202). The encoder (200) processes the image(s) (202) to generate a plurality of tile-metadata bitstreams (240n), a plurality of tile- image bitstreams (250_n), and a global metadata bitstream (260), where n=0, 1, 2, …, (N−1) and N is the total number of tiles in an individual image (202). In some examples, the encoder (200) is used in the coding block (120) of the pipeline (100). The image(s) (202) are a part of the stream (117). At least some of the tile-metadata bitstreams (240n), tile-image bitstreams (250n), and global metadata bitstream (260) are parts of the coded bitstream (122). [0039] In an example embodiment, the encoder (200) includes a tile partition module (210), a global metadata generator (220), and a tile bitstream generator (230). The tile bitstream generator (230) operates to process individual tiles defined by the tile partition module (210). For an n-th tile, operations performed by the tile bitstream generator (230) include tile padding and construction (232_n) and tile encoding (236_n). The output of the tile bitstream generator (230) includes the tile-metadata bitstreams (240n) and tile-image bitstreams (250n). The output of the global metadata generator (220) includes the global metadata bitstream (260). [0040] The tile partition module (210) operates to determine tile boundaries and the number N. In various examples, the tile partition module (210) operates to define uniform tiles or non-uniform tiles for the received image (202). Partitioning of the received image (202) into tiles can be done in one or more dimensions (e.g., horizontal and/or vertical dimensions). Hierarchical partitioning methods, such as the quad-tree partition, are typically not used for implementing operations of the tile partition module (210). [0041] In some examples, the tile partition module (210) is programmed to make tile boundary decisions by algorithmically considering some or all the following factors: (i) Banding alleviation ability in each local region (based on content). For example, each tile holding different respective tile content can be defined to be amenable to a different suitable reshaping function so that the banding risk can be reduced, and the color can be better preserved regionally. (ii) Coding efficiency for each tile (based on content). For example, a 360-degree video may have a very wide FOV, and various parts of the FOV may contain different respective views/local contents, all in the same image (202). As a result, the coding complexity may vary greatly among different local regions. Different partitions into tiles typically prompt different respective bitrates for different individual tiles, thereby resulting in various total bitrates of the final packaged bitstream for different tile partitions. (iii) Common viewport selection (from the viewer). For example, some viewpoints are more popular than others. As such, it may be beneficial to assign a higher bitrate for the tiles corresponding to more-popular viewpoints. On the other hand, some viewpoints are rarely selected by the viewers. As such, visual attention statistics can be applied in the tile partition module (210) as a factor in the determination of the tile boundaries. (iv) Bandwidth constraints. For example, the above examples illustrate that the system performance can differ for different tile partitions of the same image (202). By considering the bandwidth constraint of the channel through which the coded bitstream (122) is transmitted, tile partition decisions made in the tile partition module (210) can be steered toward staying within the available capacity (bandwidth) of the communication channel. [0042] In some examples, the tile-padding and construction operations (232_n) are configured to reduce artifacts at playback. Toward this end, the tile-padding and construction operations (232_n) are designed by taking into consideration some or all the following factors: (i) The viewport can change over time. Since the viewport typically contains only several tiles, there is typically no need for decoding all tiles. Using High Efficiency Video Coding (HEVC) as an example, the in-loop filter (e.g., sample adaptive offset, SAO, and deblocking) operation is disabled in some examples to enable independent decoding of each tile in the decoding block (130). Blocking artifacts might occur along the tile boundaries. As such, additional encoder constraints are implemented, due to which pixels in one tile do not rely on pixels of other tiles in the reference picture for motion compensation. (ii) With independent video encoding, different encoding modes along the tile boundaries in the corresponding coding units in neighboring tiles may be applied, which may cause some perceptual discontinuity. (iii) In some examples (e.g., with the above-mentioned Dolby Vision Profile 5), each tile has its own reshaping function and experiences different respective quantization and de-quantization effects. (iv) Each tile may have several versions of bitstreams encoded using different bitrates. The finally selected tiles may have different bitrates, which occurs more often for the tiles located along the viewport boundaries (e.g., see FIG.4). As a result, compression artifacts may appear inconsistently along those boundaries. A more detailed description of the bitrate and tile selection features corresponding to this particular factor is provided below in the packager subsection. In some examples, to address at least some of the above-indicated issues, the encoder (200) is configured to encode a bigger tile, which includes overlap regions belonging one or more neighboring tiles. In other words, the encoder (200) is programmed to expand nonoverlapping tiles by including some pixels of neighboring tiles into the expanded tiles, thereby causing such expanded tiles to have partial area overlaps. Herein, the term “neighboring” is used in the panoramic sense, in which the 360-degree image is continuous in the panning direction. For image-processing purposes, the panoramic view is typically “unfolded” into a planar picture shape, which has boundaries. For tiles in the middle portions of the planar picture shape, directly connected neighboring tiles are panoramically adjacent. For tiles near the boundary of the planar picture shape, there are no directly connected neighboring tiles, but there still exist neighboring tiles in the panoramic sense, i.e., panoramically adjacent tiles. For such tiles near the boundary of the planar picture shape, the encoder (200) is programmed to wrap the other side of the planar picture shape to identify and provide the panoramically adjacent tiles. Several nonlimiting examples of such wrapping are illustrated and described in reference to FIGS.10-17. A post-processing module configured to fuse panoramically adjacent overlapped expanded tiles is used at the decoder side, e.g., as described in more detail below. [0043] After tile partitioning in the module (210) and tile padding in the module (232n), the resulting individual padded tiles undergo tile encoding in the module (236_n). In some examples, the tile encoding is performed in the module (236n) using the aforementioned Dolby Vision Profile 5. In some other examples, other suitable encoding profiles are also used. In a representative example, the tile encoding module (236n) operates to generate a reshaped base layer (BL) for video compression and to output a single-channel reshaping function composer coefficients as metadata. For the n-th tile, these operations produce the tile-metadata bitstream (240n) and the tile-image bitstream (250n). In some examples, the tile bitstream generator (230) operates to generate multiple bitstreams (250n) using two or more different bitrates. Those multiple bitstreams (250n) are used to construct an output bitstream for the coded bitstream (122) by taking into account the viewport used in the decoding block (130). In such examples, the composer coefficients may remain the same even though the bitrates are different. [0044] The global metadata generator (220) operates to generate the global metadata bitstream (260) based on the received image (202). In various examples, the global metadata bitstream (260) includes common information for the entire image (202), e.g., information applicable to all tiles. The color space, brightness, HDR bit depth are examples of the common information for all tiles. Additionally, the global metadata bitstream (260) carries the tile partition definition, e.g., in the form of geometrically defined tile boundaries. Packager [0045] FIG.3 is a block diagram illustrating a packager module (300) according to an embodiment. In operation, the packager module (300) selects a subset of the bitstreams (240_n, 250_n, 260) generated by the encoder 200 for transmission to the decoding module (130). The selected subset of bitstreams is multiplexed by the packager module (300) into an output bitstream (310), which is transmitted via the coded bitstream (122). The selection is made by the packager module (300) based on a control signal (302). In some examples, the control signal (302) is generated based on the predicted viewport of the end viewer (at the decoder side) and the predicted/estimated condition of the channel through which the coded bitstream (122) is transmitted to the decoding block (130). In some examples, for each tile, the encoder (200) generates the tile-image bitstream (250n) to include two or more respective sub-streams, each encoding the same tile but at a different respective bitrate. In such examples, the selection operation performed by the packager module (300) includes selecting one of the two or more respective sub-streams and discarding the other(s). [0046] FIG.4 is a block diagram illustrating an example selection process implemented using the packager module (300) according to an embodiment. More specifically, FIG.4 illustrates a tile mosaic (400) having sixteen rectangular tiles (410i,j) arranged in four rows and four columns, where i and j are the row and column indices, respectively; i=1, 2, 3, 4; and j=1, 2, 3, 4. In the example shown, the tile mosaic (400) is encoded by the encoder (200) using two different bitrates, thereby causing each of the corresponding tile-image bitstreams (250_n) to include two respective sub-streams. A person of ordinary skill in the pertinent art will readily understand that the higher bitrate typically translates into a better image quality, whereas the lower bitrate typically translates into a poorer image quality. [0047] When the control signal (302) specifies to the packager module (300) an end- viewer viewport (420), the packager module (300) operates to select: (i) the respective higher-bitrate sub-stream for each of the tiles (410_i,j) overlapping with the viewport (420) and (ii) the respective lower-bitrate sub-stream for each of the tiles (410i,j) non-overlapping with the viewport (420). In the example shown, the respective higher-bitrate sub-streams are selected for the tiles (4102,2, 4102,3, 4103,2, 4103,3), and the respective lower-bitrate sub- streams are selected for the remaining tiles of the tile mosaic (400). As already indicated above, inclusion of the selected respective lower-bitrate sub-streams into the output bitstream (310) helps to avoid partial viewable image blackouts when the end-viewer suddenly changes (e.g., moves) the viewport (420). Tile-based 360-degree HDR Decoder [0048] FIG.5 is a block diagram illustrating a 360-degree HDR video decoder (500) according to an embodiment. Hardware of the decoder (500) includes an electronic processor (580) and a memory (570) operatively coupled to each other. The electronic processor (580) and the memory (570) enable various modules of the decoder (500) to perform various decoding operations described herein below. An example input to the decoder (500) includes the bitstream (310) received from the packager (300). The decoder (500) processes the bitstream (310) to generate a reconstructed 360-degree HDR/WCG image or sequence of images (502). In some examples, the decoder (500) is used in the decoding block (130) of the pipeline (100). In such examples, the image(s) (502) form a part of the decoded signal (132). [0049] In an example embodiment, the decoder (500) includes a bitstream demultiplexing module (510). In operation, the bitstream demultiplexing module (510) demultiplexes the received bitstream (310) into the corresponding constituent bitstreams, including the global metadata bitstream (260), a plurality of tile-metadata bitstreams (540_n), and a plurality of tile- image bitstreams (550n). In some examples, the tile-metadata bitstreams (540n) and the tile- image bitstreams (550n) differ from the corresponding tile-metadata bitstreams (240n) and the corresponding tile-image bitstreams (250_n) shown in FIG.2 due to the above-described operations of the packager (300). [0050] The decoder (500) also includes a tile bitstream decoder (530) and a tile postprocessing module (560). Both the tile bitstream decoder (530) and the tile postprocessing module (560) receive a control signal (558) specifying the position of the viewport (420) within the corresponding image (202). The tile postprocessing module (560) also receives the global metadata bitstream (260) from the bitstream demultiplexing module (510). For each tile overlapping with the viewport (420), the tile bitstream decoder (530) performs tile decoding operations (524) based on the respective tile-metadata bitstream (540_n) and the respective tile-image bitstream (550_n). The resulting decoded tiles (528_n) are applied to the tile postprocessing module (560). Various operations performed in the tile postprocessing module (560) are described in more detail below. The output of the tile postprocessing module (560) is the reconstructed image or sequence of images (502). [0051] One function of the tile postprocessing module (560) is to assemble the decoded tiles (528n) into a corresponding larger viewable image. When the decoded tiles (528n) are assembled together without postprocessing, the tile boundaries typically exhibit discontinuity artifacts. Some of the postprocessing operations performed by the tile postprocessing module (560) are thus directed at attenuating or removing such boundary discontinuity artifacts. In some examples, the artifact attenuation/removal is performed via tile fusion operations that use information from neighboring tiles to create a smooth (e.g., substantially artifact free) transitions between tiles. Various examples of the tile fusion operations are described in more detail below. [0052] Various example embodiments implement two different approaches to generating the decoded tiles (528_n) before applying the reference picture unit (RPU) for backward reshaping. A first approach is referred to as “individual decoding.” A second approach is referred to as “assembling tiles to a conforming bitstream.” The choice of a specific one of the two approaches typically depends on the profile/level limitations of the HEVC decoder and/or other computation related factors. [0053] In various examples, the individual decoding approach relies on decoding each pair of the tile bitstreams (540_n, 550_n) individually. Under this approach, each tile (528_n) is reconstructed back to the pixel domain via individual HEVC decoding performed with the tile decoding operations (524). The reconstructed pixels are passed to a suitable (e.g., Dolby Vision) composer to generate the corresponding HDR image using the composer part of the metadata (540n). Then, the HDR images are assembled into a larger HDR picture according to the metadata (260) in the tile postprocessing module (560). The latter process flow typically relies on multiple HEVC decoder instances, but each of such HEVC decoder instances has a relatively low processing limit. [0054] In various examples, the assembling tiles to a conforming bitstream approach relies on assembling the multiple tile bitstreams (540_n, 550_n) into one HEVC-conforming bitstream and then feeding that bitstream into an HEVC decoder to decode all tiles together within the tile decoding operations (524). The assembly of the multiple tile bitstreams (540_n, 550n) to one HEVC conforming bitstream is performed within the tile decoding operations (524) by a light transcoder or high-level syntax (HLS) rewriter, with reference to applicable (e.g., Dolby Vision) metadata. After the decoding, the light transcoder has the reconstructed pixels for each tile. The tile decoding operations (524) then proceed to extract each tile out and apply the tile composing operations using each tile’s composer coefficients. For each of the transmitted tiles, the tile composing operations generate a corresponding HDR tile. The tile decoding operations (524) then proceed to assemble the plurality of HDR tiles into a larger picture according to the applicable metadata, e.g., as indicated in FIG.6. This larger picture is then subjected to the tiling postprocessing in the tile postprocessing module (560). This process flow relies on one HEVC decoder, but with a relatively high processing limit. [0055] FIG.6 is a block diagram illustrating bitstream assembler operations (600) according to an embodiment. The bitstream assembler operations (600) form a part of the tile decoding operations (524). An example input to the bitstream assembler operations (600) includes a plurality of bitstreams (BS0, BS1, …, BSM). Each bitstream BSm (m=0, 1, …, M) includes a respective video parameter set (VPS_m), a respective sequence parameter set (SPSm), and a picture parameter set (PPSm). Each bitstream BSm further includes a respective sequence of segments (POC_k), where k=0, 1, …, K. Herein, the label “POC_k” is derived from the acronym POC, which stands for “Picture Order Counter.” In the example shown, a segment (POCk) in the bitstream (BSm) represents a single slice and includes a respective segment header (SHmk) and a respective block of segment data (SDmk). In other examples, the segment (POCk) in the bitstream (BSm) can represent more than one slice. [0056] In an example embodiment, the bitstream assembler operations (600) include applying the same tools/settings to all tiles corresponding to the image sequence (202) to facilitate the generation of a video parameter set (VPS), a sequence parameter set (SPS), and a picture parameter set (PPS) for an assembled bitstream (602). In some examples, the bitstream assembler operations (600) do not include parsing all sets {VPS_m, SPS_m, PPS_m} to generate the sets {VPS, SPS, PPS} assembled bitstream (602). Rather, the bitstream assembler operations (600) include taking the set {VPS, SPS, PPS} from the first tile and updating the pertinent syntax related to other tiles. The assembled bitstream (602) further includes a respective sequence of segments (POCk), wherein each segment (POCk) is a concatenation of the corresponding segments (POC_k) from the bitstreams (BS₀, BS₁, …, BSM). [0057] FIGS.7A-7D show example pseudocodes that can be used to implement some of the bitstream assembler operations (600) according to an embodiment. More specifically, FIG.7A shows a pseudocode (702) for assembling the parameters set (SPS) of the assembled bitstream (602). FIG.7B shows a pseudocode (704) for assembling the parameters set (PPS) of the assembled bitstream (602). FIG.7C shows a pseudocode (706) for a supplemental enhancement information (SEI) message directed at generating a Temporal Motion Constrained Tile Set (MCTS). FIG.7D shows a pseudocode (708) illustrating an example syntax of the slice header (SHmk). [0058] Referring to FIG.7A, the pseudocode (702) primarily deals with updating the variables pic_width_in_luma_samples and pic_height_in_luma_samples. The italicized portions of the pseudocode (702) show the corresponding added HLS syntax. [0059] Referring to FIG.7B, the pseudocode (704) is designed such that the bitstream assembler operations (600) are constrained to one tile in one slice. As a result, the total number of tiles equals the total number of slices. The italicized portions of the pseudocode (704) show the corresponding added HLS syntax. In a typical example, the pseudocode (704) also relies on the following settings: dependent_slice_segments_enabled_flag: 0 tiles_enabled_flag: 1 entropy_coding_sync_enabled_flag: 0 //*Main or Main 10 profile constraint loop_filter_across_tiles_enabled_flag: 0 //*do not allow loopfilter across tiles boundaries pps_loop_filter_across_slices_enabled_flag: 0 //*do now allow loopfilter across slice boundaries In some examples, the pseudocode (704) also needs to set num_tile_columns_minus1, num_tile_rows_minus1, uniform_spacing_flag, and whel uniform_spacing_flag==0, the detailed tile partition information. [0060] Referring to FIG.7C, the pseudocode (706) is configured to “tell” the HEVC decoder that the corresponding bitstream (602) has no drift issues. In a typical example, the pseudocode (706) also relies on the following settings: mc_all_tiles_exact_sample_value_match_flag: 1 each_tile_one_tile_set_flag: 1 These settings inform the HEVC decoder that the following encoder constraint is applied to all tiles at the encoder: pixels in one tile do not use reconstructed pixels in other tiles in reference pictures for motion compensation. [0061] Referring to FIG.7D, the pseudocode (708) is configured to support tile assembly at the decoder (500). As such, the pseudocode (708) provides a suitable syntax for slice_segment_header(). The corresponding portions of the pseudocode (708) are italicized in FIG.7D. [0062] FIG.8 is a block diagram that pictorially illustrates a tiled image frame (800) according to an embodiment. The total number of tiles (nTiles) in the tiled image frame (800) is nTiles = rTiles×cTiles, where rTiles is the number of tile rows, and cTiles is the number of tile columns in the tiled image frame (800). In the example shown, the tiles are geometrically identical. In other examples, tiles having varied geometric shapes can also be used. [0063] FIGS.9A-9B show a flowchart of a bitstream assembling method (900) that can be used to implement some of the bitstream assembler operations (600) according to an embodiment. For illustration purposes and without any implied limitations, the bitstream assembling method (900) is described below in reference to the tiled image frame (800). [0064] A processing block (902) of the bitstream assembling method (900) includes parsing the input bitstreams (540n) and creating VPS and SPS templates for the output bitstream (602). A processing block (904) includes (i) determining the number of tile rows (rTiles) and the number of tile columns (cTiles) (also see FIG.8), and (ii) computing the total number of tiles (nTiles) as nTiles = rTiles×cTiles. In some examples, the total number of tiles nTiles is equal to the number M of input bistreams (BS_m). A processing block (906) includes updating the SPS for the new assembled picture size using the following operations: a. pic_width_in_luma_samples = sum(pic_width_in_luma_samples[i]), where i=0… cTiles−1; and b. pic_height_in_luma_samples = sum(pic_height_in_luma_samples[j]), where j=0… rTiles−1. [0065] A processing block (908) of the bitstream assembling method (900) includes (i) using the PPS from the first bitstream (BS0), and (ii) modifying the PPS tile-related syntax for other PPS instances. Example syntax modifications are as follows: c. dependent_slice_segments_enabled_flag = 0; d. tiles_enabled_flag = 1; e. num_tile_columns_minus1 = cTiles−1; f. num_tile_rows_minus1 = rTiles–1; g. loop_filter_across_tiles_enabled_flag = 0; h. entropy_coding_sync_enabled_flag = 0. [0066] An optional processing block (910) of the bitstream assembling method (900) includes updating other high level syntax, such as profile, tier, and level syntax, bit_rate_pic_rate_info syntax, etc. Processing blocks (912)-(926) are configured to implement a processing loop that causes operations of the processing blocks (918, 920, 924) to be applied to different segments (POCk) and different bitstreams (BSm). An instance of the processing block (918) includes updating the slice segment header, e.g., using the syntax indicated in FIG.9B. In some loops, when the slice header update is not needed, operations of the processing block (918) are omitted. Multiple instances of the processing block (920) produce concatenations of slice_segment_header() and slice_segment_data() from each input bitstream for the current POC, e.g., using the syntax indicated in FIG.9B. An instance of the processing block (924) includes check byte alignment and updating rbsp_slice_segment_trailing_bits() when needed. Upon completion of the processing loop (912)-(926), operations of the bitstream assembling method (900) are terminated. Tile Partition [0067] In various examples, tile partitioning is performed either in a uniform way or a non-uniform way in two dimensions. Some examples of tile-partitioning algorithms are disclosed in U.S. Patent Nos.10,032,262 and US10,223,774, both of which are incorporated herein by reference in their entirety. In this subsection, the BLKSTD tile-partitioning algorithm is presented first. Then, applications of the BLKSTD tile-partitioning algorithm to uniform and non-uniform tile partitioning are described. Different implementations of the BLKSTD tile-partitioning algorithm, as well as other suitable algorithms, can be used in various embodiments. [0068] Let us denote the bit depth in the input image as ^^{^}and the bit depth in the base layer is ^^{^}. It can be noted that the number of codewords needed to avoid the banding artifact is a function of the block-based standard deviation (BLKSTD). Since an image contains multiple luminance ranges (e.g., ^ different ranges), the BLKSTD values can be measured in each luminance range. For example, in each luminance range, one can collect the pixels whose values fall into this considered range and compute the BLKSTD for each pixel and take the average of the collected BLKSTD. Note that for a video, the considered pixels need to be collected across multiple frames within the considered scene. [0069] Let us denote the original 360-degree picture ^^{^} and its height and width as ^ and ^, respectively. First, the 360-degree HDR image is partitioned into multiple small uniform patches. Let us denote this type of patch as ^_^^. The width and height (before any padding) of tile ^_^^ are ^_^ ^{^} _^ and ^_^ ^{^} _^ , respectively. The number of patches in each dimension is represented as ^_^ ^{^} and ^_^ ^{^}. The patch size is smaller than the tile size since the algorithm will collect together in a tile. [0070] In the patch ^_^^, the corresponding BLKSTD can be measured in each luminance bin, l, as ^_^^(^), and one can collect L values as one single vector denoted as ^_^^, which has dimension ^ × 1. The algorithm’s goal is to group those patches together to construct the partition boundaries for a bigger tile such that the patches within a tile have similar BLKSTD statistics to enable the constructed reshaping function to utilize the codewords, avoid banding, and preserve color in a more efficient way. By doing so, one can explore the local diversity of both the HDR reshaping in the luminance domain and the tile structure in the spatial domain to achieve better R-D and HDR/WCG parameters. [0071] In the uniform tile partition scenario, there are two sub-scenarios to consider. The first scenario includes the pre-defined number of tile partitions in both horizontal and vertical directions. In this case, the tile partition is straightforward and does not involve optimization procedures. The other scenario includes the number of tile partitions as a design parameter, but the tile partition in this case is uniform. There is a limited number of combinations in this case. Let us denote the set of candidate tile width as {^₍ ^{^} ^₎ }. The total number of options is |{^₍ ^{^} ^₎ }|. For each tile width, the number of tiles dimension is ^₍ ^{^} ^₎ ^{,^}and the indices for a patch in the tile m form a set ^₍ ^{^} ^^, )^{^} ,_^ . Similarly, the candidate tile height as {^₍ ^{^} ^₎ }, and the corresponding total options is |{^₍ ^{^} ^₎ }|. For each tile height, the number of tiles in the vertical dimension _^ ^, )^{^}, and for a patch in tile m form a (^{^} ^^, set ^ ^{^} )_,^ . Preferably, the BLKSTD values need to satisfy ^_^^ ≈ ^_^^^^ when patches ( , !) and ( ^{^}, !′) are in the same tile. If there is no such constraint, then the tile will have the same dimension as the patch, i.e., the tile will contain only one patch. [0073] One can accumulate the (vector) BLKSTD along each dimension as follows: ^^# _^ = ∑_& ^_&^ (1) ^^{^} _^ = ∑_& ^_^& (2) Let us define the distortion measurement between two vectors as '(^_^, ^_^^) = ∑^* -_. ⁺ /^, |^_^(^) − ^_^ ⁾(^)| (3) symmetric matrix 0^# whose (i, j)^th element is '(^^# &, ^₁ ^#). Such a matrix is expressed as follows: é^{'(^# # #} ^{/, ^/). ⋯ '(^79,:} ^{(8) +, , ^#} ^{/). ù} (_^) , boundary, and also knows which patches are in the m such, one can co ^# mpute the max '(^_&, ^₁) within the patch ^₍ ^{^} ^^, )^{^} ,_^ as '_^ ^{^@A} in each tile. '_^ |∀F, G ∈ ^_(^),^ } (5) Let us denote a maximal the distortion as E. If all tiles’ '_^ ^{^@A} are no larger than E, then we will claim this tile horizontal partition is valid. I₍ ^{^} ^₎ = ∏_^ ('_^ ^{^@A} ≤ L) (6) In valid tile horizontal partition options, we choose the maximal tile size to a highest video compression efficiency. M^{^,NOP} = arg ma ^{^ ^} ^x {^_(^) |I_(^) = 1} (7) The vertical partition can be done in a similar way to obtain a 2D symmetric matrix 0^{^} whose (i, j)^th element is '(^^{^} & , ^₁ ^{^}). Then, we construct the valid vertical partition options and select the option with tile size. [0075] For the non-uniform partition scenario, we can follow a method similar to that used in the uniform partition scenario (e.g., as outlined above) to compute the 2D symmetric matrix 0^#. In on example, we can use the region grow method with a maximal tolerance level for the distortion as E. [0076] As a first use case, we consider an example with no limit on the number of tiles we can partition. For the horizontal direction, we will start from the first two patches, compute max '(^^# /, ^_, ^#) as '_/ ^{^} :_, ^@A. If '_/ ^{^} :_, ^@A ≤ L, then we will include the next patch and compute max '(^^# the latter value with the threshold again. We until we have patches 0 to u and the '^{^@A} > L. Then, we _/:U will assign the patches 0 to u-1 to the first title and start the new tile from patch u. The tile will end when '_U ^{^} _:^ ^@A > L, and this tile will contain the patches u to v-1. We repeat the above- outlined to find all tile boundaries. [0077] Let us denote the set of collection for patch index for the m^th tile as ^_^ ^{^}. The initial value for each set is an empty set. In one example, the following pseudocode is used to implement the above-outlined partition process: Initialization

m = m + 1 end of pseudocode. [0078] When there is a constraint on the number of tile partitions, one can perform the above-described algorithm by changing the threshold E and find a satisfying partition iteratively. Tile Padding and Tile Fusion [0079] This section describes examples of how to pad each tile at the encoder (200) and how to fuse tiles at the decoder (500) to reduce the tile boundary artifacts. There are several 360-degree formats that can be used for these purposes, such as the Equi-Rectangular Projection (ERP) and the Cube-Map Projection (CMP). For illustration purposes, the padding and fusion processes are described in more detail for the ERP format. The CMP format is discussed at a somewhat higher level. From the provided description, a person of ordinary skill in the pertinent art will readily understand how to use both ERP and CMP formats without any undue experimentation. Tile Padding for ERP Format [0080] Let us denote the original 360-degree picture as ^^{^} and its height and width as ^ and ^, respectively. We have ^_# tiles in the horizontal direction and ^_^ tiles in the vertical direction. In total, we have ^_# ∙ ^_^ titles. Let ( , !) be the 2D partition index for a tile as the m^th tile horizontally and the n^th tile vertically, where 0 ≤ ≤ ^_# − 1 and 0 ≤ ! ≤ ^_^ − 1. Let us denote the corresponding tile as ]_^^. The width and height (before any padding) of the tile ^^{^} _^^ are ^_^ ^{^} _^ and ^_^ ^{^} _^ , respectively. FIG.4 illustrates an example of a 4×4 tile partition with equally sized tiles (410mn). In other examples, tile partitions can be non- uniform horizontally and/or vertically. Even under the uniform partition, the tiles near the picture boundaries may be smaller than the interior tiles, e.g., owing to a non-integer factor of the tile-to-picture size scaling along each image dimension. [0081] FIGS.10-12 are block diagrams illustrating padding operations according to an embodiment. More specifically, FIG.10 illustrates picture boundaries padding. FIGS.11-12 illustrate tile boundaries padding. [0082] Referring to FIG.10, in the case of ERP, the top row and the bottom row are reduced to the north and south poles, respectively. Each pole is represented by a single point, and the poles do not connect to each other. As such, the picture’s top and bottom do not typically need to be padded. However, a left picture boundary (1002) and a right picture boundary (1004) are panoramically adjacent in an original 360-degree image (1010) and are parts of the corresponding 360-degree panorama upon being properly connected. If the boundaries (1002, 1004) are not appropriately padded and processed, then the end user will observe an artifact near those boundaries when the viewport is positioned over them. To reduce or eliminate this type of artifacts, the left and right picture boundaries (1002, 1004) are padded as illustrated in FIG.10. More specifically, a copy of a left patch (1012) located at the left picture boundary (1002) is added to the right of the right picture boundary (1004). Similarly, a copy of a right patch (1014) located at the right picture boundary (1004) is added to the left of the left picture boundary (1002). These copy additions are indicated in FIG.10 by the dashed arrows (1022, 1024). [0083] Let us denote the length (in terms of pixels) of the padded area as ^_O. We pad the left picture boundary with a copy of the ^_O × ^ patch (1014). We also pad the right picture boundary with a copy of the ^_O × ^ patch (1012). Let us denote a resulting padded 360- degree picture (1020) as ^^_. We define ^^_ = ^ + 2^_O and ^^_ = ^. Then ^^_ has the dimensions ^^_ × ^^_. [0084] After obtaining the padded 360-degree picture (1020) as illustrated in FIG.10, we can start extracting therefrom various tiles and padding those tiles. FIG.11 schematically illustrates those operations for an edge tile (1102). The boundaries of the resulting padded tile are indicated in FIG.11 by the dashed line (1104). FIG.12 schematically illustrates those operations for an inner tile (1202). The boundaries of the resulting padded tile are indicated in FIG.12 by the dashed line (1204). The description below uses the ^^_ coordinates, which correspond to the padded 360-degree picture (1020). This description is applicable to the tiles (1102, 1202) as well as to any other tiles of the padded 360-degree picture (1020). [0085] The ( , !) tile will be extracted out from ^^_. To facilitate the discussion, we define the accumulated width and height from the top/left tile as follows: ^_^ ^b _^ = ∑^{^} &_. ⁺ /^, ^_& ^{^} ^ ∀ > 0 (8) ^_^ ^b _^ = ^_^ ^{^} ∀! > 0 coordinate for the top-left corner (c_^ ^d* _^ , e_^ ^d* _^ ) of as: = ^ − by (c_^ ^d* _^ , e_^ ^d* _^ ) and (c_^ ^fg _^ , e_^ ^fg _^) as a new : ^_^ ^_ _^ = c_^ ^fg _^ − c_^ ^d* _^ + 1 (13) channel as well, e.g., with the 4:2:0 format. The overlap length in such cases will be one half, i.e., ^_O/2. Tile Fusion for ERP Format [0086] This subsection describes example tile-fusion operations performed in the decoder (500) according to some embodiments. Those operations include two blocks of operations: (i) operations directed at computing the weighting factor matrix per pixel and (ii) operations directed at performing the actual tile fusion. [0087] In some examples, for each padded tile, ^^_ _^^ , the decoder (500) operates to construct the weighting factor matrix, i^_ _^^ , with the same dimension. Since a tile may be padded differently on four boundaries (e.g., see examples shown in FIGS.11-12), to handle those different combinations, we first build a template for weighting factor matrix as i^d _^^ with dimension ^_^ ^d _^ × ^_^ ^d _^ ^_^ ^d _^ = ^_^ ^{^} _^ + 2^_O (15) to 1, as we don not have other titles to fuse therein. Thus, the final values will be from the tile itself: i^d _^^ j^_O: ^_O + ^_^ ^{^} _^ − 1, ^_O: ^_O + ^_^ ^{^} _^ − 1k = 1 (17) The weights at the left boundary of the tile are expressed as i^d _^^ ⁽c, e⁾ = ^{^ln} ^{m +A ^ d} T_*op, , ∀c ∈ ^q^_^^ , ^_^^ ^r, ∀e ∈ s^_O, ^_^ ^d _^ − ^_O − 1t (18) of the tile n i^d _^^ (c, e) = ^{^lm +A} T_*op, , ∀c ∈ q^_^ ^{^} _^ , ^_^ ^d _^ r, ∀e ∈ _s^_O, ^_^ ^d _^ − ^_O − 1_t (19) of the tile are as i^d _^^ (c, e) = ^up, T_*op, , ∀c ∈ s^_O, ^_^ ^d _^ − ^_O − 1t, ∀e ∈ s0,2^_O − 1t (20) of the tile are as i^d _^^ ⁽c, e⁾ = ^{^ln} ^{m +u} T_*op, , ∀c ∈ s^_O, ^_^ ^d _^ − ^_O − 1t, ∀e ∈ ^q^_^ ^{^} _^ , ^_^ ^d _^ ^r (21) the weights are computed using the following expressions: i^d _^^ (c, e) = ^Ap, T_*op, ∙ ^up, T_*op, , ∀c ∈ s0,2^_O − 1t, ∀e ∈ s0,2^_O − 1t (22) corner, and bottom-right corner, respectively. Using the template i^d _^^ defined with Eqs. (15)-(25), the decoder (500) operates to extract the weights matrix i^_ _^^ corresponding to tile ^^_ _^^ as follows: i^_ _{^^ = v} ^{i d} ^{^^ (0: ^_} ^{^^ − 1, 0: ^_} ^{^^ − 1) FI ! = 0} [0088] In some examples, the block of tile fusion operations includes setting up two all- zero matrices, ^^b and i^b, with dimensions (^ + 2^_O) × (^). When the decoder (500) receives one tile, ^^_ _^^ , the decoder (500) operates to compute the weighting matrix, i^_ _^^ , and perform the following operations: ^^b(c_^ ^d* _^ : c_^ ^fg _^ , e_^ ^d* _^ : e_^ ^fg _^ ⁾ = ^^b(c_^ ^d* _^ : c_^ ^fg _^ , e_^ ^d* _^ : e_^ ^fg _^ ⁾ + ^^_ _^^ ⊙ i^_ _^^ (27) i^b(c_^ ^d* _^ : c_^ ^fg _^ , e_^ ^d* _^ : e_^ ^fg _^ ⁾ = i^b(c_^ ^d* _^ : c_^ ^fg _^ , e_^ ^d* _^ : e_^ ^fg _^ ⁾ + i^_ _^^ (28) where ⊙ is an element-wise multiplication within the two matrices. [0089] Recall that the left and right picture boundaries are padded with the stripes (1014, 1012) as illustrated in FIG.10. Those stripes (1014, 1012) are also fused by the decoder (500): ^^bj^_O: 2^_O − 1, : k = ^^bj^_O: 2^_O − 1, : k + ^^bj^ + ^_O: ^ + 2^_O − 1, : k (29) ^ ^ = where ⊘ is the element-wise division within the two matrices. The final ERP image, ^^g, is then extracted by the decoder (500) from ^^z as follows: ^^g = ^^z(^_O: ^ + ^_O − 1, : ) (34) [0090] This subsection describes the tile construction used with the CMP format according to some examples. Herein, approaches applied to the CMP format are similar to those described above for the ERP format, but with a modified way in which corner and edge tiles are handled. [0091] FIG.13 is a block diagram illustrating a layout (1300) representing an expanded CMP format according to one example. The layout (1300) contains six faces (1302-1312). Spatial orientations of the faces (1302-1312) in the 3D space can be visualized as being the six sides of a corresponding cube. For video compression, the faces (1302-1312) are typically rearranged to form a 2x3 rectangle, wherein there are two rows of three faces each, or rearranged to form a 3x2 rectangle, wherein there are three rows of two faces each. As shown in FIG.13, the CMP layout (1300) is a direct projection (i.e., prior to the rearrangement), wherein each of the faces (1302-1312) has a position obtained by unfolding the corresponding CMP cube into a flat shape. [0092] FIG.14 is a block diagram illustrating a tile partition of the CMP layout (1300) according to one example. In the example shown, each of the faces (1302-1312) is partitioned into four respective tiles (A-D). The shown tile partition is such that the various tiles (A-D) are horizontally and vertically aligned across the faces (1302-1312) in the CMP layout (1300). [0093] FIGS.15-17 are block diagrams illustrating tile padding in the CMP layout (1300) according to various examples. A general principle of the tile padding illustrated by FIGS. 15-17 is that the padded regions are taken from the panoramically adjacent neighbors in the 3D space. As a result, in some examples, some of the padded regions are taken from the panoramically adjacent tiles that have no direct contact with the padded tile in the CMP layout (1300), e.g., as illustrated in FIGS.16-17. [0094] FIG.15 is a block diagram illustrating a first example of the tile padding in the CMP layout (1300), wherein the tile (1304A) is being padded. The strips added to the tile (1304A) are located in the tile’s direct neighbors in the CMP layout (1300). More specifically, two of the added strips are located in the tiles (1304B, 1304D) of the same face (1304). The other two of the added strips are located in the tiles (1302B, 1310D) of other faces (1302, 1310). [0095] FIG.16 is a block diagram illustrating a second example of the tile padding in the CMP layout (1300), wherein the tile (1306B) is being padded. Three of the strips added to the tile (1306B) are located in the tile’s direct neighbors in the CMP layout (1300). More specifically, two of those three strips are located in the tiles (1306A, 1306C) of the same face (1306). The third one of the strips is located in the tile (1308A) of a different face (1308). The fourth one of the strips added to the tile (1306B) is located in the tile (1310B) of another different face (1310). Note that the tiles (1308A, 1310B) are not in direct contact with one another in the CMP layout (1300). [0096] FIG.17 is a block diagram illustrating a second example of the tile padding in the CMP layout (1300), wherein the tile (1302A) is being padded. Two of the strips added to the tile (1302A) are located in the tile’s direct neighbors in the CMP layout (1300). More specifically, those two strips are located in the tiles (1302B, 1302D) of the same face (1302). The other two of the added strips are located in the tiles (1308B, 1310A) of other faces (1308, 1310). Note that the tiles (1308B, 1310A) are not in direct contact with the tile (1302A) in the CMP layout (1300). Transmitted Metadata [0097] This subsection describes the metadata transmitted from the encoder (200) to the decoder (500) to assist the video decoding and processing at the latter according to some examples. In the described examples, each tile in the 360-degree image is encoded in parallel. Based on view port selection by the user, the corresponding tiles can either be decoded independently or assembled into one HEVC compatible bitstream based on the embodiments discussed above in reference to FIG.5. In various examples, two types of metadata, including global metadata and tile metadata, are transmitted. Both types of metadata are described in more detail below. [0098] For the global metadata bitstream (260), the encoder (200) operates to specify the information for all tiles of the corresponding one 360-degree image. In some examples, the following information is specified: • 360-degree projection type (e.g., ERP or CMP); and • tile information. One nonlimiting example of the global metadata is indicated in the following table. The corresponding syntax contains: (i) projection type; (ii) picture resolution; and (iii) tile partition information. global_metadata( ) { Descriptor } } g., described in Table 10 of ISO/IEC 23090-2:2019, Information technology -- Coded representation of immersive media -- Part 2: Omnidirectional MediA Format (OMAF), 2nd Edition, which is incorporated herein by reference in its entirety. For the picture resolution and tile-related information, the syntax is the same as that specified in the HEVC (H.265 and MPEG-H, Part 2). The list TileId[ ctbAddrTs ] for ctbAddrTs ranging from 0 to PicSizeInCtbsY − 1, inclusive, specifying the conversion from a CTB address in tile scan to a tile ID, is derived as (6-9) in section 6.5.1, CTB raster and tile scanning conversion process, of H.265. [0099] In some examples, each tile is enforced as a slice. An example conversion process can be implemented as follows: For a given tile, which is in the i-th tile column tile and j-th tile row, specified by tile (i, j), where i = 0… num_tile_columns_minus1, j = 0… num_tile_rows_minus1, the corresponding tile index tile_idx[i][j] tile_idx[i][j] = j* (num_tile_columns minus1+1) + i [00100] The location (x, y) of the top left luma sample of the tile (i, j) in the picture is specified by: • x = sum(colWidth[m])*CTB_width, where m=0… i-1 • y = sum(rowHeight[n])*CTB_height, where n=0… j-1 In HEVC, CTB_width = CTB_height = (1<< CtbLog2SizeY). [00101] For the tile metadata, the encoder (200) operates to specify, for each tile metadata bitstream (240n): • tile index; • padding size in tile boundaries; • composer coefficients. An example syntax is indicated in the following table: tile_metadata( ) { Descriptor tile_idx ue(v) tile left pad devide 2 ue(v) , _ _ , original picture with all tiles. From tile_idx, the decoder (500) can derive the tile location in the original picture. tile_left_pad_devide_2 times 2 specifies the width of the padding on the left side of the tile. tile_right_pad_devide_2 times 2 specifies the width of the padding on the right side of the tile. tile_top_pad_devide_2 times 2 specifies the height of the padding on the top side of the tile. tile_bottom_pad_devide_2 times 2 specifies the height of the padding on the bottom side of the tile. [00102] It is noted that, in some examples, the system can also be configured to use Omnidirectional video specific SEI messages to specify all syntaxes in the global metadata bitstream (260) and the padding syntax in each tile metadata bitstream (240n). Such messages are described, e.g., in VSEI: H.274: Versatile supplemental enhancement information (SEI) messages for coded video bitstreams. For example, an equirectangular projection SEI message specifies the projection_type is ERP; a generalized cubemap projection SEI message specifies the projection_type is cubemap. All tile information in the global metadata bitstream (260) and padding information in each tile metadata bitstream (240n) can be specified using a region-wise packing SEI message, for which one tile is treated as one region. [00103] According to an example embodiment disclosed above, e.g., in the summary section and/or in reference to any one or any combination of some or all of FIGs.1-17, provided is an apparatus for encoding a 360-degree image, the apparatus comprising: at least one processor; and at least one memory including program code, wherein the at least one memory and the program code are configured to, with the at least one processor, cause the apparatus at least to: partition the 360-degree image into a plurality of first tiles; pad each of the first tiles to generate a corresponding plurality of second tiles, the padding being configured to add to each of the first tiles respective panoramically adjacent regions from respective other ones of the first tiles; generate a plurality of tile-image bitstreams and a plurality of corresponding tile-metadata bitstreams by applying video encoding to at least a selected subset of the plurality of second tiles; and generate a global metadata bitstream corresponding to the 360-degree image. [00104] According to another example embodiment disclosed above, e.g., in the summary section and/or in reference to any one or any combination of some or all of FIGs.1-17, provided is a method of encoding a 360-degree image, the method comprising: partitioning, with an electronic encoder, the 360-degree image into a plurality of first tiles; padding, with the electronic encoder, each of the first tiles to generate a corresponding plurality of second tiles, the padding being configured to add to each of the first tiles respective panoramically adjacent regions from respective other ones of the first tiles; generating, with the electronic encoder, a plurality of tile-image bitstreams and a plurality of corresponding tile-metadata bitstreams by applying video encoding to at least a selected subset of the plurality of second tiles; and generating, with the electronic encoder, a global metadata bitstream corresponding to the 360-degree image. [00105] In some embodiments of the above method, the first tiles are nonoverlapping with one another. [00106] In some embodiments of any of the above methods, the plurality of tile-image bitstreams includes a first tile-image bitstream having a first bitrate and a second tile-image bitstream having a lower second bitrate. [00107] In some embodiments of any of the above methods, the method further comprises: receiving, with the electronic encoder, information specifying an end-viewer viewport for the 360-degree image; selecting, with the electronic encoder, the first tile-image bitstream for transmission to an electronic decoder when a corresponding one of the first tiles overlaps with the end-viewer viewport; and selecting, with the electronic encoder, the second tile- image bitstream for transmission to the electronic decoder when the corresponding one of the first tiles has no overlap with the end-viewer viewport. [00108] In some embodiments of any of the above methods, the global metadata bitstream carries first metadata specifying tile boundaries defined during the partitioning. [00109] In some embodiments of any of the above methods, the global metadata bitstream additionally carries second metadata applicable to all tiles of the corresponding plurality of second tiles. [00110] In some embodiments of any of the above methods, the partitioning is based on at least one of visual attention statistics corresponding to the 360-degree image and available channel bandwidth for transmission to a corresponding electronic decoder of the plurality of tile-image bitstreams, the plurality of corresponding tile-metadata bitstreams, and the global metadata bitstream. [00111] In some embodiments of any of the above methods, the partitioning comprises: partitioning the 360-degree image into a plurality of uniform patches; computing a respective luminance standard deviation for each of the uniform patches; and grouping different sets of the uniform patches based on values of the respective luminance standard deviation to form different ones of the first tiles. [00112] In some embodiments of any of the above methods, the partitioning further comprises: selecting a candidate height and a candidate width; computing tile-wise distortion values corresponding to the candidate height and the candidate width, with the tile-wise distortion values being computed using the values of the respective luminance standard deviation of the uniform patches of candidate tiles; and comparing the tile-wise distortion values with a fixed threshold value. [00113] In some embodiments of any of the above methods, the partitioning further comprises selecting a tile heigh and a tile width by finding the candidate height and the candidate width for which: each of the tile-wise distortion values in the 360-degree image is smaller than the fixed threshold value; and a total number of the first tiles in the 360-degree image is minimized. [00114] In some embodiments of any of the above methods, at least some of the different ones of the first tiles have different respective sizes. [00115] In some embodiments of any of the above methods, the 360-degree image is an HDR image. [00116] In some embodiments of any of the above methods, a tile-metadata bitstream of the plurality of corresponding tile-metadata bitstreams caries metadata specifying reshaping function coefficients applicable to a respective one of the second tiles. [00117] According to yet another example embodiment disclosed above, e.g., in the summary section and/or in reference to any one or any combination of some or all of FIGs.1- 17, provided is a non-transitory computer-readable medium storing instructions that, when executed by an electronic processor, cause the electronic processor to perform operations comprising a method of encoding a 360-degree image, the method comprising: partitioning, with an electronic encoder, the 360-degree image into a plurality of first tiles; padding, with the electronic encoder, each of the first tiles to generate a corresponding plurality of second tiles, the padding being configured to add to each of the first tiles respective panoramically adjacent regions from respective other ones of the first tiles; generating, with the electronic encoder, a plurality of tile-image bitstreams and a plurality of corresponding tile-metadata bitstreams by applying video encoding to at least a selected subset of the plurality of second tiles; and generating, with the electronic encoder, a global metadata bitstream corresponding to the 360-degree image. [00118] According to yet another example embodiment disclosed above, e.g., in the summary section and/or in reference to any one or any combination of some or all of FIGs.1- 17, provided is an apparatus for reconstructing a 360-degree image, the apparatus comprising: at least one processor; and at least one memory including program code, wherein the at least one memory and the program code are configured to, with the at least one processor, cause the apparatus at least to: based on an end-viewer viewport, select a first subset of a plurality of tile-image bitstreams and a corresponding second subset of a plurality of tile-metadata bitstreams representing the 360-degree image; decode the first subset and the corresponding second subset to reconstruct a tile subset of a plurality of second tiles, each of the second tiles including a respective one of a plurality of first tiles of the 360-degree image and respective added portions having panoramically adjacent regions from respective other ones of the first tiles; and assemble the tile subset into a viewable image based on a global metadata bitstream representing the 360-degree image, said assembling including tile-fusion operations applied to the respective added portions in the tile subset and configured to form portions of the viewable image corresponding to boundaries between the first tiles. [00119] According to another example embodiment disclosed above, e.g., in the summary section and/or in reference to any one or any combination of some or all of FIGs.1-17, provided is a method of reconstructing a 360-degree image, the method comprising: based on an end-viewer viewport, selecting, with an electronic decoder, a first subset of a plurality of tile-image bitstreams and a corresponding second subset of a plurality of tile-metadata bitstreams representing the 360-degree image; decoding, with the electronic decoder, the first subset and the corresponding second subset to reconstruct a tile subset of a plurality of second tiles, each of the second tiles including a respective one of a plurality of first tiles of the 360-degree image and respective added portions having panoramically adjacent regions from respective other ones of the first tiles; and assembling, with the electronic decoder, the tile subset into a viewable image based on a global metadata bitstream representing the 360- degree image, said assembling including tile-fusion operations applied to the respective added portions in the tile subset and configured to form portions of the viewable image corresponding to boundaries between the first tiles. [00120] In some embodiments of the above method, the first tiles are nonoverlapping with one another. [00121] In some embodiments of any of the above methods, the first subset includes a first tile-image bitstream having a first bitrate and a second tile-image bitstream having a lower second bitrate. [00122] In some embodiments of any of the above methods, the global metadata bitstream carries first metadata specifying the boundaries between the first tiles. [00123] In some embodiments of any of the above methods, the global metadata bitstream additionally carries second metadata applicable to all tiles of the plurality of second tiles. [00124] In some embodiments of any of the above methods, a tile-metadata bitstream of the plurality of tile-metadata bitstreams caries metadata specifying reshaping function coefficients applicable to a respective one of the second tiles. [00125] In some embodiments of any of the above methods, said decoding comprises: assembling the first subset and the corresponding second subset into a single High Efficiency Video Coding (HEVC)-conforming bitstream; and applying HEVC decoding to the single HEVC-conforming bitstream to reconstruct the tile subset. [00126] In some embodiments of any of the above methods, the tile-fusion operations include: for a pixel location in an overlap region of two tiles from the plurality of second tiles, computing a pixel value as a weighted sum of corresponding pixel values of the two tiles. [00127] In some embodiments of any of the above methods, weights for the weighted sum are determined based on a distance from the pixel location to a tile boundary. [00128] In some embodiments of any of the above methods, said decoding comprises: assembling the first subset and the corresponding second subset into a single conforming bitstream; and decoding the single conforming bitstream to reconstruct the tile subset. [00129] In some embodiments of any of the above methods, the single conforming bitstream is a High Efficiency Video Coding (HEVC)-conforming bitstream. [00130] In some embodiments of any of the above methods, the assembling comprises: grouping segments of the first subset and the corresponding second subset into blocks, each of the blocks corresponding to a different respective picture order counter value; concatenating the blocks to form a block sequence; and prepending one or more parameter sets to the block sequence, the one or more parameter sets being from a selected tile-image bitstream of the first subset and the corresponding second subset. [00131] In some embodiments of any of the above methods, the one or more parameter sets include a video parameter set, a sequence parameter set, and a picture parameter set. [00132] According to yet another example embodiment disclosed above, e.g., in the summary section and/or in reference to any one or any combination of some or all of FIGs.1- 17, provided is a non-transitory computer-readable medium storing instructions that, when executed by an electronic processor, cause the electronic processor to perform operations comprising a method of reconstructing a 360-degree image, the method comprising: based on an end-viewer viewport, selecting, with an electronic decoder, a first subset of a plurality of tile-image bitstreams and a corresponding second subset of a plurality of tile-metadata bitstreams representing the 360-degree image; decoding, with the electronic decoder, the first subset and the corresponding second subset to reconstruct a tile subset of a plurality of second tiles, each of the second tiles including a respective one of a plurality of first tiles of the 360-degree image and respective added portions having panoramically adjacent regions from respective other ones of the first tiles; and assembling, with the electronic decoder, the tile subset into a viewable image based on a global metadata bitstream representing the 360- degree image, said assembling including tile-fusion operations applied to the respective added portions in the tile subset and configured to form portions of the viewable image corresponding to boundaries between the first tiles. [00133] With regard to the processes, systems, methods, heuristics, etc. described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps could be performed simultaneously, that other steps could be added, or that certain steps described herein could be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating certain embodiments and should in no way be construed so as to limit the claims. [00134] Accordingly, it is to be understood that the above description is intended to be illustrative and not restrictive. Many embodiments and applications other than the examples provided would be apparent upon reading the above description. The scope should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and intended that future developments will occur in the technologies discussed herein, and that the disclosed systems and methods will be incorporated into such future embodiments. In sum, it should be understood that the application is capable of modification and variation. [00135] All terms used in the claims are intended to be given their broadest reasonable constructions and their ordinary meanings as understood by those knowledgeable in the technologies described herein unless an explicit indication to the contrary is made herein. In particular, use of the singular articles such as “a,” “the,” “said,” etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary. [00136] The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments incorporate more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in fewer than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter. [00137] While this disclosure includes references to illustrative embodiments, this specification is not intended to be construed in a limiting sense. Various modifications of the described embodiments, as well as other embodiments within the scope of the disclosure, which are apparent to persons skilled in the art to which the disclosure pertains are deemed to lie within the principle and scope of the disclosure, e.g., as expressed in the following claims. [00138] Some embodiments may be implemented as circuit-based processes, including possible implementation on a single integrated circuit. [00139] Some embodiments can be embodied in the form of methods and apparatuses for practicing those methods. Some embodiments can also be embodied in the form of program code recorded in tangible media, such as magnetic recording media, optical recording media, solid state memory, floppy diskettes, CD-ROMs, hard drives, or any other non-transitory machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the patented invention(s). Some embodiments can also be embodied in the form of program code, for example, stored in a non-transitory machine-readable storage medium including being loaded into and/or executed by a machine, wherein, when the program code is loaded into and executed by a machine, such as a computer or a processor, the machine becomes an apparatus for practicing the patented invention(s). When implemented on a general-purpose processor, the program code segments combine with the processor to provide a unique device that operates analogously to specific logic circuits. [00140] Unless explicitly stated otherwise, each numerical value and range should be interpreted as being approximate as if the word “about” or “approximately” preceded the value or range. [00141] Although the elements in the following method claims, if any, are recited in a particular sequence with corresponding labeling, unless the claim recitations otherwise imply a particular sequence for implementing some or all of those elements, those elements are not necessarily intended to be limited to being implemented in that particular sequence. [00142] Reference herein to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the disclosure. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments necessarily mutually exclusive of other embodiments. The same applies to the term “implementation.” [00143] Unless otherwise specified herein, the use of the ordinal adjectives “first,” “second,” “third,” etc., to refer to an object of a plurality of like objects merely indicates that different instances of such like objects are being referred to, and is not intended to imply that the like objects so referred-to have to be in a corresponding order or sequence, either temporally, spatially, in ranking, or in any other manner. [00144] Unless otherwise specified herein, in addition to its plain meaning, the conjunction “if” may also or alternatively be construed to mean “when” or “upon” or “in response to determining” or “in response to detecting,” which construal may depend on the corresponding specific context. For example, the phrase “if it is determined” or “if [a stated condition] is detected” may be construed to mean “upon determining” or “in response to determining” or “upon detecting [the stated condition or event]” or “in response to detecting [the stated condition or event].” [00145] Also for purposes of this description, the terms “couple,” “coupling,” “coupled,” “connect,” “connecting,” or “connected” refer to any manner known in the art or later developed in which energy is allowed to be transferred between two or more elements, and the interposition of one or more additional elements is contemplated, although not required. Conversely, the terms “directly coupled,” “directly connected,” etc., imply the absence of such additional elements. [00146] As used herein in reference to an element and a standard, the term compatible means that the element communicates with other elements in a manner wholly or partially specified by the standard and would be recognized by other elements as sufficiently capable of communicating with the other elements in the manner specified by the standard. The compatible element does not need to operate internally in a manner specified by the standard. [00147] The functions of the various elements shown in the figures, including any functional blocks labeled as “processors” and/or “controllers,” may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), and non volatile storage. Other hardware, conventional and/or custom, may also be included. Similarly, any switches shown in the figures are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the implementer as more specifically understood from the context. [00148] As used in this application, the terms “circuit,” “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry); (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions); and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.” This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device. [00149] It should be appreciated by those of ordinary skill in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the disclosure. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown. [00150] “BRIEF SUMMARY OF SOME SPECIFIC EMBODIMENTS” in this specification is intended to introduce some example embodiments, with additional embodiments being described in “DETAILED DESCRIPTION” and/or in reference to one or more drawings. “BRIEF SUMMARY OF SOME SPECIFIC EMBODIMENTS” is not intended to identify essential elements or features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. [00151] Various aspects of the present invention may be appreciated from the following Enumerated Example Embodiments (EEEs): 1. A method of encoding a 360-degree image, the method comprising: partitioning, with an electronic encoder, the 360-degree image into a plurality of first tiles; padding, with the electronic encoder, each of the first tiles to generate a corresponding plurality of second tiles, the padding being configured to add to each of the first tiles respective panoramically adjacent regions from respective other ones of the first tiles; generating, with the electronic encoder, a plurality of tile-image bitstreams and a plurality of corresponding tile-metadata bitstreams by applying video encoding to individual tiles of at least a selected subset of the plurality of second tiles; and generating, with the electronic encoder, a global metadata bitstream corresponding to the 360-degree image. 2. The method of EEE 1, wherein the plurality of tile-image bitstreams includes a first tile-image bitstream having a first bitrate and a second tile-image bitstream having a lower second bitrate. 3. The method of EEE 2, further comprising: receiving, with the electronic encoder, information specifying an end-viewer viewport for the 360-degree image; selecting, with the electronic encoder, the first tile-image bitstream for transmission to an electronic decoder when a corresponding one of the first tiles overlaps with the end-viewer viewport; and selecting, with the electronic encoder, the second tile-image bitstream for transmission to the electronic decoder when the corresponding one of the first tiles has no overlap with the end-viewer viewport. 4. The method of one of the preceding EEEs, wherein the global metadata bitstream carries first metadata specifying tile boundaries defined during the partitioning; and wherein the global metadata bitstream additionally carries second metadata applicable to all tiles of the corresponding plurality of second tiles. 5. The method of one of the preceding EEEs, wherein the partitioning comprises: partitioning the 360-degree image into a plurality of uniform patches; computing a respective luminance standard deviation for each of the uniform patches; and grouping different sets of the uniform patches based on values of the respective luminance standard deviation to form different ones of the first tiles. 6. The method of EEE 5, wherein the partitioning further comprises: selecting a candidate height and a candidate width; computing tile-wise distortion values corresponding to the candidate height and the candidate width, with the tile-wise distortion values being computed using the values of the respective luminance standard deviation of the uniform patches of candidate tiles; comparing the tile-wise distortion values with a fixed threshold value; and selecting a tile heigh and a tile width by finding the candidate height and the candidate width for which: each of the tile-wise distortion values in the 360-degree image is smaller than the fixed threshold value; and a total number of the first tiles in the 360-degree image is minimized. 7. The method of one of the preceding EEEs, wherein a tile-metadata bitstream of the plurality of corresponding tile-metadata bitstreams caries metadata specifying reshaping function coefficients applicable to a respective one of the second tiles. 8. A method of reconstructing a 360-degree image, the method comprising: based on an end-viewer viewport, selecting, with an electronic decoder, a first subset of a plurality of tile-image bitstreams and a corresponding second subset of a plurality of tile- metadata bitstreams representing the 360-degree image; decoding, with the electronic decoder, individual tile-image bitstreams of the first subset and the corresponding second subset to reconstruct a tile subset of a plurality of second tiles, each of the second tiles including a respective one of a plurality of first tiles of the 360-degree image and respective added portions having panoramically adjacent regions from respective other ones of the first tiles; and assembling, with the electronic decoder, the tile subset into a viewable image based on a global metadata bitstream representing the 360-degree image, said assembling including tile-fusion operations applied to the respective added portions in the tile subset and configured to form portions of the viewable image corresponding to boundaries between the first tiles. 9. The method of EEE 8, wherein the global metadata bitstream carries first metadata specifying the boundaries between the first tiles; and wherein the global metadata bitstream additionally carries second metadata applicable to all tiles of the plurality of second tiles. 10. The method of EEE 8 or 9, wherein a tile-metadata bitstream of the plurality of tile- metadata bitstreams caries metadata specifying reshaping function coefficients applicable to a respective one of the second tiles. 11. The method of one of the preceding EEEs, wherein said decoding comprises: assembling the first subset and the corresponding second subset into a single conforming bitstream; and decoding the single conforming bitstream to reconstruct the tile subset. 12. The method of EEE 11, wherein the single conforming bitstream is a High Efficiency Video Coding (HEVC)-conforming bitstream. 13. The method of EEE 11 or 12, wherein the assembling comprises: grouping segments of the first subset and the corresponding second subset into blocks, each of the blocks corresponding to a different respective picture order counter value; concatenating the blocks to form a block sequence; and prepending one or more parameter sets to the block sequence, the one or more parameter sets being from a selected tile-image bitstream of the first subset and the corresponding second subset; and wherein the one or more parameter sets include a video parameter set, a sequence parameter set, and a picture parameter set. 14. The method of one of the EEEs 8 to 13, wherein the tile-fusion operations include: for a pixel location in an overlap region of two or more tiles from the plurality of second tiles, computing a pixel value as a weighted sum of corresponding pixel values of the two or more tiles. 15. The method of EEE 14, wherein weights for the weighted sum are determined based on a distance from the pixel location to a tile boundary. 16. Apparatus for encoding a 360-degree image, comprising: at least one processor; and at least one memory including program code; wherein the at least one memory and the program code are configured to, with the at least one processor, cause the apparatus to carry out the method of encoding a 360-degree image according to one of the claims 1 to 7. 17. Apparatus for reconstructing a 360-degree image, comprising: at least one processor; and at least one memory including program code; wherein the at least one memory and the program code are configured to, with the at least one processor, cause the apparatus to carry out the method of reconstructing a 360- degree image according to one of the claims 8 to 15. 18. Non-transitory computer-readable medium storing instructions that, when executed by an electronic processor, cause the electronic processor to perform operations comprising the method of encoding a 360-degree image according to one of the claims 1 to 7. 19. Non-transitory computer-readable medium storing instructions that, when executed by an electronic processor, cause the electronic processor to perform operations comprising the method of reconstructing a 360-degree image according to one of the claims 8 to 15.

Claims

CLAIMS 1. A method of encoding a 360-degree image, the method comprising: partitioning, with an electronic encoder, the 360-degree image into a plurality of first tiles; padding, with the electronic encoder, each of the first tiles to generate a corresponding plurality of second tiles, the padding being configured to add to each of the first tiles respective panoramically adjacent regions from respective other ones of the first tiles; generating, with the electronic encoder, a plurality of tile-image bitstreams and a plurality of corresponding tile-metadata bitstreams by applying video encoding to individual tiles of at least a selected subset of the plurality of second tiles; and generating, with the electronic encoder, a global metadata bitstream corresponding to the 360-degree image; wherein a tile-metadata bitstream of the plurality of corresponding tile-metadata bitstreams caries metadata specifying reshaping function coefficients applicable to a respective one of the second tiles. 2. The method of claim 1, wherein the plurality of tile-image bitstreams includes a first tile-image bitstream having a first bitrate and a second tile-image bitstream having a lower second bitrate. 3. The method of claim 2, further comprising: receiving, with the electronic encoder, information specifying an end-viewer viewport for the 360-degree image; selecting, with the electronic encoder, the first tile-image bitstream for transmission to an electronic decoder when a corresponding one of the first tiles overlaps with the end-viewer viewport; and selecting, with the electronic encoder, the second tile-image bitstream for transmission to the electronic decoder when the corresponding one of the first tiles has no overlap with the end-viewer viewport. 4. The method of one of the preceding claims, wherein the global metadata bitstream carries first metadata specifying tile boundaries defined during the partitioning; and wherein the global metadata bitstream additionally carries second metadata applicable to all tiles of the corresponding plurality of second tiles. 5. The method of one of the preceding claims, wherein the partitioning comprises: partitioning the 360-degree image into a plurality of uniform patches; computing a respective luminance standard deviation for each of the uniform patches; and grouping different sets of the uniform patches based on values of the respective luminance standard deviation to form different ones of the first tiles. 6. The method of claim 5, wherein the partitioning further comprises: selecting a candidate height and a candidate width; computing tile-wise distortion values corresponding to the candidate height and the candidate width, with the tile-wise distortion values being computed using the values of the respective luminance standard deviation of the uniform patches of candidate tiles; comparing the tile-wise distortion values with a fixed threshold value; and selecting a tile heigh and a tile width by finding the candidate height and the candidate width for which: each of the tile-wise distortion values in the 360-degree image is smaller than the fixed threshold value; and a total number of the first tiles in the 360-degree image is minimized. 7. A method of reconstructing a 360-degree image, the method comprising: based on an end-viewer viewport, selecting, with an electronic decoder, a first subset of a plurality of tile-image bitstreams and a corresponding second subset of a plurality of tile- metadata bitstreams representing the 360-degree image; decoding, with the electronic decoder, individual tile-image bitstreams of the first subset and the corresponding second subset to reconstruct a tile subset of a plurality of second tiles, each of the second tiles including a respective one of a plurality of first tiles of the 360-degree image and respective added portions having panoramically adjacent regions from respective other ones of the first tiles; and assembling, with the electronic decoder, the tile subset into a viewable image based on a global metadata bitstream representing the 360-degree image, said assembling including tile-fusion operations applied to the respective added portions in the tile subset and configured to form portions of the viewable image corresponding to boundaries between the first tiles; wherein a tile-metadata bitstream of the plurality of tile-metadata bitstreams caries metadata specifying reshaping function coefficients applicable to a respective one of the second tiles. 8. The method of claim 7, wherein the global metadata bitstream carries first metadata specifying the boundaries between the first tiles; and wherein the global metadata bitstream additionally carries second metadata applicable to all tiles of the plurality of second tiles. 9. The method of claim 7 or 8, wherein said decoding comprises: assembling the first subset and the corresponding second subset into a single conforming bitstream; and decoding the single conforming bitstream to reconstruct the tile subset. 10. The method of claim 9, wherein the single conforming bitstream is a High Efficiency Video Coding (HEVC)-conforming bitstream. 11. The method of claim 9 or 10, wherein the assembling comprises: grouping segments of the first subset and the corresponding second subset into blocks, each of the blocks corresponding to a different respective picture order counter value; concatenating the blocks to form a block sequence; and prepending one or more parameter sets to the block sequence, the one or more parameter sets being from a selected tile-image bitstream of the first subset and the corresponding second subset; and wherein the one or more parameter sets include a video parameter set, a sequence parameter set, and a picture parameter set. 12. The method of one of the claims 7 to 11, wherein the tile-fusion operations include: for a pixel location in an overlap region of two or more tiles from the plurality of second tiles, computing a pixel value as a weighted sum of corresponding pixel values of the two or more tiles. 13. The method of claim 12, wherein weights for the weighted sum are determined based on a distance from the pixel location to a tile boundary. 14. Apparatus for encoding a 360-degree image, comprising: at least one processor; and at least one memory including program code; wherein the at least one memory and the program code are configured to, with the at least one processor, cause the apparatus to carry out the method of encoding a 360-degree image according to one of the claims 1 to 6. 15. Apparatus for reconstructing a 360-degree image, comprising: at least one processor; and at least one memory including program code; wherein the at least one memory and the program code are configured to, with the at least one processor, cause the apparatus to carry out the method of reconstructing a 360- degree image according to one of the claims 7 to 13. 16. Non-transitory computer-readable medium storing instructions that, when executed by an electronic processor, cause the electronic processor to perform operations comprising the method of encoding a 360-degree image according to one of the claims 1 to 6. 17. Non-transitory computer-readable medium storing instructions that, when executed by an electronic processor, cause the electronic processor to perform operations comprising the method of reconstructing a 360-degree image according to one of the claims 7 to 13.