JP6495552B2 - Dynamic range coding for images and video - Google Patents

Description

  The present invention applies an image or video of a first luminance dynamic range to a second luminance dynamic range (in the majority of the following embodiments, the encoding side is lower than the first range of the input image and the decoding side With regard to the apparatus and method and the resulting product, eg a data storage product (eg Blu-ray disc) or transmission product or signal, which makes it possible to convert it into a higher) image or video, in particular the master high dynamic range (HDR: high dynamic range) image (eg, 1000 nit peak brightness, ie, the peak brightness of the associated reference display), which is not limited to a specific color look, eg, defined by a color grader Master HDR grading created or broadcast Ready RAW TV program capture, then encoding and communication via a second dynamic range image, or in particular a set of images (video), which is encoded in a different dynamic range than the input master Standard dynamic range image (SDR: standard dynamic range, which is defined in the legacy Rec. 709 OETF and looks optimal on a 100 nit peak brightness (PB) reference monitor) Or any LDR (low dynamic range) image coding, and on the other side of any image communication system, a corresponding image or video decoder, for example, On the receiving side Generate a decoded image suitable for rendering on an available 3000 nit PB HDR display. Embodiments of the method and apparatus are particularly suitable for any video encoding and decoding that needs to be able to handle higher luminance requirements than legacy (LDR) video encoding (also referred to as standard SDR encoding in this document). SDR (LDR) video coding is typically performed in Rec. Encoded with 709 EOTF, which is in good agreement with typical LDR display capabilities with peak brightness around 100 nits standard value and black level of 0.1 nit, and LDR grading is performed at these standard values. Assume that A high dynamic range image is any image that cannot be encoded with legacy SDR encoding alone (although some of the tools and equipment are reused in place, as explained below) because Typically because of higher image quality characteristics, especially because of the higher peak brightness of the image (at least twice as high as 100 nits, but typically higher quality HDR images such as 1000 nitPB or 5000 nitPB) Is). If no further details of the lower end of the luminance dynamic range are mentioned, at least in order to understand the embodiments of the present application, it is implicitly assumed by those skilled in the art to assume it 0 nits.

  In recent years, several very different displays, specifically television signal receiving displays (televisions) with significantly different peak brightness, have appeared on the market. Traditionally, the peak brightness (PB) of so-called legacy low dynamic range (LDR) displays has only changed by about twice (at somewhere between 80 and 150 nits), but the recent trend towards higher peak brightness is over 1000 nits So-called high dynamic range (HDR) televisions, and 5000 nit PB displays, and it is expected that a variety of such higher PB displays will soon be on the market. Even movie theaters are currently exploring ways to increase the final brightness dynamic range perceived by viewers. Compared to a 100 nit LDR standard legacy TV, for example a 2000 nit display has 20 times the peak brightness, which corresponds to more than 4 additional stops available, ie rendering brighter objects in various images This corresponds to a larger number of techniques. On the other hand, if a new generation HDR image generation or shooting system is also used, this allows for much better rendering of HDR scenes or effects. For example, instead of (soft) clipping the clear world outside a building or vehicle (as done in legacy LDR grading), using additional available brightness on the brightness axis of the HDR TV gamut, A colorful outdoor area can be displayed. This means that content creators are called, but not limited to, color graders (although they are embodied in various ways, for example in live television production, one that affects several color characteristics of the encoding in particular). A person who may only need to adjust the dial from time to time) and there is room to create dedicated HDR images or video content that is very beautiful (typically brighter, sometimes more contrasting and more colorful) It is. On the other hand, however, this creates a problem, and LDR image coding is relatively designed starting from white and is well illuminated according to an intermediate gray of 18% reflection, which typically means The brightness rendered on a display of less than 5% of a relatively low PB, such as 100 nits, is typically viewed by viewers as it is difficult to identify dark gray or depending on ambient lighting It can be seen as even indistinguishable black. On a 5000 nit display, there is no problem with this optimally graded HDR image, so 5% of 5000 nit is still 250 nit, so this looks like a normal interior, for example, up to 95% of the luminance range is Or purely for HDR effects such as areas that are close to such a lamp, ie brightly lit. However, in LDR, this HDR grading rendering is completely wrong (because it was not created for such a display), and viewers can, for example, hottest corresponding to the brightest area on the area close to black. I can only see the spot.

  In general, regrading is necessary to produce an optimal image for sufficiently different displays (at least twice the PB difference). This is done by regrading the image for the lower dynamic range display to make it suitable for rendering on the higher dynamic range display (ie, it looks optimal on an actual display of 1000 nit PB, for example, Upgrade the 1000 nit reference display input image, which is then color processed for rendering on a 5000 nit PB actual display) and vice versa, ie downgrade the image and encode it as a video image Both to make it suitable for display on the actual display of a PB lower than the reference display associated with the grading being performed (the image is typically transmitted to the receiver in some manner). For simplicity, only scenarios where one or more HDR images are downgraded to LDR will be described.

  HDR technology (which means that it should be able to process at least some HDR images of fairly complex, i.e. high peak brightness, such as 10000 nits, but LDR images or moderate Works with dynamic range images, etc.) and penetrates both consumer and professional areas (eg cameras, data processing devices such as Blu-ray players, televisions, computer software, projection systems, security or video conferencing systems, etc.) ), A technique capable of processing various aspects by various methods is required.

  In WO 2013/144809 (and WO 2014/056679), Applicant has proposed that an image (Im_res) suitable for a display dynamic range different from the reference display dynamic range associated with the input image (Im-in). Generally formulate a technique for performing color processing to produce (typically PB is sufficient to characterize different display dynamic ranges, and thus optimally graded images, because (In some scenarios, this is for ignoring the black point and assuming it is actually zero.) That is, this basically formulates the PB of the display created so that the image looks optimal, Form a good prior art to be improved for the present invention as will be elucidated below. This principle is briefly reformulated again in FIG. However, the reader understands that some of the characteristics of the prior art examples are relevant in the context of this embodiment, some do not exist in general HDR coding, and there are no restrictions on this embodiment and teachings. It should be understood that it can work with such various HDR video (or image) codec technologies.

  Specifically, what is relevant is that it has two different dynamic range looks of the scene, which can be related to each other via color conversion (eg, as shown in FIG. Significantly reduce luma, or equivalently luma (these are codes that encode the corresponding luma typically into a 10 or 12 bit representation, etc.) You can choose to focus on a sub-range that has a small luminance range for the LDR). Our embodiment can also work with systems that send some encoding of the master HDR image to any receiver, but the following description uses an embodiment that conveys LDR grading instead of the HDR image. However, a color conversion function that allows the receiver to recalculate a close reconstruction of the master HDR grading image (Im_in_HDR) of the HDR scene (some of which may operate in the chromaticity plane, but mainly luminance conversion) Let's assume that we use together the metadata that encodes. This is not only for receivers with HDR functionality to render HDR images on a connected HDR display, but also for legacy LDR images for people who still have LDR televisions or computer monitors, projectors, portable displays, etc. It can also be rendered.

  This principle is generally applicable (constructable), ie, it should not be assumed that there are any specific restrictions on the color format of the input or output image, or the color space in which color processing is performed, Specifically, when the prior art refers to a particular linear RGB process, this document explicitly states that several non-linear color space processes and encoding strategies based thereon are invented and described.

  The various pixels of the input image Im_in are continuously color processed by the color converter 100 (here it is assumed that it is present in the video encoder, the HDR video to be encoded is taken as input, and the LDR image is Output, which still optimally includes HDR information, but of the regraded LDR look), which is multiplied by the multiplier 104 (multiplier factor (a)) by the multiplier 104, This is done by obtaining the output color RsGsBs of the pixels in the output image Im_res. The multiplication factor is typically defined from a certain tone mapping specification created by a human color grader, but analyzes the characteristics of the image (eg, the color characteristics of a special object such as a histogram or a face). May come from automatic conversion algorithm. The mapping function is, for example, coarse and gamma-like, so dark colors are lifted (which is needed to make it brighter and more contrast to render on LDR displays), and at the cost of contrasting bright areas Is reduced and pastelized on the LDR display. Grader further identifies certain special objects, such as faces, and creates a portion of the curve with increased contrast for that brightness. Specifically, this curve is the maximum of the R, G and B color components of each pixel named M (determined by the maximum value evaluation unit 101), and the curve application unit 102 (which is easily LUT Typically, after receiving a parameter encoding a mapping function shape such as a gamma coefficient, it is applied on the receiving side that performs color processing, for example, calculated for each shot of an image) The same principle works even if M is luminance or a non-linear representation with luminance or lightness, eg luma, ie 1 / N 乘 of luminance, where N is an integer, etc. Can do. Then, the multiplication coefficient calculation unit 103 calculates an appropriate multiplication coefficient (a) for each pixel currently being processed. This is, for example, the output of the tone mapping function F applied to M, ie F (M) divided by M, when the image is rendered on a first target display, such as a 100 nit LDR display. If the image is needed (for example for an 800 nit PB intermediate display) (or other values, possibly higher than the reference display PB of the HDR input image Im_in), it is rendered directly on the display or communicated Or other function G that rescales the amount of multiplicative mapping of the input color to a value suitable for the display dynamic range to which the image fits (whether stored in some memory for later use) Applies to (M) / M. This is a technique for expressing very complex brightness conversion as multiplication. While the prior art described to illustrate the background of the present invention typically multiplies linear RGB components, embodiments of the present invention are non-linear, eg, typically RGB color representations, For example, Rec. Emphasize that it works with R'G'B 'components transformed with 709 OETF, or powers of R, G and B, which are typically less than 1, eg, exponent values of 1/2.

  The part described so far constitutes the overall color processing. This means that processing can be performed based only on specific values in the colors of a continuous set of pixels (and we will focus only on the brightness of those colors). Thus, for example, if only pixels are obtained from a set of pixels in a circular sub-selection of the image, color processing can be performed according to the above formulated principle. However, human vision is very relative and spatially relative, and the color and brightness of an object is related to the colorimetric properties of other objects in the image (and also various technical limitations). More advanced HDR encoding systems have the option of performing local processing. In some images, it may be desirable to separate one or more objects, such as lamps or faces, and perform dedicated processing on the objects. However, to reiterate, in the technique presented here, this is not just some separate color processing, but a part of at least one further grading encoding that can be derived from the image of the master grading pixel. (Here, LDR derived from HDR). The simpler variants of the market do not use local processing (similar in concept but lead to, inter alia, more complex integrated circuits) and the following principles can be explained without their details The embodiment will not be described in further detail.

  The master grading or derived grading is actually communicated to the receiver as a spatial structure, i.e., an image of an imaged scene object, and the color conversion function that encodes the relationship between the two looks is also metadata. If communicated, other gradings can be recalculated at the receiver. That is, for example, when an HDR image is received, in order to construct an LDR image by decoding as necessary, or conversely, when an LDR image is communicated or stored in a look pair Requires color processing to reconstruct the HDR image. The fact that the principle of local processing is used in the coding technique has technical implications, among other things, that it requires a simple set of basic mathematical processing methods, the reasons for which are in the field This is because all decoding ICs or software must be able to implement this and understand the encoding at an affordable price to generate a decoder LDR image.

  When designing practically useful coding techniques for various images or videos that take advantage of the market, the technical constraints are from the IC point of view (cheap devices are also simple ICs or area parts of ICs or software The coding function tools should be few and smartly selected to do the most necessary to create and encode the various dynamic range look images of the scene (As a result, any “grader” or content creator in any content creation variant will store or communicate this with the desired result that created the HDR / LDR image look pair (close enough to the desired). And a corresponding encoding for). On the other hand, the other problem is that in the philosophy described above, a human color grader, etc. specifies the regrading as encoded in an LDR image etc. and is appropriate for any receiver at the receiving end. While playing the role of regrading to HDR images, in the optimal set of parameters for a particular look of a given scene, the grader also has the appropriate grading / coding tools in the proper order so that they (Not only need to get good accuracy of the desired color look, but also time is important, so as little as possible to get the look you want quickly and efficiently Need to do this in operation). The two conflicting sets of constraints need to be provided elegantly. Furthermore, there is even a third criterion that must be seen when an LDR image is transmitted to any receiver, and at least approximately the following technical solution must be satisfied: When designing an LDR look image, the reconstruction of the HDR image by the receiver HDR decoder must still be of sufficient accuracy, so this is due to the general purpose HDR encoder and decoder at the time of invention. This also affects the resulting optimum technical equipment unit.

  Hattori et al., “HLS: SEI message for Knee Function Information”, 16. JCT-VC MEETING, September 1, 2014, San Jose includes input HDR luminance (ie, codes up to 1200 nits) on the input dynamic range up to, for example, 1200% of the scene white level based on one or more knee points. ) And a new SEI message specifying the relationship between LDR luma. Kneepoints say that when a digital sensor is illuminated according to the average gray world assumption, it will hard clip scene objects that are only slightly brighter than the scene white (which is about 5 times brighter than the scene average gray). It was a trick to solve the problem of having a problem tendency. The idea is that if you have a better sensor that is less noisy for darker scene brightness, make the scene a little underexposed, for example, up to four times the scene white, brighter than the scene white. Discriminating scene brightness (for example, bride's white dress under optimal scene lighting) (clip it sloppyly, for example, all over 1.2 times the scene white) White, ie, luma Y ′ = 8 bits, not encoding to 255). Of course, capturing such brighter scene brightness accurately in the camera sensor is only part of the solution because of the SDR for consumption such as rendering with good image quality on an SDR100 nitPB display, for example. This is because when calculating the image, there is also a need for a trick to assign the actual 8-bit luma code to the scene luminance (relative to the maximum still recordable scene luminance, i.e. 1.0) determined by the analog sensor. Simply compressing all the colors on the SDR output luma axis to fit the upper range of 4x or even 12x is not an elegant solution, because the reason seems to be well exposed as well This is because a supposed dark object becomes too dark at that time and does not provide good SDR image quality. Therefore, we devised a technique to keep darker luma's classic (Rec. 709) luma assignments to knee points, and above knee points, a more compressed, typically logarithmic luma code assignment strategy. Use a much higher upper range of input luminance (eg, a range from 1x scene white to 4x scene white) depending on the position of the knee point, the upper range of the luma code, eg, the top 10% (Or if you want to reduce the brightness brighter than a significant amount of scene white in the SDR image, set the knee point to 50% of the luma range, ie 128 for 8 bits, or 512 for 10 bits. (Although it can be selected, the color look of the image is still visible, but begins to deteriorate significantly). Hattori introduces techniques and practical techniques to quickly communicate all the necessary information to the decoder, and when the decoder receives an SDR image, the HDR image is based on one or more such knee points. That information is needed to apply the inverse function to perform the reconstruction. The knee processing mechanism is not a good technique for accurately controlling the look of the SDR image. Higher, especially if the K-fold factor that specifies how many times the maximum scene white brightness should still be able to be encoded is not too high (ie a medium high dynamic range scene) Bending the higher dynamic range (input_d_range) with a simple and fast function that continually bends the lightness subrange to the smaller subrange of the SDR luma is an easy approach (assuming this is not a problem, but This is not always true if you have important image content, such as in the brightest areas such as clouds, with beautiful bright gray values, destroyed by the wrong simple logarithm part of the function). It is clear that this document does not teach a simple and very useful coarse grading function that is particularly useful when a human grader wants to optimize the look of an image accurately (used blindly on any automated device). In contrast to Hattori, which is only a mathematical specification of a certain reasonably working luminance-to-luma mapping, because its sole purpose is simply to reconstruct the HDR look image, ie, at the receiver. It is possible to encode into SDR images that are not necessarily artistic, and the Applicant works (semi-) automatically in some embodiments, but with the same encoding principle Design a system that should also cater to markets with artistic accuracy, such as accurate color grading with human color graders in Hollywood movies This is because the wanted Rukoto). More specifically, there is clearly no teaching of the middle section of the parabola, even though the precise dark and bright partial region control of the HDR scene image is not taught, and Hattori reaches such an implementation. Is not trying to do the necessary HDR research.

  US Patent Application Publication No. 2015/010059 also includes this same knee point curve (model 3: several pivot points) communicated as SEI image teaching, including the teaching of the S curve, It is just another possible HDR to SDR mapping curve that is independent of the teaching.

  Zicon Mai et al., "Optimizing a Tone Curve for Backward-Compatible High Dynamic Range Image and Video Compression, IEEE Transactions on cessations." 20, no. 6, June 2011 is also a method of actually transmitting a reconfigurable HDR image as an SDR image, but an image optimum mapping function shape determined by a greatly different method, that is, based on a luminance histogram of an input image (Do not allocate too few codes for large regions, this may introduce banding, see FIG. 3).

  WO 2014/178286 is also a knee-type encoder (FIG. 3) that allows scene brightness (N times) somewhat brighter than scene white to be included in the SDR code. This can then be used to render an HDR image (one that brightens the brightest object cleanly) on an HDR display with a peak brightness N times brighter than the SDR display when N is 8 or 10, for example. (FIG. 7).

  WO 2014/128586 also introduces a variety of communicating HDR images of HDR scenes as SDR images that can actually be used to render directly on legacy SDR displays already deployed in large numbers in the viewer's premises. Includes technical teaching. This teaches that highly customized brightness mapping curve shapes by image may be useful (FIG. 8), but the actual coarse function is communicated with the corresponding graded SDR technique. It does not teach anything that it is a very useful function in HDR.

  None of the prior art gives any suggestions in the direction of the elegant and simple HDR coding system of the present application, and the present application is highly efficient for all practical purposes, even for critical color graders. It enables to reach quality SDR images efficiently.

  In addition to being computationally simple enough for ICs to operate at video speeds, the grader is on any intended display (although at least on HDR displays and others, typically legacy LDR displays). , On various displays between the HDR display where at least the HDR look is encoded and the LDR display where the LDR look is encoded together, with parameters specifying a functional regrading color transformation starting from the HDR image, The encoding preferably looks good, and both images specify an arbitrary detailed color look for display (typically defined as a 10-bit word scaled to [0,1]) In addition to having a practically useful coding system that is sufficiently versatile and easy to handle The problem is that the input color (Y′UV_LDR) of the pixel of the input image (Im_in) is changed to the output color (R′o, G′o, of the red, green and blue color components of the pixel of the output image (Im_res, REC_HDR)). B′o), the input image has a first luminance dynamic range (DR — 1), the output image has a second luminance dynamic range (DR — 2), and the first dynamic The peak luminance of the range is at least twice lower than the peak luminance of the second dynamic range or vice versa, and the darkness of the luma range of the input image color including the darkest input luma value determined by the slope variable (InvBet) The linear interval for the subrange (SR_d) and the bright subrange (SR_br) controlled by the second slope variable (InvAlph) A coarse mapping unit (202, 552) configured to apply a three-interval lightness grading curve including a second linear interval for the brightest input luma value and a parabolic interval between the two linear intervals This is solved by an HDR video decoder (250) comprising an image color processing device (200) comprising:

  The creator, for example, the person adjusting the parameters, may determine the required slope according to the characteristics of the HDR scene or its image and, secondly, the characteristics of the encoding in which the image is encoded if desired. it can. Typically, an output image of encoding (an input image received by a receiver and a decoder constituting the same) is a 100 nit PB Rec. In the case of 709 SDR encoding, for example, a grader (or an automatic curve determination algorithm based on measured image characteristics), for example, determines the curve shape for the PB of the input master HDR image (eg, 5000 nit vs. 1000 nit PB). However, an accurate shape may be determined based on the content. For example, if there is very dark content such as a single car in FIG. 4, the grader makes it a relatively deep luminance for HDR image rendering on an HDR display (eg, 2000 nit PB), but the LDR image code of the HDR scene. We want it to be relatively high and bright (they need to be visible when rendered on a typical SDR display). In addition, the creator has already taken into account typical LDR image encoding details, such as the number of bits that the HEVC codec and the like uses to encode the LDR image. Some embodiments of the decoder autonomously determine the parabolic region between linear intervals, eg, a constant 20% of the input luma range, or a percentage depending on the slope of the two intervals (eg, the slope More if the difference is large), or whether there are more details in the current shot characteristics of the image, for example whether there is more detail in the intermediate brightness range above the darker range, or whether there is a smooth gradient Based on whether or not.

  However, in other embodiments, the grader, or generally the creator, can specify the width of the parabolic region, eg, two widths (from which point the parabolic portion changes to a linear portion) W1 and W2 is specified from some defined point that can be defined by the decoder, for example, from where it intersects when the linear portion is continuous. Or it can be conveyed as a single width value. The only necessary condition is that the decoder can apply an inverse 3-section lightness grading function to obtain a reconstructed HDR look image of the HDR scene from the received LDR image. In various embodiments, the parameters of the concave upbending function shown in FIG. 2 (ie, InvBet, InvAlph) can be transmitted, or similarly, the downgrade curve parameters (alph, bet) can be transmitted. it can. One curve can be easily converted to the other, for example, the LUT can be set to the desired accuracy and then the axes can be exchanged, so that those skilled in the art can You will understand that you are talking about both possibilities in the realization of. In general, there are two additional parameters as desired, eg, white offset Wh_o, which defines where the brightest HDR code will fit on the output LDR luma code range (or typically other implementations). The form may be defined on the vertical axis from the brightest input luminance or luma of HDR, in which case HDR colors exceeding this value will be clipped in the LDR representation, which may be useful depending on the particular application of image coding Or may be undesirable). Similarly, there is a dark offset B_o, which is determined by the grader based on other principles, because the dark color rendering on the display is different from the light color rendering. Therefore, in a general system, five parameters alpha, bet, W (= W1 + W2, defined in a pre-agreed manner, for example 50% to the left and right of the intersection 303), B_o and Wh_o are supplied. It is useful to have an encoder embodiment.

  In a simple embodiment, a three-section curve is sufficient. More advanced embodiments apply additional color transformations. For example, the first pre-color conversion unit 224 applies a transformation that distributes the color of the image more uniformly, for example, for a human viewer, before applying the tri-part curve. The a posteriori color conversion unit 203 applies other color conversion functions, for example, the grader can darken certain parts of the luma range as compared to the lightness look obtained from a three-part curve. The domain color conversion unit 204 is, for example, a square root or a Rec. Instead of obtaining Y'o results for the 709 domain, further color space transformations can be performed, and similarly, for example, calculations can be performed on a perceptually linearized domain. Of course, the input and output color domains can typically affect the exact shape of the three-part curve and the two, three, or five parameters described above that characterize it. Finally, necessary color conversion is performed, for example, Rec. After generating the results of 709, ie, some HDR luma definitions, such as those with PQ or linear R'o, G'o, B'o color component specifications, the color format unit 226 further displays the connected display. Specify a final RGB color space color suitable for direct drive, eg Rd, Gd, Bd, and the connected display is typically a pre-specified light that is standard or display specific An HDR display that expects an HDR image definition in its image connection (cable or wireless) that typically follows an electro-transfer function (OETF) or the like. The customization function application unit (203) is very detailed based on this current HDR scene need (specifically, the complexity of splicing all object brightness puzzles in a very small LDR luminance range). Designing an exact function can be done where it can be performed (eg, using sufficient time, computational resources, etc.), i.e. typically on the author side (and this function Is transmitted to the receiving side device). In particular, the human color grader can fine tune the non-linear shape and bend it at all suitable locations corresponding to the brightness of the main object or region of the starting image. Thus, for example, a small portion can be brightened as desired to an arbitrary brightness in the generated image. In particular, for example if most of the indoor scene already has the correct brightness, but some small part of the sky visible through the window is too bright or too dark, the custom curve CC will only convert those pixel colors. Can be designed. In some specific embodiments, the custom curve can even be designed such that its slope does not fall below a minimum value anywhere in the input range. Various types of HDR image or video processing systems in the future market (eg broadcast, LDR-based existing satellite channels versus Internet distribution) and various types of content (very magnificent HDR art in Hollywood) The system has been designed to be compatible with typical images (as opposed to on-site production where the generated dynamic range occurs), so the custom curve unit can be used for any detailed luminance (brightness) behavior. It can be implemented for any part of the image that needs to be implemented, and in various implementations, no matter how much or less the implementation effort of the creator on which this is realized.

  The following non-exhaustive embodiments are very useful.

  The HDR video decoder (250) of claim 1, wherein the image color processing device (200) is configured to apply a three-section curve to a low dynamic range luma (Y'_LDR). This is useful for operating in one particular domain, eg one luma domain of two gradings, eg typically SDR luma.

  The output luma (Y'o) related to the luminance of the color, which is the output result of the image color processing device (200), preferably applying a three-section curve to the input color by a power function of index 1 / N where N is 2 HDR video decoder (250), configured to generate as a result of applying a three-section curve.

  The image color processing apparatus (200) performs a multiplication using the output luma (Y'o) as a multiplication coefficient, and a preferable non-linear color expression (R's, G's, B's) of the color of the pixel currently being processed. An HDR video decoder (250) configured to determine an output color by comprising a multiplier (225) applied to the.

  The image color processing device (200) is technically derived from linear R, G, and B color components by a non-linear function, preferably having a shape close to a square root function and an exponential 1 / N function where N is an integer value. An HDR video decoder (250) configured to obtain a non-linear color representation (R's, G's, B's) as defined in

  HDR video decoding comprising a reading unit (277) configured to read the first and second slope variables from the received metadata and configured to supply it to the coarse mapping units (202, 552) Vessel (250).

  The reading unit (277) is further configured to read the width of the parabolic region (W_par) between the two linear intervals from the received metadata and supply it to the coarse mapping unit (202, 552). An HDR video decoder (250) configured.

  A method of video decoding to generate a continuous image decoder HDR video for the dark subrange (SR_d) of the luma range of the input image color including the darkest input luma value determined by the slope variable (InvBet) Linear interval, a second linear interval for the brightest input luma value in the bright subrange (SR_br) controlled by the second slope variable (InvAlph), and a parabolic interval between the two linear intervals The output luma (Y'o) supplied to the multiplication of the preferred non-linear RGB color representation (R's, G's, B's) of the input color during color conversion by applying a three-interval lightness grading curve ).

  Configured to convert an input color of a pixel of an input image (Im_in) to an output color (Y′UV) of a pixel of an output image (IMED), and the input image has a second luminance dynamic range (DR_2) The output image has a first luminance dynamic range (DR_1), the peak luminance of the first dynamic range is at least twice lower than the peak luminance of the second dynamic range, or vice versa, and the slope variable ( A linear interval for the dark subrange (SR_d) of the luma range of the input image color including the darkest input luma value determined by InvBet), and a bright subrange (SR_br) controlled by the second slope variable (InvAlph) Includes a second linear interval for the brightest input luma value at and a parabolic interval between the two linear intervals Image color processing apparatus comprising a coarse mapping unit configured to apply a section brightness re grading curve (503) comprises a (200), HDR video encoder (501).

  An image color processing device (200) is configured to apply a three-section curve to a color representation of an input color in a non-linear domain, the color components of which are determined by a non-linear function based on linear red, green and blue additive color components An HDR video encoder (501), characterized in that it is defined.

  An HDR video encoder (501), wherein the image color processor (200) is configured to apply a three-section curve to linear red, green and blue color representations of the input color.

  An HDR video encoder (501), wherein the image color processor (200) is configured to determine an output color with a representation that includes a non-linear luma (Y'o) related to the luminance of the output color by a non-linear function.

  The image color processing device (200) is configured to determine an output color with a representation defined by standard dynamic range video coding, and the output luma (Y'o) color component is set to Rec. 709 HDR video encoder (501), characterized by being defined by an optical-electrical transfer function or square root.

  An HDR video encoding method for generating an HDR image set that is encoded into a low dynamic range image, wherein an input color of a pixel of an input image (Im_in) is converted to an output color (Y ′) of a pixel of an output image (IMED) UV), the input image has a second luminance dynamic range (DR_2), the output image has a first luminance dynamic range (DR_1), The dark subrange of the luma range of the input image color, where the peak luminance is at least twice lower than the peak luminance of the second dynamic range or vice versa, including the darkest input luma value determined by the slope variable (InvBet) SR_d) and a bright sub-range (S) controlled by a second slope variable (InvAlph) Applying a three-interval lightness grading curve comprising a second linear interval for the brightest input luma value in _br) and a parabolic interval between the two linear intervals, comprising the step of converting .

  Code that, when executed by a processor, applies all the steps defined in any one of the above method claims, some pixelated color component data, and metadata specifying a three-section curve Ie, decoding and reconstructing the received HDR image (as LDR), typically by receiving at least two or preferably five parameters (alpha, bet, W, Wh_o, B_o) as described above A computer readable memory comprising: a signal comprising information that causes the receiver to function technically, whether on memory or other technical means.

  These and other aspects of any variation of the method and apparatus according to the present invention will become apparent and elucidated with reference to the implementations and embodiments described hereinafter and with reference to the accompanying drawings, in which: Serves only as a non-limiting specific example to illustrate a more general concept, dashed lines are used to indicate that components are optional, and non-dashed components are not necessarily required is not. Also, the dashed line is used to indicate that an element described as essential is hidden inside the object, or for intangibles such as object / region selection, value level indication on a chart, etc. You can also

FIG. 1 schematically illustrates a possible color processing device previously invented and patented by the applicant for performing dynamic range conversion including local color processing, which color processing typically occurs in an input image; At least including changing the brightness of the object, which elucidates some concepts, the preferred embodiment of the present invention requires the necessary changes in the nonlinear RGB color space and typically its corresponding luma Y ′. Applied in addition. FIG. 1 schematically illustrates an example of a system configured to perform dynamic range conversion for a system capable of parametrically decoding and generating HDR images from received LDR images, ie, an HDR scene The HDR look is also received via metadata characterizing a color conversion function for deriving the HDR look image from the received LDR look image, but only the LDR image pixel color is actually sent to the receiver and received. . FIG. 4 is a diagram illustrating the encoding side function shape of one typical three-section coarse first luma mapping for encoding LDR from HDR image pixel color data, where the input is, for example, in the HDR linear luminance domain and the output The (vertical axis) is typically in the LDR square root LDR luma domain, for example. Several examples illustrate typical technical and artistic issues related to HDR content that need to be visible even on a legacy 100 nit peak brightness (PB) SDR display installation base in lower dynamic range displays FIG. FIG. 2 schematically illustrates a little more exemplary video encoding system in which Applicants apparatus and method embodiments are advantageously used.

  FIG. 1 illustrates a system for encoding (at least) two graded images (HDR, eg, 5000 nit PB, and standard SDR LDR with PB = 100 nit) and rendering them on a display with a significantly different dynamic range (PB). One possible color conversion and in particular its color conversion core unit. One of ordinary skill in the art can perform a calculation on a calibrated display to see what look the human grader is actually creating, while at the same time his own preference for the grading function in the encoding function toolkit. A content creation side that specifies optimum parameter values according to the receiver, and a receiver that includes the apparatus in a video reception and color processing device such as a set-top box, BD player, computer, display itself, or cinema business system, for example. And understand that this system can exist in both.

  Describe a receiver that already has data specifying two gradings (HDR and LDR, which can then be further optimized by further calculations for any intermediate dynamic range MDR display such as PB = 800 nit) .

  Thus, according to our new encoding principle, the receiving device can be connected, for example, on a Blu-ray disc or via an Internet connection to a video server or from another device via an HDMI cable. There is actually only one actual encoded image Im_in_HDR received (e.g. classical 10-bit HEVC encoding but naturally decoding into a normalized [0,1] image Is possible). This then needs to be calculated into LDR grading, for example, because the LDR display is connected and requires a correctly graded LDR image (eg, viewers can view the HDR display in the living room) Will continue to watch on the portable pad PC in bed).

  In order to be able to perform color conversion, the color conversion device also requires a parameter (CF) that specifies a function. Those skilled in the art will appreciate that, for example, a parabola can be specified by the start and end points, the slope of the start of the line, the curvature, and the like.

  Typically, this includes not only saturation control of the HDR to LDR mapping, but also mappings that affect at least the brightness of the output object (but mathematically by scaling the linear RGB color components multiplicatively, That luminance mapping is typically applied).

  FIG. 2 shows in more detail how the luminance regrading can be preferably performed.

  Assume that an SDR image, ie, encoded Y′UV (or Y′CbCr) is input. They can be matrixed into the scaled RGB components R'sG'sB's of the input image pixels. These are assumed, for example, to be in the square root luma domain (ie, the corresponding linear color component appears by the square). The corresponding Y'_LDR luma is easily separated from the Y'UV representation. It can be seen in FIG. 4B that these R′sG′sB ′s values are actually a scaled version of the finally obtained HDR color components (R′o, G′o, B′o). As can be seen, in FIG. 4B, one color of both LDR and HDR grading is shown in the RGB gamut normalized to the same maximum luma = 1.0 (eg, Rec. 2020 primary). If a motorcycle has to be rendered on an LDR display when driven with an LDR image with the same absolute brightness (5 nits) it has on an HDR display when driven with an HDR image, this is This means that the relative LDR luma, normalized to 1, ie normalized to 1023 for 10-bit codes) needs to be higher. That is, the color conversion between the color components R′o, G′o, B′o and R ′s, G ′s, B ′s or vice versa, and the corresponding luminance or luma Y′_HDR and Y ′. Corresponds to _LDR scaling, which is implemented by multiplier 225. In some embodiments, R ′s, G ′s, B ′s are calculated directly from the input Y′UV color representation, while in other embodiments, the different R applied by the color converter 223. There are additional color transformations included to reach the 's, G's, B's values (all dashed portions of the drawing are not simpler embodiments on the market, but for some other embodiments) Note that is optional.) This applies further lightness and / or color fine-tuning, for example some look adjustment.

  The reading unit (277) then allows the coarse mapping unit 202 to reconstruct the HDR image from the appropriate function that was used to encode the HDR / LDR look image pair together, ie, the received LDR image. For example, passing parameters or supplying functions as LUTs. The accurately scaled luma Y′o obtained by applying (at least) three-interval curve mapping is then used as an input multiplier to multiply each of the three scaled color components to produce the correct output color. This is generated and further converted by the color format unit 226 into another color representation.

  A preferred embodiment of the coarse mapping unit (202) applies a function such as that shown in FIG. The position of the parabola section is determined by encoding the start and end luma values, but the parabola can also be encoded as its width as in FIG. The input is, in this example, without limitation, the luminance of the linear RGB representation, i.e. u_HDR_in, and the output TU_LDR_out can be fine-tuned later by the custom shape curve of unit 203 in the application-specific system if desired, Alternatively, it can be sent to a multiplier to obtain the correct HDR color for this pixel being processed.

In this embodiment, the basic “parabolic” tone mapping curve has three intervals:
A dark interval through (0,0) controlled by a parameter of slope bet or bg (base gain);
A light interval through (u_max, TU_max) with slope alpha or dg (differential gain);
A parabolic section connecting the two with a width xp (a parabola of x width).

Without a parabola, the two linear intervals are the points um = (TU_max−dg * u_max) / (bg−dg),
TUm = bg * um = TU_max- (u_max-um) * dg
Connect in

  Adding a parabola centered on this (um, TUm) creates a continuously differentiable curve, which must start with slope = bg and end with slope = dg. From the mathematical calculation it is obtained that only one degree of freedom (out of three), ie the parabola width xp is left.

Depending on the width, the y value at u = um is
From TU = TUm at up = 0,
TU = TUm-delta_TU = TU-up * (bg-dg) / 8.

This relationship can be reversed to calculate up from delta_TU:
up = 8 * delta_TU / (bg-dg)

  Thus, typically, starting from up = 0, the maximum distance delta_TU between the bending curve and the reference luminance mapping curve (scatter plot) can then be examined and up can be calculated therefrom.

  Thus, in this embodiment, the width of the parabolic interval (typically between 0.0 and 1.0) is the slope of the base gain (eg, a typical value is 0.5 for bright images). And 1.0 for darker images) and the slope of the brightest input range (typically between 0.0 and 0.25) in addition to any receiving device The third parameter for designating this function shape.

  In FIG. 4, the future HDR system (eg, connected to a 1000 nit PB display) needs to be able to handle correctly, i.e., regardless of what display is connected or expected to be connected. Only two examples of the many possible HDR scenes that need to be able to create appropriate brightness for all objects / pixels in the final rendered image are shown. For example, ImSCN1 is a sunny outdoor image of a cowboy movie showing in Texas, and ImSCN2 is a night image. What makes HDR image rendering different from its usual aspect in the LDR era, which has just finished (or is actually scheduled to start in the next few years), is that LDR has such a limited dynamic range. (Approx. PB = 100 nit, and black level ± 1 nit, or higher in brighter viewing environment due to screen reflection), mainly reflecting only the reflectance of the object (this is a good white 90% and good black 1%). Therefore, the object had to be displayed independently of its illumination, and it was not possible to faithfully display all the very good and sometimes very high-contrast illuminations of a possible scene. In practice, it meant that very bright sunny scenes had to be rendered with the same display brightness (0-100 nits) as the overcast rainy day scene. Also, even night scenes cannot be rendered too dark, or viewers are not able to identify the darkest part of the image well, so they are also rendered over a range of 0-100 nits. Is done. Therefore, conventionally, the night scene must be colored blue so that the viewer can understand that he is not watching the daytime scene. Now, of course, in real life, human vision also adapts to the amount of light available, but not so much (most people recognize that it has become darker in real life). Therefore, it is desirable to render an image using all the magnificent local lighting effects that can be artistically designed internally, at least with an available HDR display.

  However, it is still necessary for some people to downgrade a wonderful new HDR movie to its limited LDR display (the range is shown to the right of FIG. 4 but not to scale) Does not change the fact that there is.

  Thus, on the left side, we identify the object brightness we want to see in a master HDR grading of 5000 nitPB (ie optimized for rendering on a 5000 nitPB display). If it is not just an illusion, but wants to convey the true feeling that the cowboy is in a bright sunlit environment, the brightness needs to be rendered, for example, near 500 nits. From these examples alone, splicing all object puzzles with a smaller LDR luminance range is ideally a simple compression (eg, mapping a HDR PB to a LDR PB by a linear function, thereby We can already get the feeling that it is not a problem of mapping all low luminance. Conversely, two examples of different luminance mapping-behavior classes are given. In daytime scenes, if you want to calculate HDR images from received LDR images, specifically, cowboys rendered near 18 nits of LDR mid-gray are mapped to 500 nits in HDR (ie, approximately 30 nits). Double the increase in brightness), it is possible to actually apply a stretching function that stretches all the brightness. However, you don't want to do that in the night scene, or it becomes tremendously bright on the HDR monitor (if you actually jump into the details, some image details may cause the brain to You can still imagine watching the scene, but if you really want the spectacular, high quality HDR rendering that is now possible, it renders far from ideal). In this ImSCN2, we want the brightness of all dark objects at night to be the same on the two displays (and all displays in the intermediate PB). Rather, it is the light of the lighting pole that may be brightened to very bright brightness in the HDR image, and may be the moon. Therefore, the shape of the luminance mapping function is greatly different. If you have both of these two typical image aspects together, for example in a single image taken in a cave and looking at a sunny outdoors through a small hole, you can actually design a complex intensity mapping curve, You may want to obtain both LDR and HDR object brightness according to your artistic desires. How such a situation typically occurred in the LDR era was simply clipping everything outside the cave to white. Or in the LDR era, we were only thinking about what the camera took as a relative brightness, regardless of its meaning, and what it implied to ultimately render on any display, Part of the image was often too dark. For example, if you walk down the corridor and see the sun coming in, the places that are hit by the sun look very bright. Other parts of the corridor are relatively dark, but this does not mean that those who walk there will see them appear darker than usual (actually because of the additional lighting, even in shadows, the sun It looks somewhat brighter than if you move backwards). However, LDR rendering with these sunny colors near white can only render shadows in the hallway too dark, because otherwise it is the only thing possible in a limited range Because it renders shadows with reasonable brightness, but everything in the sun is clipped beyond the maximum luma code, eg, 255 and rendered at 100 nits.

  Thus, optimal LDR rendering of such scenes is a complex design issue, but at least now with HDR displays, sunny parts can be rendered realistically, ie beyond a certain brightness. For example, when the viewing environment corresponds to approximately 200 nits, the shadow portion of the image can be rendered near 200 nits. Further, a portion exposed to sunlight can be rendered at, for example, 2000 nits according to the PB of the display. It always looks much more realistic than a corridor or clip that is too dark, if not always the same relative amount as real life above the shadow brightness.

  However, the reader should consider all of this complexity, specifically the many types of images that may be encountered, and at least some higher quality HDR ranges (eg PB = 10,000 nits) and SDR 100 nit ranges. Understand why the large differences require a system that allows for the precise specification of different pixel colors and in particular their brightness. Applicants also specifically specify, to the extent that content creators want to do so, at least for those who want it, at least for how any other dynamic range image is calculated from the received image. He had a philosophy that should be influenced to some extent necessary.

  FIG. 5 shows a possible integration of our basic brightness changing device (or method) in one typical complete system or chain for communication and consumption of HDR images. Those skilled in the art will understand how graders and the like can use UI components to change the shape of any function, for example the parameters that characterize them, according to their needs or desires. Let's go. Example of mode ii (the LDR image downgraded from the master HDR image MAST_HDR created by the content creator from its own RAW capture is actually communicated and then reconstructed to approximate the MAST_HDR image if needed on the receiving side) However, the embodiment of the system and our device is a mode in which the device applies a luminance downgrade at the receiver when the MAST_HDR image is actually communicated and an LDR image is required to feed the SDR display. I want to emphasize that it can also be used in i-motion. Each of these received LDR or HDR images can also be converted to an image with a different dynamic range, such as 1499 nitPB. Also, an embodiment of the device may be incorporated into a creating device, eg, an encoder, for example, what happens to a color grader at the receiving side, and how an LDR image calculated from MAST_HDR by a given function. The device and method can also be used in any intermediate location transcoder, such as a local content distributor viewing booth, for example.

  This exemplary scheme video encoder 501 obtains an input image IM_IN via input 509, which is assumed to be a master HDR grading already artistically created for ease of explanation. It may be an HDR image from a RAW image feed, which has little real-time obstruction and probably needs to be minimally color processed with a few dials during shooting.

  Color processing calculated for the pixel color by the color processing unit may be included, for example, a saturation change that reduces the saturation, in the LDR transform, for example a brighter color in a stained glass window, There are things that can be additionally brightened by pushing into the narrow top of the LDR color gamut near white, but the details are not described. The luminance mapping unit 503 then does various things that any of our device embodiments do as shown in FIG. 2 and is determined for the current image set, eg, by user interface interaction or previously Load the determined function from the encoded metadata, perform brightness uniformity, and tripartite curves, and if applicable, a function CC of some optimal shape. Some embodiments determine the shape of the three-part curve by having the image analysis unit 566 analyze the characteristics of the image, such as the location of most of the pixel brightness, the size and scattering of highlight patches, and the like. The function input means 508 can be understood by the reader as, for example, a typical color grading tool, or a connection to a database that stores at least one function, or a connection to a remote human grader. In this example, the intermediate image IMED is currently represented by pixel luminances distributed in the LDR range of 0 to 100 nit and the corresponding Rec. 709 luma (ie, Y'oUV as shown) and is encoded by the image or video encoding unit 505 with a typical legacy LDR encoding technique such as HEVC. The reason for this is that it “looks” like a normal LDR image, at least for subsequent technologies, such as the passing image distribution pipeline, although it is actually an HDR image encoding of the HDR scene. Because. This is communicated to any receiver by also sending the color conversion function (or its inverse) used to generate the LDR image from the master HDR image, which is an HDR image instead of the normal LDR image. As well as allowing the receiver to reconstruct the approximation of the MAST_HDR image by applying the received inverse function to the received LDR image. Thus, the encoded image or video LDR_oenc actually acts as a normal LDR video for the rest of the system and travels through some communication means 510, for example, Such as an internet connection or physical memory transported to any consumer or professional (eg movie) location.

  At the receiving end, this encoded output image (LDR_oenc) becomes the input image or video LDR_ienc (which may have undergone further transformation, but for purposes of explanation, the same image that has been looped through) Is assumed to be). When using an HDR communication system in mode i with LDR_oenc, a function with a shape different from that in mode ii is used to give different image brightness and statistics to the image, but it is immediately noticed that HEVC encoding and the like are both performed. Should.

  The video decoder 550, via its input 556, is created by an image and some other person, such as metadata MET (F) encoding the function, specifically a color grader or a technical director of life production, for example. Get both the best custom curve selected on the side. The image or video decoding unit (555) decodes the HEVC video, which is then color processed (ie, at least approximately HDR) by a luminance mapper 552 that embodies any of our apparatus or method embodiments. Apply the appropriate inverse tripartite function to reconstruct the image). Finally, a correctly graded REC_HDR, eg, a 5000 nit PB image, can be sent to a display 580, eg, ideally a 5000 nit display (if the PB does not match between the HDR content and the display, for example, embodied in an STB. This video decoder has already displayed the image with the appropriate color conversion up to the required, eg 2500 nit display PB, or the display does it internally, the proprietary of the device / method we have taught Do by having a version). Of course, if properly graded content is supplied to the legacy SDR 100 nit display, the video decoder 550 supplies it with the LDR image LDR_rnd, which in this example is simply received at the decoder that does not require further color conversion. If an HDR image is received in an LDR HEVC container, the video decoder 550 further performs an appropriate downgrade according to any of our device / method embodiments.

  The algorithmic components disclosed in this document may actually be implemented as hardware (eg, part of an application specific IC) or as software running on a dedicated digital signal processor or general purpose processor (fully or partially) To be realized. They are semi-automatic in the sense that at least some user input exists (eg, at the factory or consumer input, or other human input).

  Which components are optional improvements and can be implemented in combination with other components, and how the (optional) steps of the method correspond to the respective means of the apparatus and vice versa Will be understood by those skilled in the art from this proposal. The fact that several components are disclosed in a particular relationship in the present invention (eg, in one diagram of a configuration) is based on the same inventive concept disclosed herein for patenting. This does not imply that other configurations are not possible as an embodiment. The fact that, for practical reasons, only a limited range of examples is given does not mean that other variants cannot fall within the scope of the claims. In practice, the components of the present invention can be embodied in different variations along any chain of use, for example, all variations on the producer side, such as an encoder, are decoders, etc. Similar or corresponding to the corresponding device on the consumer side of the disassembled system, and vice versa. Some components of the embodiments are encoded as specific signal data in a signal that is transmitted or further used for coordination, etc., in any transmission technique between the encoder and decoder. . The word “apparatus” in the present application is used in the broadest sense, ie a group of means enabling the realization of a specific purpose, and thus for example IC (a small part of), dedicated equipment (eg A device having a display), or part of a networked system. A “configuration” or “system” is also intended to be used in the broadest sense, so that, among other things, a single physical purchaseable device, part of a device, part of a cooperating device (part of ).

  The notation of a computer program product is that a general purpose or special purpose processor enters a command into the processor after a series of loading steps (which includes intermediate conversion steps, eg, conversion to intermediate language and final processor language). It should be understood to encompass any physical realization of a set of commands that allows performing any of the characteristic functions of the invention. Specifically, a computer program product is implemented as data on a carrier such as a disk or tape, data residing in a memory, data traveling via a wired or wireless network connection, or program code on paper. . Apart from the program code, characteristic data necessary for the program is also embodied as a computer program product. Such data is (partially) supplied in any manner.

  Any data that can be used in accordance with the present invention or any philosophy of this embodiment, such as video data, is also embodied as a signal on a data carrier, which is removable memory such as an optical disk, flash memory, removable hard disk, A portable device writable via wireless means.

  Some of the steps necessary for the operation of any presented method are computer program products such as data input and output steps, well-known and typically built-in processing steps such as standard display driving, or ( Instead of being described in any unit, apparatus or method described herein (along with details of an embodiment of the invention), it already exists within the functionality of the processor or any apparatus embodiment of the invention. The resulting product and similar products, such as specific new signals included in any step of the method or any subpart of the apparatus, and any new use of such signals, or any relevant Protection against the method is also desired.

  It should be noted that the above embodiments are illustrative rather than limiting of the present invention. Not all of these options have been described in detail for the sake of brevity, if one skilled in the art can easily implement the examples presented to other areas of the claims. Apart from combinations of elements of the invention combined in the claims, other combinations of elements are possible. Any combination of elements can be realized in a single dedicated element.

Any reference sign between parentheses in the claim does not limit the claim and is not any specific symbol in the drawings. The word “comprising” does not exclude the presence of elements or aspects not listed in a claim. The word “a” or “an” preceding an element does not exclude the presence of a plurality of such elements.

Claims (15)

An image color processing apparatus that converts an input color of a pixel of an input image having a first luminance dynamic range into an output color of red, green, and blue color components of a pixel of the output image having a second luminance dynamic range. An HDR video decoder comprising:
The peak luminance of the first luminance dynamic range is at least twice lower than the peak luminance of the second luminance dynamic range, or vice versa,
The image color processing device includes a linear interval for the dark subrange of the luma range of the input image color including the darkest input luma value determined by the slope variable, and a lightest subrange controlled by the second slope variable. An HDR video decoder comprising a coarse mapping unit that applies a three-interval lightness grading curve including a second linear interval for a bright input luma value and a parabolic interval between the two linear intervals.   The HDR video decoder according to claim 1, wherein the image color processing device applies the three-section lightness grading curve to a low dynamic range luma.   The image color processing apparatus outputs an output luma related to the luminance of a color as an output result obtained by applying the three-section lightness grading curve to the input color by a power function of an index 1 / N including a case where N is 2. The HDR video decoder according to claim 1 or 2, which is generated as a result of applying the three-section lightness grading curve.   2. The output color is determined by the image color processing device comprising a multiplier that applies a multiplication with an output luma as a multiplication factor to a preferred non-linear color representation of the color of the pixel currently being processed. The HDR video decoder as described in any one of thru | or 3.   The image color processing device has a shape close to a square root function and is technically defined from linear R, G, and B color components by a nonlinear function that is a power function of an exponent 1 / N where N is an integer value. The HDR video decoder according to claim 1, which obtains a color representation of 6. The HDR video decoder according to claim 1, comprising a reading unit that reads the slope variable and the second slope variable from received metadata and supplies them to the coarse mapping unit. 7. .   The HDR video decoder according to claim 6, wherein the reading unit further reads the width of a parabolic region between the two linear intervals from received metadata and supplies it to the coarse mapping unit.   A method of video decoding to generate a continuous image decoder HDR video, a linear interval for a dark subrange of a luma range of input image colors including a darkest input luma value determined by a slope variable; Applying a three-segment lightness grading curve that includes a second linear interval for the brightest input luma value in the bright subrange controlled by a slope variable of two and a parabolic interval between the two linear intervals; Generating an output luma that is provided for multiplication with a preferred non-linear RGB color representation of the color-converted input color. An HDR video encoder comprising an image color processing device for converting an input color of a pixel of an input image having a second luminance dynamic range into an output color of a pixel of an output image having a first luminance dynamic range. ,
The peak luminance of the first luminance dynamic range is at least twice lower than the peak luminance of the second luminance dynamic range, or vice versa,
The image color processing device includes a linear interval for the dark subrange of the luma range of the input image color including the darkest input luma value determined by the slope variable, and a lightest subrange controlled by the second slope variable. An HDR video encoder comprising a coarse mapping unit that applies a three-interval lightness grading curve including a second linear interval for bright input luma values and a parabolic interval between the two linear intervals. The HDR video encoder according to claim 9, wherein the image color processing device applies the three-section lightness grading curve to a color representation of the input color in a non-linear domain.
An HDR video encoder, characterized in that its color component is defined by a non-linear function based on linear red, green and blue additive color components.   10. The HDR video encoder according to claim 9, wherein the image color processing device applies the three-interval lightness grading curve to linear red, green and blue color representations of the input color.   The HDR video encoder according to any one of claims 9 to 11, wherein the image color processing device determines the output color by an expression including a nonlinear luma related to luminance of the output color by a nonlinear function. 13. The HDR video encoder according to any one of claims 9 to 12, wherein the image color processing device determines the output color with a representation defined by standard dynamic range video encoding.
The output luma color component is Rec. 709 HDR video encoder, characterized by being defined by an optical-electrical transfer function or square root. A method of HDR video encoding that generates an HDR image set that is encoded into a low dynamic range image comprising:
The input color pixel of an input image having a second luminance dynamic range, comprising the steps of converting the output color pixel of an output image having a first luminance dynamic range, the peak luminance of the first luminance dynamic range There at least 2-fold step is lower or vice versa from the peak luminance of the second luminance dynamic range,
The converting step includes a linear interval for the dark subrange of the luma range of the input image color including the darkest input luma value determined by the slope variable, and the brightest in the bright subrange controlled by the second slope variable. Applying a three-segment lightness grading curve comprising a second linear segment for the input luma value and a parabolic segment between the two linear segments.   A computer readable memory comprising code that, when executed by a processor, performs all the steps of the method according to claim 8 or 14.

Images