Image brightness adjustment for perceptually uniform electro-optical transfer functions.

Abstract

The image processing device includes a receiver 401 that receives an image including a first pixel brightness encoded according to a perceptually uniform electro-optical transfer function (EOTF). A converter converts this to a second pixel brightness encoded according to the EOTF, which represents a logarithmic mapping from optical light values ​​to a second pixel brightness, and an image processor circuit 411 applies a brightness adjustment process to the second pixel brightness. The converter 410 includes first converters 601, 605 that generate intermediate pixel brightnesses by applying a logarithmic function to the first pixel brightness. A second converter 603 generates the intermediate pixel brightnesses by applying a second logarithmic function to the output value of the perceptually uniform EOTF for the first pixel brightness divided by a divisor equal to a power of the first pixel brightness having a value greater than one. A combiner combines the intermediate pixel brightnesses to generate the second pixel brightness.

Description

[Technical Field]

[0001] The present invention relates to image processing, particularly but not exclusively to brightness adjustment processes such as tone mapping for high dynamic range (HDR) images. [Background technology]

[0002] A few years ago, a novel approach to high dynamic range (HDR) video coding was introduced, notably by the present applicant (see, for example, WO2017 / 157977).

[0003] Video coding is generally primarily concerned with color codes (e.g., luma and two chromas per pixel) to represent an image, or only with creating or, more precisely, defining color codes. This is somewhat different from knowing how to optimally display an HDR image. (For example, in the simplest case, one might simply use a highly nonlinear optical-electrical transfer function (OETF) to convert a desired luminance into, say, a 10-bit luma code, and vice versa, use an inverse electro-optical transfer function (EOTF) to convert these video pixel luma codes into display luminance, mapping the 10-bit electrical luma code to display optical pixel luminance, but more complex systems can deviate in several directions, particularly by decoupling the coding of an image from the specific use of the coded image.)

[0004] Coding and processing HDR video stands in stark contrast to the way traditional video techniques were used, by which all video was encoded until recently, and which is now called standard dynamic range (SDR) video coding (also known as low dynamic range video coding, or LDR). SDR began in the analog era as PAL or NTSC and transitioned to Rec. 709-based coding, such as MPEG-2 compression, in the digital video era.

[0005] While sufficient technology for communicating moving images in the 20th century, advances in display technology that exceeded the physical limitations of the electron beam of 20th-century CRTs, namely global TL backlit LCDs, made it possible to display images with significantly brighter (and potentially dimmer) pixels than conventional displays, thereby necessitating the ability to code and create such HDR images.

[0006] In fact, for various reasons, it was first necessary to start with much brighter and, in some cases, darker image objects that could not be coded by the SDR standard (8-bit Rec. 709) in order to invent ways to make these increased brightness range colors technically representable. From there, one by one, all the rules of video technology had to be rethought and often reinvented.

[0007] The Rec. 709 SDR luma code definition could only encode a luminance dynamic range of approximately 1000:1 (at 8-bit or 10-bit luma) due to its approximately square-root OETF function shape: Y_code=power(2,N) * sqrt(L_norm), where N is the number of bits in the luma channel and L_norm is a normalized version of physical luminance between 0 and 1.

[0008] Furthermore, in the SDR era, because absolute display luminance was not defined, in practice, the maximum relative luminance L_norm_max=100% or 1 was mapped via the square-root OETF to the maximum normalized luma code Yn=1 (e.g., equivalent to Y_code_max=255). This has some technical differences compared to creating absolute HDR images (i.e., an image pixel coded to display as 200 nits would ideally (i.e., whenever possible) display as 200 nits on all displays, not at significantly different display luminances). In the relative paradigm, a coded pixel luminance of 200 nits would display as 300 nits on a brighter display, i.e., a display with a brighter maximum displayable luminance PL_D (a.k.a., display maximum luminance), and would display as, say, 100 nits on a less capable display. Note that absolute encoding can also work with normalized luminance representations and normalized 3D color gamuts, in which case 1.0 uniquely means, say, 1000 nits.

[0009] On displays, such relative images have typically been displayed somewhat heuristically by mapping the brightest luminance in the video to the brightest displayable pixel luminance (this is done automatically, without further luminance mapping, via the electronic driving of the display panel by the maximum luma Y_code_max). So if you buy a 200 nit PL_D display, whites will appear twice as bright as on a 100 nit PL_D display, but this will give you a brighter, more visually enjoyable, and somewhat more beautiful version of the same SDR video image, considering factors like eye adaptation that were previously thought to be of little importance.

[0010] Conventionally, today, when talking about SDR video images (in an absolute framework), there is usually (e.g., agreed upon according to standards) a video peak luminance of PL_V=100 nits. Therefore, in this application, we consider the maximum luminance of an SDR image (or SDR grading) to be exactly that, or generalized at approximately that value.

[0011] Grading in this application is intended to mean either an activity or a resulting image in which pixels are given brightness as needed, for example, by a human color grader or an automaton. For example, when viewing an image (e.g., designing an image), there are multiple image objects, and ideally, one would like to give the pixels of those objects a brightness that is spread around an average brightness that is optimal for that object and the scene, also taking into account the overall image. For example, if an image's capabilities are such that the brightest codable pixel in the image is 1000 nits (the maximum brightness of the image or video, PL_V), one grader might choose to give the pixel an explosion brightness value of 800-1000 nits to make the explosion appear very powerful, while another filmmaker might choose an explosion brightness of 500 nits or less, for example, so that it does not overpower the rest of the image at that time (of course, both situations are technically possible).

[0012] The maximum brightness of an HDR image or video can vary widely and is typically communicated along with the image data as metadata about the HDR video or image (common values ​​are, for example, 1000 nits, 4000 nits, or 10,000 nits (non-limiting), and typically, an HDR image is said to have a PL_V of at least 600 nits). If a video creator chooses to define their image as PL_V=4000 nits, they can of course choose to create brighter bursts, but relatively they will not reach the 100% level of PL_V, but may be up to, for example, 50% for such a high PL_V definition of the scene.

[0013] An HDR display may have a maximum capability, i.e., a highest displayable pixel luminance, such as 600 nits, 1000 nits, or N x 1000 nits (starting with lower-end HDR displays). The maximum luminance or peak luminance of that display, PL_D, is separate from the maximum luminance of the video, PL_V, and the two should not be confused. Video creators typically cannot create optimal video for every possible end-user display (i.e., the capabilities of the end-user display are optimally used by the video, and (ideally) the maximum luminance of the video does not exceed the maximum luminance of the display, but is not lower either; i.e., some part of the video image should have at least some pixels where the pixel luminance L_p = PL_V, which also entails that PL_V = PL_D in the continuous optimization for any particular display).

[0014] The creator makes several decisions (e.g., what content to capture, how to capture) and typically creates a video with a high PL_V to accommodate at least the highest PL_D display of the intended audience today, and possibly the intended audience in the future when higher PL_D displays emerge.

[0015] A secondary question then arises: how to optimally display an image with a peak luminance PL_V on a display with a (sometimes much) lower display peak luminance PL_D, known as display adaptation. In the future, there will likely be displays that require images with a lower dynamic range than, say, a 2000 nit PL_V image, as created and received over a communications medium. In theory, displays are always regradable; that is, the luminance of image pixels can be mapped to make them displayable through internal heuristics. However, if video creators exercise sufficient care in determining pixel luminance, they can also show how to display images at lower PL_D values. Ideally, it would be beneficial for displays to largely adhere to these technical desiderata.

[0016] The situation is more complicated when it comes to the darkest displayable pixel luminance, BL_D. While some of this may be due to fixed physical characteristics of the display, such as LCD cell leak light, even with the best displays, what a viewer ultimately perceives as a distinct darkest black also depends on the lighting in the viewing room, which is not a well-defined value. This lighting can be characterized as an average illuminance level, for example, in lux, but for video display purposes, it is more elegantly characterized as a minimum pixel luminance. This also involves the human eye, which typically perceives darker pixels in a stronger way than bright or medium luminance. This is because the human eye may perceive many high-luminance pixels, which can reduce the relevance of darker pixels, especially their absolute luminance. However, the eye may not be the limiting factor, for example, when viewing an image of a scene that is mostly dark but is masked by ambient light in front of the display screen. If we assume that humans can only perceive a noticeable difference of 2%, there is a darkest drive level (or luma), b, above which the next darker luma level can be seen (i.e., displaying another 2% more luminance level, or X% higher displayed luminance).

[0017] In the LDR era, we didn't care about the darkest pixels at all. We mainly cared about the average luminance, which was about 1 / 4 of the maximum PL_V=100nit. When an image was exposed around this value, everything in the scene looked bright and colorful, except for clipping in the bright parts of the scene above the 100% maximum. For the darkest parts of the scene, if they were important enough, images were created that were captured with a good amount of base lighting in a recording studio or filming environment. Even if parts of the scene looked bad (for example, because they were buried in code Y=0), it was considered normal.

[0018] Therefore, if nothing more is specified, it can be assumed that the blackest black is zero, or in fact something like 0.1 or 0.01 nits. In such situations, engineers place more importance on the above-average brighter pixels of the coded and / or displayed HDR image.

[0019] In terms of coding, the difference between HDR and SDR is not only physical (more different pixel luminances can be displayed on a larger dynamic range capable display), but also technical, potentially involving a different luma code assignment function (using the OETF, or in an absolute way the inverse of the EOTF), and further technical concepts such as additional dynamically changing (per image or per set of temporally consecutive images) metadata that specifies how to re-grade the pixel luminances of various image objects to obtain an image with a secondary dynamic range different from the starting image dynamic range (typically the two luminance ranges end with peak luminances that differ by a factor of at least 1.5).

[0020] Simple HDR codecs have been introduced to the market. For example, the HDR10 codec is used to create the recently released Black Jewel Box HDR Blu-ray. This HDR10 video codec uses a logarithmic rather than square-root function as the OETF (inverse OETF), i.e., the so-called perceptual quantizer (PQ) function standardized in SMPTE 2084. Rather than being limited to 1000:1 as in the Rec. 709 OETF, this PQ OETF allows for a much larger (ideally visible) range of luminance, sufficient for practical production of HDR video, i.e., a luma between 1 / 10,000 nit and 10,000 nit.

[0021] Note that readers should not simplistically confuse HDR with a large number of bits in the luma codeword. This applies to linear systems like the number of bits in an analog-to-digital converter, and indeed the number of bits is the base 2 logarithm of the dynamic range. However, the code assignment function can have a highly nonlinear shape, so in theory, you could define HDR images with only 10 bits of luma (8 bits per color component HDR image) however you wanted. This offers the advantage of reusability of systems already in place (e.g., ICs with a specific bit depth, or video cables, etc.).

[0022] After luma calculation, there are 10 bit planes of pixel luma Y_code, to which two chrominance components Cb and Cr per pixel are added as chrominance pixel planes. Further down the line, this image can be treated as if it were a conventional, mathematically compressed (e.g., MPEG-HEVC compressed) SDR image. The compressor does not need to consider pixel color or luminance.

[0023] However, the receiving device, e.g., a display (or indeed a decoder thereof), typically needs to perform a correct color interpretation of the {Y,Cb,Cr} pixel colors, e.g., to display a correct-looking image rather than an image with bleached colors.

[0024] This is typically handled by communicating the three pixelated color component planes together with further image definition metadata that defines the image coding, such as an indication of the EOTF used (assuming without limitation that the PQ EOTF (or OETF) was used), the value of PL_V, etc.

[0025] More advanced codecs may include additional image definition metadata, e.g., processing metadata, e.g., functions (explained in more detail in Figure 2) that specify how to map a normalized version of the luminance of the first image up to PL_V=1000 nit to the normalized luminance of a secondary reference image, e.g., an SDR reference image with PL_V=100 nit.

[0026] To better understand readers who are not familiar with HDR, we will briefly clarify some interesting aspects of Figure 1. Figure 1 shows some typical examples of the many possible HDR scenes that a future HDR system (e.g., connected to a 1000 nit PL_D display) will need to be able to process correctly. While the actual technical processing of pixel colors can be done in various ways and with various color space definitions, the regrading desiderata are shown as absolute luminance mappings between luminance axes spanning different dynamic ranges.

[0027] For example, ImSCN1 is a sunny outdoor image from a Western movie with mostly bright areas. The first thing to understand is that the pixel brightness of any image is usually not a brightness that can actually be measured in the real world.

[0028] Even if there is no further human involvement in the creation of the output HDR image (which serves as a starter image and is referred to as the master HDR grading or image), no matter how simple it may be by adjusting one parameter, the camera will always at least measure the relative luminance in the image sensor due to its iris, so there will always be some step involved to ensure that at least the brightest image pixel falls within the available coding luminance range of the master HDR image.

[0029] For example, the specular reflection of the sun in a sheriff's star might be measured at over 100,000 nits in the real world, which is neither visible on typical near-term displays nor comfortable for a viewer viewing a movie image in a dimly lit room at night. Alternatively, a video creator might determine that 5000 nits is bright enough for the star's pixels, and if this is the brightest pixel in the movie, the video creator could decide to create a video with PL_V=5000 nits. The camera is the only relative pixel brightness measurement device for the raw version of the master HDR grade, but it should also have a high enough native dynamic range (full pixels well above the noise floor) to produce a good image. The pixels in a graded 5000-nit image are typically derived nonlinearly from the raw image captured by the camera. For example, a color grader takes such aspects into account as a typical viewing situation, which is not the same as the actual shooting location, i.e., standing in a hot desert. The best (highest PL_V) image selected to create for this scene, ImSCN1, i.e. the 5000 nit image in this example, is the Master HDR Grade. This is the minimum amount of HDR data required to create and communicate, but it is not the only data communicated for all codecs; some codecs don't even communicate an image at all.

[0030] The availability of such a high encodable brightness range DR_1 (e.g., 0.001 nit to 5000 nit) allows content creators to provide viewers with a better experience of bright appearance, but also dim night scenes (if well graded throughout the film), provided, of course, that the viewer has a corresponding high-end PL_D=5000 nit display. A good HDR film balances the brightness of different image objects not only within a single image, but also over the course of the storyline of the film or of the video material produced in general (e.g., a well-composed HDR soccer program).

[0031] The leftmost vertical axis in Figure 1 shows some of the (average) object luminances one would like to see in a 5000 nit PL_V master HDR grading, ideally targeted at a 5000 nit PL_D display. For example, a movie might want to show a cowboy bathed in bright sunlight with a pixel luminance of approximately 500 nits (i.e., 10 times brighter than a typical LDR display; however, another creator might prefer a slightly less HDR impression, such as 300 nits). This, according to the creator, constitutes the best way to display this Western image, giving the best possible appearance to the end consumer.

[0032] The need for a higher dynamic range of luminance can be more easily understood by considering an image that has fairly dark regions, such as the shadowed corners of the cave image ImSCN3, but also relatively large areas of very bright pixels, such as the sunlit outside world seen through the cave entrance. This creates a different visual experience than, for example, the nighttime image ImSCN2, where only street lights contain areas of high brightness pixels.

[0033] The problem here is that, since at present many consumers still have LDR displays, and even in the future there will be good reasons to create two gradings of a movie instead of the typical single HDR image per coding, it is necessary to define a PL_V_SDR=100nit SDR image that best corresponds to the master HDR image. This is a technical decision that is separate from the technical choice regarding the coding itself, proving, for example, that if you know how to (reversibly) create this secondary image from one master HDR image and the other, you can choose to code and communicate either one of the pair (effectively communicating two images for the price of one, i.e., communicating the pixel color component planes of only one image per video instant).

[0034] Such a reduced dynamic range image, of course, cannot define an object with a pixel brightness of 5000 nits, such as a truly bright sun. The minimum pixel brightness, or deepest black, is also as high as 0.1 nit, rather than the more desirable 0.001 nit.

[0035] Therefore, the corresponding SDR image must be created in a reduced luminance dynamic range DR_2.

[0036] This can be done by an automatic algorithm in the receiving display, which may for example use a fixed luminance mapping function, or may be conditioned by simple metadata such as the PL_V_HDR value and potentially one or more other luminance values.

[0037] However, more complex luminance mapping algorithms can generally be used. However, in this application, without loss of generality, we assume that the mapping is defined by a global luminance mapping function F_L (e.g., one function per image). This defines, for at least one image, how all possible luminances (i.e., e.g., 0.0001 to 5000) occurring in a first image are mapped to corresponding luminances in a second output image (e.g., 0.1 to 100 nits for an SDR output image). The normalization function is obtained by dividing the luminance along both axes by their respective maximum values. In this context, global means that the same function is used for all pixels of an image, regardless of further conditions, such as their location within the image (e.g., a more general algorithm that uses several functions for pixels that can be classified according to several criteria).

[0038] Ideally, the video creator should decide how to redistribute all luminances along the available range of the secondary image (SDR image), since they know best how to sub-optimize for the reduced dynamic range, given the limitations, so that the SDR image still looks at least as good as the intended master HDR image. The reader will understand that actually defining (locating) such object luminances corresponds to defining the shape of the luminance mapping function F_L, the details of which are outside the scope of this application.

[0039] Ideally, the shape of the function should change for different scenes, i.e., the cave scene versus the sunny western scene (a little later in the film), or generally from image to image in time. We call this dynamic metadata (call it F_L(t), where t represents the instant of the image).

[0040] Ideally, then, the content creator would create the best image for each situation, i.e., each potential end-user display, e.g., a PL_D_MDR=800 nit display requiring a corresponding PL_V_MDR=800 nit image, but this is usually too much effort on the part of the content creator, even for the most expensive offline video creation.

[0041] However, applicants have demonstrated that it is sufficient to create (only) two different dynamic range reference gradings of a scene (usually at the extremes, e.g., 5000 nits is the highest required PL_V, and 100 nits is usually sufficient as the lowest required PL_V). This is because all other gradings can be derived automatically from these two reference gradings (HDR and SDR), e.g., via a (usually fixed, e.g., standardized) display adaptation algorithm applied to the end-user display receiving the information of the two gradings. In general, the calculations can be performed in any video receiver, such as a set-top box, a TV, a computer, or film production equipment. The communication channel for the HDR images can also be any communication technology, such as terrestrial or cable broadcast, a physical medium such as a Blu-ray disc, the Internet, a communication channel to a portable device, or professional site-to-site video communication.

[0042] This display adaptation typically involves applying a luminance mapping function to the pixel luminances of, for example, the master HDR image. However, the display adaptation algorithm must determine a luminance mapping function, i.e., a display adaptation luminance mapping function FL_DA, that is different from F_L_5000to100 (the reference luminance mapping function that connects the luminances of the two reference gradings). This is not necessarily trivially related to the original mapping function F_L between the two reference gradings (there are several variations in display adaptation algorithms). The luminance mapping function between a master luminance defined by a PL_V dynamic range of 5000 nits and an intermediate dynamic range of 800 nits will be referred to in this text as F_L_5000to800.

[0043] Here, the display adaptation is symbolically indicated (only for one of the average object pixel luminances) by an arrow that maps the F_L_5000to100 function above the 800 nit MDR image luminance range not to the "simple" expected location, but to a slightly higher location (i.e., in such an image, the cowboy should be slightly brighter, at least according to the selected display adaptation algorithm). So, while a more complex display adaptation algorithm may place the cowboy at a higher location than shown, some customers may be satisfied with the simpler location where the connection between the 500 nit HDR cowboy and the 18 nit SDR cowboy exceeds the 800 nit PL_V luminance range.

[0044] Typically, a display adaptation algorithm calculates the shape of the display adaptation luminance mapping function FL_DA based on the shape of the original luminance mapping function F_L (or reference luminance mapping function, also known as reference regrading function).

[0045] This explanation based on Fig. 1 constitutes a technical desiderata of an HDR video coding and / or processing system, and Fig. 2 illustrates some exemplary technical systems and their components for realizing the desiderata (non-limiting) according to the applicant's codec approach. Those skilled in the art should understand that these components can be embodied in various devices, etc. Those skilled in the art should understand that the examples are presented as pars prototo (parts taken as wholes) for various HDR codec frameworks, merely to gain background understanding of some principles of operation, and are not intended to specifically limit any of the embodiments of the innovative contributions presented below.

[0046] Although possible, the technical communication of two actual different images at one time (HDR and SDR gradings each communicated as three color planes respectively) is expensive, especially in terms of the amount of data required.

[0047] Also, this is not necessary, since if one knows that all corresponding secondary image pixel intensities can be calculated based on the primary image intensities and the function F_L, one can decide at one moment to communicate only the primary image and the function F_L as metadata (and can also choose to communicate either the master HDR image or the SDR image as a representative of both). The receiver knows its (usually fixed) display adaptation algorithm, so it can determine the FL_DA function at its end based on this data (additional metadata can be communicated to control or guide the display adaptation, but is not currently implemented).

[0048] There are two modes for communicating one image per moment and a function F_L.

[0049] In a first backwards compatible mode, an SDR image is communicated ("SDR communication mode"). This SDR image can be displayed directly (without further luminance mapping) on ​​a conventional SDR display, but the HDR display must apply an F_L or FL_DA function to obtain an HDR image from the SDR image (or vice versa, depending on the communicated function variant, i.e., upgrading or downgrading). The interested reader is referred to the following for full details of Applicant's standardized exemplary first mode approach: ETSI TS103 433-1 V1.2.1(2017-08):High-Performance Single Layer High Dynamic Range System for use in Consumer Electronics devices;Part 1:Directly Standard Dynamic Range(SDR)Compatible HDR System(SL-HDR1).

[0050] In another mode, the master HDR image itself is communicated ("HDR communication mode"), i.e., for example, a 5000 nit image and a function F_L that allows for computing a 100 nit SDR image (or other low dynamic range image via display adaptation) from it. The master HDR communicated image itself can be encoded using, for example, a PQ EOTF.

[0051] Figure 2 also shows the entire video communication system. On the transmitting side, we start with the image source 201. This could be anything from a hard disk to a cable output from a television studio etc, depending on whether we have offline created video from an internet distribution company for example, or an actual broadcast.

[0052] This results in a master HDR video (MAST_HDR) that is, for example, color graded by a human color grader, or a shaded version of the camera capture, or an automatic brightness redistribution algorithm, etc.

[0053] In addition to the grading of the master HDR image, a set of often reversible color transformation functions F_ct is defined. Without intending loss of generality, we assume that this includes at least one luminance mapping function F_L (although there may be further functions and data specifying, for example, how the saturation of pixels changes from HDR to SDR grading).

[0054] This luminance mapping function, as mentioned above, defines the mapping between HDR and SDR reference gradings (the latter being, in Figure 2, the SDR image Im_SDR that is communicated to the receiver, whether or not the data is compressed via, for example, MPEG or other video compression algorithms).

[0055] The color mapping of the color converter 220 should not be confused with that applied to the raw camera feed to obtain the master HDR video, which is assumed here to be already input, since this color conversion is intended to obtain the regrading desiderata, technically formulated in the luminance mapping function F_L, simultaneously with the image to be communicated.

[0056] In an exemplary SDR communication type (i.e., SDR communication mode), a master HDR image is input to a color converter 202. The color converter 202 is configured to apply an F_L luminance mapping to the luminance of the master HDR image (MAST_HDR) to obtain all corresponding luminances written to the output image Im_SDR. For purposes of explanation, assume that the shape of this function is adjusted by a human color grader using color grading software for each shot of an image of a similar scene in a movie. The applied function F_ct (i.e., at least F_L) is written into (dynamic, processing) metadata communicated with the image, for example, MPEG supplemental enhancement information data SEI(F_ct), or a similar metadata mechanism in other standardized or non-standardized communication methods.

[0057] Once the HDR images to be communicated have been properly redefined as corresponding SDR images Im_SDR, these images are often compressed (at least, e.g., for broadcast to end users) using existing video compression techniques (e.g., MPEG HEVC, VVC, AV1, etc.), which is performed in a video compressor 203 that forms part of a video encoder 221 (which may be included within various types of video production devices or systems).

[0058] The compressed image Im_COD is transmitted to at least one receiver via an image communication medium 205 (e.g., satellite, cable, or Internet transmission, e.g., compliant with ATSC3.0 or DVB, etc.) (although the HDR video signal can also be communicated via a cable, e.g., between two video processing devices).

[0059] Further conversion is typically performed before transmission by a transmit formatter 204, which applies packetization, modulation, transmission protocol control, and other techniques depending on the system, typically implemented in an integrated circuit.

[0060] At any receiving site, a corresponding video signal unformatter 206 applies the necessary unformatting methods, e.g., modulation, to re-obtain the compressed video as a set of compressed HEVC images (i.e., HEVC image data).

[0061] The video decompressor 207 performs, for example, HEVC decompression to obtain a stream of pixelated, uncompressed images Im_USDR. In this example, the images Im_USDR are SDR images, but in other modes they are HDR images. The video decompressor also unpacks the required luminance mapping function F_L, or more generally, the color conversion function F_ct, for example from the SEI message. The images and functions are input to a color converter 208 (of the decoder). The color converter 208 is arranged to convert the SDR images into images of any non-SDR dynamic range (i.e., images with a PL_V greater than 100 nits, typically at least several times higher, e.g., 5 times higher).

[0062] For example, a 5000 nit reconstructed HDR image Im_RHDR is reconstructed as a close approximation of the master HDR image (MAST_HDR) by applying the inverse color transform IF_ct of the color transform F_ct used at the encoding side to create Im_LDR from MAST_HDR. This image is then sent to, for example, the display 210 for further display adaptation. However, the display-adapted image Im_DA_MDR can be created in one go during decoding by using the FL_DA function (e.g., determined in firmware in an offline loop) in the color converter instead of the F_L function. Therefore, the color converter may include a display adaptation unit 209 to derive the FL_DA function.

[0063] The optimized, e.g., 800 nit, display adapted image Im_DA_MDR is sent to, e.g., the display 210 if the video decoder 220 is included in, e.g., a set-top box or a computer, or to a display panel if, e.g., the decoder is in a mobile phone, or to a projector in a cinema if, e.g., the decoder is in a server connected to the Internet.

[0064] FIG. 3 shows a useful variation of the internal processing of a color converter 300 (i.e., corresponding to 208 in FIG. 2) of an HDR decoder (or an encoder that typically has roughly the same topology but uses an inverse function, but typically does not include display adaptation).

[0065] The luminance of a pixel (in this example a pixel of an SDR image) is input as the corresponding luma Y'SDR. The chrominance, also known as chroma components Cb and Cr, are input to the lower processing path of the color converter 300.

[0066] The luma Y'SDR is mapped to the required output luminance L'_HDR (e.g., the master HDR reconstruction luminance or another HDR image luminance) by the luminance mapping circuit 310. The luminance mapping circuit 310 applies an appropriate function for the particular image and maximum display luminance PL_D, e.g., a display-adapted luminance mapping function FL_DA(t), obtained from the display adaptation function calculator 350, which uses as input the reference luminance mapping function F_L(t) communicated along with the metadata. The display adaptation function calculator 350 can also determine an appropriate function for processing chrominance. Here, we simply assume that a set of multiplication coefficients mC[Y] for each possible input image pixel luma Y is stored, for example, in the color LUT 301. The exact nature of the colorization process may vary. For example, one may want to keep pixel saturation constant by first normalizing the chrominance with the input luma (the corresponding hyperbola in the color LUT) and then correcting the output luma, although any differential saturation process may be used. Hue is typically preserved because both chrominances are multiplied by the same multiplier.

[0067] Indexing color LUT 301 with the luma value Y of the currently color transformed (luminance mapped) pixel provides the required multiplication coefficient mC as the LUT output, which is used by multiplier 302 to multiply the two chrominance values ​​of the current pixel, i.e., to provide the color transformed output chrominance. Cbo=mC * Cb, Cro=mC * Cr

[0068] Via a fixed color matrixing processor 303 that applies standard colorimetric calculations, the chrominance can be converted to lightness-free normalized non-linear R'G'B' coordinates R' / L', G' / L', and B' / L'.

[0069] The R'G'B' coordinates that give the output image the appropriate brightness are obtained by multiplier 311, which calculates: R'_HDR=(R' / L') * L'_HDR, G'_HDR=(G' / L') * L'_HDR, B'_HDR=(B' / L') * L'_HDR, This can be summarized in the color triplet R'G'B'_HDR.

[0070] Finally, there may be further mapping to the format required by the display by a display mapping circuit 320, which results in the display driving color D_C. Not only is this formulated in the colorimetry desired for the display (e.g., even in HLG OEFT format), but this display mapping circuit 320 may in some variants be arranged to perform specific color processing for the display. That is, the display mapping circuit 320 may, for example, further remap some of the pixel brightnesses.

[0071] Some examples illustrating suitable display adaptation algorithms for deriving FL_DA functions corresponding to any possible F_L functions that may have been determined by the producing grader are taught in WO2016 / 091406 or ETSI TS103 433-2 V1.1.1(2018-01).

[0072] As mentioned above, luma codes representing HDR video / image data are often represented in a perceptually uniform representation, where the mapping between luminance and luma codes (or vice versa) is such that the perceptual impact of a luminance change corresponding to a change in one least significant bit of the luma code is the same regardless of the absolute value of the luminance / luma code.

[0073] The captured luminance is mapped to a luma code using an appropriate OETF (inverse EOTF) that results in such a perceptually uniform representation. Similarly, the luma code of such a perceptually uniform representation can be mapped to the display output luminance using an appropriate OETF. In practice, several different transfer functions have been standardized, such as EOTF_ST2084, standardized by the Society of Motion Picture and Television Engineers (SMPTE). Summary of the Invention [Problem to be solved by the invention]

[0074] However, perceptually uniform domains can sometimes offer advantageous quantization, keeping the perceptual effects of quantization constant. However, perceptually uniform representations are not ideal for all operations. In particular, performing brightness adjustment processes such as tone mapping and grading tends to be suboptimal when using perceptually uniform representations. In particular, such operations tend to be complex, resource-intensive, and provide suboptimal results. Furthermore, conversion to other representations tends to be disadvantageous, often increasing complexity and introducing errors and distortions in the mapping between luma codes and luminance. This is particularly true for perceptually uniform representations, where the required conversions tend not to correspond to well-behaved functions and tend to have extreme behavior toward zero luminance, due to a tendency toward (positive) infinite first derivative values ​​with respect to luminance, which in practice often approaches zero.

[0075] As such, improved approaches would be advantageous, particularly approaches that allow for increased flexibility, improved adaptability, improved performance, improved image / video quality, fewer errors and inaccuracies, easier processing, less complexity and resource usage, easier implementation, and / or an improved spatial audio experience.

[0076] U.S. Patent Application Publication No. 2020 / 0035198 teaches, for example, that one can take initial brightness values ​​coded in (the inverse of) the SMPTE 2084 EOTF, apply that EOTF to various pixel brightness values ​​to reconstruct them into luminance, apply multiplicative (brightening or darkening) scaling in the linear domain, and convert to quadratic brightness using a different EOTF (e.g., the SDR EOTF (or more precisely, its inverse, the OETF) for Rec. 709). This U.S. patent application does not suggest an EETF, as in the present invention, that directly converts any perceptually uniform brightness to logarithmic brightness. EETFs are more suitable for certain types of processing, such as multiplicative brightness regrading (in the linear domain) or relighting processes.

[0077] SUMMARY OF THE INVENTION Accordingly, the Invention seeks to preferably mitigate, alleviate or eliminate one or more of the above mentioned disadvantages singly or in any combination. [Means for solving the problem]

[0078] According to one aspect of the present invention, there is provided an apparatus as claimed in claim 1, namely an image processing apparatus, comprising: a receiver (401) configured to receive an image including a first pixel lightness (Y'_HDR_PQ) encoded according to a perceptually uniform electro-optical transfer function (EOTF); a converter (410) configured to convert a first pixel brightness to a second pixel brightness (Y'_LOG), the second pixel brightness being encoded according to an EOTF defined by a logarithmic mapping from luminance (i.e., optical value) to the second pixel brightness; an image processor circuit (411) configured to apply a brightness adjustment process to the second pixel brightness; The converter (410) a first converter circuit (601, 605) configured to generate a first intermediate pixel color value by applying a first logarithmic function to the first pixel color value and to apply multiplicative scaling to the first intermediate pixel color value to obtain the scaled first intermediate pixel color value, wherein the scaling multiplier is an exponent having a value greater than 1; a second converter circuit (603) configured to generate a second intermediate pixel lightness by applying a second logarithmic function to the output value of the perceptually uniform EOTF for the first pixel lightness divided by a divisor equal to a power function of the first pixel lightness raised to the exponent; and an adder (607) configured to add the scaled first intermediate pixel color value and the second intermediate pixel color value to obtain a second pixel color value.

[0079] This process is typically performed pixel by pixel along a scan of the image.

[0080] When an EOTF or OETF is specified, luminance is uniquely defined, and so is lightness (e.g., 10-bit quantization). Because the output of this innovation (which overall was, e.g., an EETF from SMPTE 2084-defined lightness to a logarithmically defined output lightness, before lightness modification processing) is always logarithmic, the input EOTF is configurable (e.g., preceded in processing circuitry or even selectable on-the-fly before processing) and can have, e.g., various partially logarithmic and partially non-logarithmic function shapes.

[0081] This approach improves performance and operation in many scenarios and embodiments, particularly allowing for more accurate and easier brightness adjustment processing. This approach allows brightness adjustment processing to be done in the logarithmic domain, thereby enabling brightness scaling and multiplication using addition and subtraction. Such operations are commonly used in most brightness adjustment processing, and can significantly reduce complexity and resource usage in many applications.

[0082] The specific approach of converting from a perceptually uniform domain to a logarithmic domain for pixel lightness representation allows for accurate conversion and easy implementation. In particular, parts of the required translation / transformation function that tend to be ill-behaved (and have a limit of -∞ for lightness levels approaching complete darkness) can be addressed by splitting the transformation into different parts that are performed separately and then combined. This approach allows the ill-behaved parts to be handled primarily by the standard logarithmic function, for which practical implementations have been developed that can handle very small input values.

[0083] Pixel brightness is expressed as a luma code / value. A pixel brightness coded according to the EOTF reflects the existence of a mapping between pixel brightness ( / luma code) values ​​and light values, specifically optical light values ​​in the linear domain (e.g., measured in nits). The EOTF represents this mapping in the direction from luma values / codes to optical light values. The inverse function EOTF (EOTF -1 ) also corresponds to the OETF and represents the same directional mapping from optical light values ​​to luma values / codes. Therefore, the EOTF and its matching OETF (=EOTF -1 ) both represent the same mapping between optical light values ​​and luma values / codes. Pixel lightness encoded according to a perceptually uniform EOTF is also inherently encoded according to a perceptually uniform OETF (=EOTF -1 ) and vice versa. A pixel lightness that is encoded according to an EOTF that represents a logarithmic mapping from optical light values ​​to second pixel lightnesses is also essentially encoded according to an OETF (=EOTF -1 ) is encoded according to

[0084] The first logarithmic function and the second logarithmic function have the same base. The combination of the first and second intermediate pixel brightnesses may be a (possibly weighted) sum. The pixel brightness is a luma value. The pixel brightness may be a normalized value relative to a reference brightness, e.g., in the range 0 to 1, where 1 corresponds, e.g., to 10,000 nits.

[0085] The brightness adjustment process is a tone mapping that takes the second pixel brightness as input. This approach allows for improved and less complex tone mapping.

[0086] According to an optional aspect of the present invention, claim 2 is provided.

[0087] This provides improved operation and performance in many scenarios and embodiments, particularly by allowing for a more accurate conversion of pixel brightness into the logarithmic domain. The scale factor is a design parameter that is optimized for a particular application.

[0088] According to an optional aspect of the present invention, claim 3 is provided.

[0089] This provides improved operation and performance in many scenarios and embodiments. In many embodiments, the scale factor is set such that, for example, a first pixel brightness is mapped to the same value as a second pixel brightness relative to a reference brightness. For example, a first pixel brightness Ein=1 is mapped to the same corresponding second pixel brightness value Eout=1 relative to a reference brightness of, for example, 10,000 nits.

[0090] According to an optional aspect of the present invention, claim 4 is provided.

[0091] This provides improved operation and performance in many scenarios and embodiments, particularly by allowing pixel brightness to be converted more accurately into the logarithmic domain.

[0092] The parameters γ and x are selected to provide the particular performance and operation required for a particular implementation / embodiment.

[0093] According to an optional aspect of the present invention, claim 5 is provided.

[0094] This provides improved operation and performance in many scenarios and embodiments, particularly by allowing pixel brightness to be converted more accurately into the logarithmic domain.

[0095] The parameters γ and x are selected to provide the particular performance and operation required for a particular implementation / embodiment.

[0096] According to an optional aspect of the present invention, claim 6 is provided.

[0097] This provides improved operation and performance in many scenarios and implementations, especially when the first pixel intensity is encoded according to SMPTE ST2084 EOTF.

[0098] According to an optional aspect of the present invention, claim 7 is provided.

[0099] This provides improved operation and performance in many scenarios and implementations, especially when the first pixel intensity is encoded according to SMPTE ST2084 EOTF.

[0100] According to an optional aspect of the present invention, claim 8 is provided.

[0101] This provides improved operation and performance in many scenarios and implementations.

[0102] According to an optional aspect of the present invention, claim 9 is provided.

[0103] This approach is particularly suitable for converting pixel intensities encoded according to the SMPTE ST2084 EOTF.

[0104] According to an optional aspect of the present invention, claim 10 is provided.

[0105] This approach is particularly suitable for converting pixel lightness encoded according to the SMPTE ST2094-20 EOTF. Another useful EOTF is Applicant's perceptually uniform EOTF, as specified in ETSI TS103433.

[0106] According to an optional aspect of the present invention, claim 11 is provided.

[0107] This facilitates and / or enhances the conversion in many embodiments.

[0108] According to one aspect of the present invention, there is provided a method as claimed in claim 12.

[0109] According to an optional aspect of the present invention, claim 13 is provided.

[0110] According to an optional aspect of the present invention, claim 14 is provided.

[0111] These and other aspects, features and advantages of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

[0112] These and other aspects of the method and apparatus according to the present invention will be apparent and elucidated with reference to the implementations and embodiments described below, and with reference to the accompanying drawings, which serve only as non-limiting specific examples illustrating more general concepts, and in which dashed lines are used to indicate that components are optional. Components not shown with dashed lines are not necessarily required. Dashed lines are also used to indicate that an element is described as required, but is hidden inside an object, or for intangible things such as object / area selection, etc. [Brief explanation of the drawings]

[0113] [Figure 1] The diagram illustrates several typical color transformations that occur when optimally mapping a high dynamic range image to a corresponding image of a lower dynamic range (e.g., a standard dynamic range image with a maximum brightness of 100 nits) that is optimally color-graded and similar-looking (as similar as desired and possible given the difference between the first dynamic range DR_1 and the second dynamic range DR_2). In the lossless case, this also corresponds to the mapping of a received SDR image, which actually encodes an HDR scene, to a reconstructed HDR image of that scene. Luminance is shown as a position on a vertical axis ranging from darkest black to maximum brightness PL_V. The luminance mapping function is symbolically shown by an arrow that maps average object luminance from the luminance of the first dynamic range to the second dynamic range (those skilled in the art will understand how to equivalently depict this as a conventional function (e.g., axes normalized to 1, normalized by dividing by the respective maximum luminance)). [Figure 2]1 shows a schematic example of a high-level diagram of applicant's recently developed technique for encoding high dynamic range images (i.e., images that can typically have a brightness of at least 600 nits or more (typically 1000 nits or more)), which can actually communicate an HDR image either by itself or as a corresponding brightness-regraded SDR image plus metadata encoding a color transformation function that includes at least a properly determined brightness mapping function (F_L) to pixel colors that is used by a decoder to convert the received SDR image into an HDR image. [Figure 3] 1 shows details of the image decoder internals and in particular the pixel color processing engine. [Figure 4] 1 illustrates some elements of an example image processing device according to some embodiments of the present invention. [Figure 5] 1 shows an example of a perceptually uniform luma domain to log-luma domain transformation. [Figure 6] 5 illustrates an example of an element of a converter for the image processing device of FIG. 4. [Figure 7] An example of a conversion function that can be used in the converter of FIG. 6 is shown below. [Figure 8] An example of a conversion function that can be used in the converter of FIG. 6 is shown below. [Figure 9] 1 illustrates some elements of a possible configuration of a processor for implementing elements of an image processing device according to some embodiments of the present invention. [Figure 10] 10 illustrates some elements of another example image processing apparatus according to another illustrative embodiment of an EETF partitioning embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0114] Figure 4 shows an image processing apparatus used to adapt the brightness of pixels of an image, for example for a color converter in an HDR decoder or encoder. The apparatus corresponds to the approach of Figure 3, and the comments and explanations for Figure 3 apply to the corresponding features of Figure 4. The apparatus is configured to adjust the brightness of a received image.

[0115] The signal processing apparatus of Figure 4 comprises a receiver 401 configured to receive an image, which may be an individual image or an image / frame of, for example, a video sequence.

[0116] Images are formed by pixels, each represented by a value indicating the brightness of the corresponding pixel. For color images, any suitable color coding / representation may be used, and the following description will focus on a color representation consisting of one brightness / luma value and two chroma values. Specifically, the description will be made with reference to a received image encoded according to a Y'CbCr color space / representation, where Y' is the luma component and CB and CR are the blue-difference and red-difference chroma components. However, it will be understood that other color representations may be used in other embodiments, such as other color representations with one luma component and multiple chroma components, or color representations using separate color channels, such as RGB-encoded data. Where appropriate, such color representations are converted to a Y'CbCr color space / representation, for example, by receiver 401.

[0117] In the approach of Figure 4, image processing circuitry 411 is configured to perform luminance processing. In this illustrated approach, therefore, the upper path is configured to perform luminance processing, and the lower path is configured to perform chroma (CbCr) processing.

[0118] The input data to the upper path Y'_HDR_PQ is specifically HDR pixel luma (eg, of an HDR grade image with bright burst pixels up to 4000 nits), expressed as, for example, PQ (Perceptual Quantization) luma.

[0119] Image processor circuit 411 can perform any luminance processing function, but this can be done in the logarithmic domain so that linear light-domain scaling / multiplication can be implemented by addition (e.g., a brightened output luminance can be achieved (typically linearly) by, for example, a luminance multiplication by 3, and thus can be implemented logarithmically as addition). Converter 410 therefore generates a luma value Y'_LOG, which represents luminance as a log(luminance) [e.g., log_10 or log_2] value.

[0120] In many embodiments, the brightness of a pixel is therefore given by the luma code / value of the pixel.

[0121] Pixel lightness of an image is encoded according to a perceptually uniform EOTF / OETF. Therefore, the mapping between luma values ​​and optical lightness (actual linear optical lightness, e.g., measured in nits) is a perceptually uniform mapping. Therefore, a difference / change in luma code / value by a step of 1 LSB is perceived to result in the same lightness change regardless of the absolute value (i.e., the step represented by the luma code is seen perceptually the same across the range). It will be understood that different models and measures of the perceptual impact of lightness changes are known and can serve as the basis for a perceptually uniform representation.

[0122] A perceptually uniform EOTF typically starts as a gamma function, also known as a power function, for the darkest luminances to be coded, and gradually changes to a logarithmic mapping for the brightest luminances. Thus, a perceptually uniform EOTF typically approaches a gamma / power function for luminances approaching zero luminance, and approaches a logarithmic function for luminances approaching maximum luminance.

[0123] It will be understood that the EOTF represents a mapping from luma codes to optical brightness, and the OETF represents a mapping from optical brightness to luma codes. Thus, both the EOTF and the OETF represent a mapping between optical brightness and luma codes. In fact, the two also have a corresponding EOTF, where a given OETF is given as its inverse function, i.e., EOTF = OETF.-1 Similarly, a given EOTF also has a corresponding OETF, which is given as the inverse function EOTF, i.e., OETF=EOTF -1 Thus, a luma code encoded according to an EOTF is essentially also encoded according to the corresponding OETF. In fact, both represent a mapping between luma codes and optical brightness (but in reverse). In a practical implementation, the OETF is used to convert optical brightness values ​​to luma codes (i.e., on the capture / input side), and the EOTF is used to convert luma codes to optical brightness values ​​(i.e., on the rendering side). In a practical system, the EOTF used may be the inverse of the OETF applied to convert the actual captured pixel values, but in some practical systems, the OETFs may be different. That is, the inverse of the EOTF used is not necessarily the same as the OETF used (and similarly, the OETF used is not necessarily the same as the EOTF used).

[0124] In the system of Figure 4, pixel lightness of a received image is represented by a luma code that is encoded according to a perceptually uniform EOTF, and therefore equivalently, according to a perceptually uniform OETF, which is given as the inverse function of the perceptually uniform EOTF. The luma codes therefore represent values ​​with quantization designed to have the same relative perceptual impact across the entire range.

[0125] Luma codes are specifically represented by values ​​mapped to optical brightness according to a mapping defined by the Society of Motion Picture and Television Engineers (SMPTE) as the ST2084 EOTF. In some embodiments, luma codes are specifically represented by values ​​mapped to optical brightness according to a mapping defined by the SMPTE as the ST2094-20 EOTF.

[0126] While the EOTF is generally thought of as a decompression function (i.e., a concave function that stretches or brightens higher intensities mapped to the output luminance compared to lower intensities), the reverse is also true for the EOTF. -1 (which can be thought of as the OETF that matches the EOTF) is an inverse function and therefore can be thought of as a compressive function (i.e., convex, with a gradually decreasing slope at higher lightness). Therefore, a perceptually uniform domain is -1 can be thought of as connected to the RGB function in that it transforms linear light into perceptually uniform data values. This function is typically

number

number

[0127] Any EOTF that provides a one-to-one mapping from luma values ​​to linear optical light values ​​also inherently defines an inverse mapping from linear optical light values ​​to luma values, i.e., has a corresponding OETF. Thus, luma values ​​inherently represent linear optical light values ​​and are therefore equivalently encoded according to the EOTF / OETF that defines this mapping.

[0128] In contrast to the approach of FIG. 3, the device of FIG. 4 does not perform a brightness adjustment process on the received luma values. Rather, the device of FIG. 4 includes a converter 410 configured to convert the perceptually uniform luma code into a luma code encoded according to an EOTF defined by a logarithmic mapping from optical light values ​​to second pixel brightnesses (and equivalently, an OETF given by the inverse function EOTF). This is also referred to as a logarithmic EOTF / OETF. The pixel values / luma codes are accordingly converted into a representation in which the luma code has a logarithmic mapping to optical brightness values. This representation is also referred to as being in the logarithmic domain. Thus, in this representation, a doubling of the luma code value corresponds to an increase in the optical brightness to which the luma code maps by a factor equal to the base of the logarithm.

[0129] Thus, the converter 410 provides an electro-electrical transfer function (EETF) that maps luma codes encoded according to a perceptually uniform mapping to luma codes encoded according to a logarithmic mapping. The converter accordingly maps a first / input pixel brightness / luma code to a second / output pixel brightness / luma code. The converter 410 attempts to generate the second pixel brightness to map to the same optical brightness as the first pixel brightness (i.e., for a pixel, the amount of nits represented by the output value is the same as that of the input value), but because the mapping is different (logarithmic rather than perceptually uniform), the optical brightness (usually) is represented by a different value / luma code.

[0130] The converter 410 is coupled to an image processor circuit 411 that is configured to apply a brightness adjustment process to the second pixel brightnesses. In many embodiments, the brightness adjustment process is specifically a tone mapping or grading process that selectively adjusts the brightness of individual pixels. However, it will be appreciated that in other embodiments, other brightness adjustment processes may be performed.

[0131] The luma codes / values ​​resulting from the brightness adjustment process are output from the image processor circuit 411 for further processing or use in any suitable manner. For example, in the example of Figure 4, the resulting pixel values ​​are sent to mixer 311, which uses them to scale the relative color channel values ​​derived from the input chroma values ​​to provide, for example, a color channel RGB output that is further used to display the image. The output from the image processor circuit 411 is preferably PQ.

[0132] In other embodiments, the resulting luma code is converted back to a perceptually uniform representation / mapping / encoding and transmitted or distributed to a remote source, for example, for rendering / display.

[0133] This approach offers many advantages, particularly in that it often results in significantly reduced complexity and resource requirements. Brightness adjustment processes typically involve scaling pixel values. For example, during tone mapping, brightness values ​​are scaled by a given factor, which is applied to many (sometimes all) pixels in an image. However, proportional scaling is generally associated with optically linear color representations, and determining corresponding values ​​in a perceptually uniform domain is complex and resource-intensive, since those values ​​depend on the absolute value of brightness and therefore vary from pixel to pixel. However, performing such scaling operations in the logarithmic domain is highly efficient and requires far fewer resources. In particular, complex multiplication operations can be replaced by simpler addition / subtraction operations (because multiplications are converted to addition / subtraction in logarithmic values).

[0134] Therefore, using the EETF to convert from a perceptually uniform representation to a logarithmic representation significantly reduces computational resource usage and generally eases the processing requirements for lightness adjustments. This is highly advantageous in many applications and scenarios. However, to ensure that a sufficiently high-quality result is achieved, it is important that the EETF conversion is accurate and does not introduce too much distortion. However, this is typically a very difficult challenge to address, as the required EETF tends to be a poorly behaved function.

[0135] As a specific example, a first pixel brightness is represented by a perceptually uniform luma code corresponding to the mapping provided by the ST2084 EOTF, and the mapping to convert this to a logarithmic mapping can be calculated by the conversion coefficients required for different luma codes.

[0136] Figure 5 shows an example of such a transformation, converting from an ST2084 EOTF-based mapping of luma codes to a log2-based mapping of luma codes. A particular challenge in implementing such a transformation is the low luma values ​​(E in The problem is that as σ approaches zero, the required transform coefficients approach -∞. The EETF mapping required for low luma values ​​cannot be easily represented exactly. This is particularly unsuitable for implementation in a look-up table (LUT), as a large number of entries would be required for low luma values.

[0137] Note that this issue is not just related to ST2084 EOTF-based mapping of received luma codes, but applies in general to most perceptually uniform mappings.

[0138] In practice, most perceptually uniform representations are based on Barten Lightness and contrast sensitivity functions (CSFs) [see Peter Barten, "Formula for the contrast sensitivity of the human eye," Proc. SPIE 5294, Image Quality and System Performance, (December 18, 2003)]. In such mappings, the inverse EOTF (i.e., the OETF corresponding to the EOTF) behaves like a logarithmic function at high lightness levels and like a gamma function at low lightness (dark) levels. Such mappings are inherently prone to the problems described and the difficulties of converting from a perceptually uniform representation to a logarithmic representation.

[0139] When applying tone mapping to an ST2084-based video signal (e.g., HDR10 or SL-HDR2), one may choose to apply a transformation to the linear light domain. Since tone mapping involves applying tone mapping gains as a function of one or more video components or their derivatives (e.g., maxRGB), such gains can be implemented very easily in the logarithmic domain. Multiplication and division are simply addition or subtraction, respectively, in the logarithmic domain. Another aspect of the logarithmic domain is that it requires significantly fewer bits than the linear light domain to achieve the same subjectively perceived picture quality. For example, in the linear light domain, it takes approximately 28(=ceil(log2(10 4 / EOTF_ST2084(2 -10 )))) bits are required, whereas in the logarithmic domain this is 12 bits (11 + s bits). Operations in the logarithmic domain can result in smaller, faster and therefore more efficient tone mapping implementations than implementations of such operations in the linear light or perceptually uniform domain.

[0140] Figure 5 shows the problem from EETF EOTF-ST2084 to log. The displayed area 501 is the singularity

number

[0141] In the system of Figure 4, converter 410 uses a particular approach to converting luma values / pixel brightness levels that allows for reduced complexity and / or improved conversion in many scenarios, which in many embodiments and scenarios improves and / or simplifies implementation and operation, and in particular allows for practical implementation of the desired EETF with high accuracy, including for low luma values.

[0142] 6 shows elements of an exemplary implementation of the converter. In this approach, the converter 410 does not simply apply a conversion function, but rather takes a very specific approach of applying two transformations / conversions and combining them to the appropriate luma value in the logarithmic domain.

[0143] The converter 410 receives a luma value representing the pixel brightness of the image, also called the first pixel brightness. The luma value / code is E in , and is provided in a perceptually uniform domain as described above.

[0144] The first pixel brightness is provided to the first sub-converter 601. The first sub-converter 601 is configured to apply a first logarithmic function (e.g., a logarithm to base 2) to the first pixel brightness, resulting in a modified value referred to as the first intermediate pixel brightness. It will be understood that in other embodiments, logarithms to other bases can be used. The first sub-converter 601 also applies a scale factor to the logarithm in many embodiments. The scale factor and / or base of the logarithm are implementation / design values ​​that are optimized for the particular desired performance and operation of a particular embodiment.

[0145] The first pixel brightness is also provided to the second sub-converter 603. The second sub-converter 603 is configured to generate a second intermediate pixel brightness from the first pixel brightness. Specifically, the second sub-converter 603 applies a perceptually uniform EOTF to the first pixel brightness and divides the result by a divisor equal to a power of the first pixel brightness with an exponent greater than one. The perceptually uniform EOTF is specifically an EOTF according to which the luma value of the first pixel brightness is encoded. Thus, the luma value of the first pixel brightness is mapped to optical brightness in the linear light domain (e.g., measured in nits), and the perceptually uniform EOTF is an EOTF that maps from luma values ​​to optical brightness. Thus, the perceptually uniform EOTF used in the second sub-converter 603 is the inverse transfer function of the perceptually uniform OETF used to convert captured optical brightness to luma values. The second sub-converter 603 is configured to apply a second logarithmic function to the output value from the division.

[0146] In particular, the second sub-converter 603 applies the following function to the first pixel brightness represented in the luma code to generate the second intermediate pixel brightness:

number

[0147] The first sub-converter 601 applies the following function to the first pixel brightness represented in the luma code to generate the first intermediate pixel brightness: E 1stmod (E in )=log x (E in ) where E in represents the first pixel brightness, and x represents the base of the logarithm.

[0148] In many embodiments, the second intermediate pixel brightness is scaled by a scale factor equal to the exponent γ. In Figure 6, this is shown for emphasis by a separate multiplier 605, but it will be understood that this can be considered part of the first sub-converter 601 shown.

[0149] Thus, the first sub-converter 601 applies the following function to the first pixel brightness represented in the luma code to generate the first intermediate pixel brightness: E 1stmod (E in )=γlog x (E in ) where γ is the exponent also used by the divisor applied by the second sub-converter 603.

[0150] The first sub-converter 601 (including the multiplier 605) and the second sub-converter 603 are coupled to a combiner 607 configured to combine the first and second intermediate pixel colors. The combiner 607 is specifically an adder / summing circuit that adds the first and second intermediate pixel colors to generate the second pixel color.

[0151] Thus, overall, converter 410 provides the following EETF to be applied to the first pixel color value to generate the second pixel color value:

number

[0152] The values ​​of x and γ are design parameters that are adapted to the particular preferences and requirements of individual embodiments. In the example described, the base of the logarithm is the same for the first sub-converter 601 and the second sub-converter 603, although it will be understood that in some embodiments different bases may be used.

[0153] In the above example, the first brightness value and the second brightness value are normalized brightness values ​​with respect to a given optical brightness value. Pixel brightness is typically provided in the range [0,1], with the upper end of the range (i.e., luma value 1) corresponding to a predetermined brightness level. The predetermined brightness level is typically a maximum / peak brightness level representing the maximum brightness that can be represented by the luma code (although in other embodiments, luma codes greater than 1 are allowed, for example). For example, in many embodiments, the luma code is a normalized code where a value of 1 corresponds to a predetermined brightness level, for example, 10,000 nits.

[0154] In many embodiments, converter 410 is further configured to scale the second pixel brightness by a gain / scale factor α. In some embodiments, scale factor α is applied to the combined value (e.g., at the output of combiner 607). However, in many embodiments, it is done separately in two paths, i.e., by both first sub-converter 601 and second sub-converter 603. Thus, converter 410 may, for example, perform the following operation:

number

[0155] Such an implementation is particularly advantageous in many embodiments. In particular, scaling can be efficiently incorporated into the logarithmic function implemented by the first sub-converter 601, or can be easily included by modifying the multiplication performed by multiplier 605. Similarly, scaling can be included as an integral part of the function implemented by the second sub-converter 603. For example, this could be implemented as a look-up table with stored values ​​including the scale factor α.

[0156] In many embodiments, a common / global scale factor α is used to scale the output so that there is an appropriate relationship between the luma value of the second pixel brightness and the optical brightness level, particularly the maximum value of the first pixel brightness, e.g., E, corresponding to the maximum pixel brightness, e.g., 10,000 nits. in =1, the value of E out It can be set to yield an output value of 1, which also corresponds to maximum pixel brightness, i.e. 10,000 nits.

[0157] The scale factor α scales pixel brightness such that the maximum input luma value / code is mapped to the same maximum pixel brightness as the (same) output luma code. Specifically, in many embodiments, the scale factor α is in At =1, converter 410 is E out =1.

[0158] In some embodiments, the input (first) pixel brightness is in a range that does not include the zero value. For example, in a 12-bit representation, the lowest input brightness is 2 -12, which is a value of 0. However, in many embodiments, an input value / luminance of zero is also possible and can be accommodated. However, this can be treated as a separate / special case in which the output (second) pixel luminance in the logarithmic domain is determined not based on the approach described above, but by a direct, separate mapping. For example, an input value of 0 is directly mapped to an output value of 0, and indeed a value of zero is reserved for zero luminance throughout different functions, processes, and domains. In fact, in some embodiments, a zero (luminance) input value is directly mapped to a zero (luminance) output value (possibly throughout the entire signal processing chain). Thus, the value may be treated by the described apparatus as a special case that is processed differently from other values. This approach provides an efficient EETF that converts from pixel luminance and luma codes that provide a perceptually uniform representation to pixel luminance and luma codes that provide a logarithmic representation. This approach can provide an EETF that converts accurately between domains, and in practice has been shown to provide theoretically accurate conversion in many cases. Thus, this approach allows for a significantly easier luminance adjustment process, as scaling of luminance levels can be performed with low-complexity addition / subtraction operations rather than multiplications.

[0159] The use of separate functions that are then combined further allows for more practical and easier computation. Indeed, this alleviates the problem that the required conversion coefficients are ill-behaved, especially for very low luma values ​​or for luminance values ​​approaching complete darkness. In effect, this approach allows for the separation of the required transfer function into a well-behaved function (implemented by the second sub-converter 603) and a logarithmic function (implemented by the first sub-converter 601).

[0160] A well-behaved function can be implemented relatively easily, for example using a LUT with appropriate interpolation, or as a combination of several part functions, each covering a range of luma values ​​(each part function being an approximation of the well-behaved function within a range).

[0161] Logarithmic functions may be poorly behaved in the sense that there is still a limit of -∞ for lightness approaching complete black (luma values ​​approaching zero). However, logarithms are not special functions; they are standard mathematical functions for which efficient implementations have been developed that provide accurate output values ​​for input values ​​approaching 0. In particular, highly efficient hardware (e.g., VLSI and ASIC logic structures) and signal processing algorithms have been developed to specifically address the problem of logarithmic functions approaching -∞.

[0162] This particular approach therefore provides ease of implementation and improved accuracy in many scenarios and embodiments.

[0163] In many embodiments, the logarithm is the base 2 logarithm, where x=2. This is a particularly advantageous approach as it provides a suitable transformation to a logarithmic representation that can be implemented with reasonable / low complexity. Thus, log x is preferably log2 due to its implementation advantages in computer programs as well as in VLSI, such as a small number of tables in iterative implementations. Several specific implementations of the log2 function have been developed, particularly in VLSI, that provide relatively accurate results at a relatively low complexity.

[0164] In many embodiments, the first pixel color value is encoded according to a mapping defined in the SMPTE, ST2084 EOTF, or ST2094-20 EOTF (in other words, encoded according to the inverse of these EOTFs).

[0165] These perceptually uniform domains are widely used, and the current transformation approach provides a particularly efficient method for transforming these particular perceptually uniform domains to the logarithmic domain with high accuracy, allowing for practical and typically low-complexity computations.

[0166] As previously mentioned, the exponent γ is a design parameter that is carefully tailored to provide desired results and effects. Particularly advantageous performance is achieved in many embodiments for γ to be less than 3, more advantageously having a value between 1.1 and 4, and often even more advantageously having a value between 1.6 and 1.8. Particularly advantageous performance has been found for γ substantially equal to 1.695.

[0167] These values ​​allow for easy / practical implementations that allow for particularly accurate conversion between particular perceptually uniform mappings, particularly those represented by the ST2084 EOTF or the ST2094-20 EOTF. In particular, values ​​between 1.6 and 1.8 are often particularly suitable for perceptually uniform mappings represented by the ST2084 EOTF, and values ​​between 2 and 3 (or, more advantageously, in many embodiments, between 2.3 and 2.5) are often particularly suitable for perceptually uniform mappings represented by the ST2094-20 EOTF. In practice, a value of exactly 2.4 can be used in ST2094-20 and has been shown to provide advantageous conversion.

[0168] Similarly, the overall scale factor α is a design parameter that is carefully adapted to provide desired results and effects. For example, in many embodiments, the relative scaling between the input first pixel brightness and the output second pixel brightness relative to a given reference brightness (e.g., when converter 410 is set to E in =1 for E out = 1).

[0169] Particularly advantageous performance is achieved in many embodiments for α to be less than 0.5, more advantageously with scale factor values ​​having values ​​in the range of 0.05 to 0.1, and often even more advantageously with values ​​of 0.07 to 0.08. Particularly advantageous performance has been found for α to be substantially equal to 0.075.

[0170] In many embodiments, the scale factor is advantageously determined as follows:

number

[0171] The above values ​​allow for easy / practical implementations that allow for particularly accurate conversion between particular perceptually uniform mappings, particularly those represented in the ST2084 EOTF or the ST2094-20 EOTF. In practice, the indicated advantageous values ​​of γ and α advantageously work together to provide particularly advantageous conversion of pixel lightness, improving overall performance.

[0172] In many embodiments, converter 410 advantageously provides the following functions:

number

number

number

[0173] It has been found that such an approach provides near-optimal results in terms of conversion accuracy, while allowing for a practical and efficient implementation that uses a standard, known approach to determine the logarithmic value of the second term (performed by the first sub-converter 601), and allows the first term to be implemented (by the second sub-converter 603) using relatively low-complexity means, such as by using a LUT. Indeed, the function for the first term is shown in FIG. 7. As can be seen, this function is well-behaved and lends itself to implementation using a LUT, possibly combined with appropriate interpolation. For example, this function could also be implemented by a series of partial functions, each covering a range of input brightness values ​​and each approximating the function of FIG. 7 over a particular range.

[0174] In particular, the function performed by the second sub-converter 603 is to convert the critical section of the conversion (E approaching zero) in This helps ease implementation, since the sigma sigma (approaches -∞ for sigma ...

[0175] The first term uses EOTF, the argument of the logarithm function, as the gamma function E γ (where γ>1). In the case of EOTF ST2084, γ≈1.695 is nearly optimal. Combined with x=2,

number

[0176] Note that when the mapping between perceptual uniform pixel brightness / luma and a linear light function follows ST2094-20 at L=10000 nits, a gamma γ=2.4 results in a substantially perfect and accurate conversion. The functions that need to be implemented in the second sub-converter 603 tend to be much smoother (or more mathematically complete) in ST2094-20 than in ST2084.

[0177] Both the ST2084 EOTF and the ST2094-20 EOTF are derived from Barten Lightness and CSF functions. The described approach and functions tend to be particularly advantageous for any mapping / EOTF / OETF that is derived from Barten Lightness and CSF and is desired to be transformed into the logarithmic domain. The inverse functions of such EOTFs are characterized by a gamma behavior towards darkness / black / low lightness and a logarithmic behavior towards peak white / high lightness values.

[0178] As previously mentioned, in many embodiments, the function performed by the second sub-converter 603 may be implemented as a LUT. In some embodiments, the LUT contains a value for each possible luma value that indicates the first pixel brightness. In other embodiments, a smaller LUT is used, interpolating between the stored values ​​to determine the appropriate output value.

[0179] In some embodiments, the input range, i.e., the range of possible values ​​of the first pixel brightness, is divided into multiple subranges / segments. For example, as shown in FIG. 8, the function is divided into 23 subranges / segments. For each range, a function is stored that provides a conversion mapping from the input pixel brightness to the second intermediate pixel brightness. These functions are specifically polynomials that are adapted / optimized to approximate the best-fit function of the second sub-converter 603 in a particular segment. Thus, in the example of FIG. 8, one polynomial is stored per segment, for a total of 23 polynomial functions.

[0180] For a given first pixel brightness value, the second sub-converter 603 accordingly determines the sub-range / segment that the value falls into, then selects / obtains the corresponding polynomial function and evaluates this function for the first pixel brightness value, and the result is then used as the second intermediate pixel brightness value.

[0181] It will be appreciated that various approaches for adapting a polynomial to approximate a given function (for a given range of values) are known, and any suitable approach may be used. It will also be appreciated that many such embodiments involve adapting the ranges of individual functions. Indeed, it will be appreciated that in some scenarios, a completely manual approach may be used to determine appropriate functions and ranges.

[0182] For example, such approaches are based on implementing a non-uniform segmentation approach to interpolating LUTs, such as described in D.H. Douglas and T.K. Peucker, "Algorithms for the Reduction of the Number of Points Required to Represent a Line or Its Caricature," The Canadian Cartographer, Vol. 10, No. 2, pp. 112-122, 1973, or Tsutomu Sasao, Shinobu Nagayama, and Jon T. Butler, "Numerical Function Generators Using LUT Cascades," IEEE Trans. Computers, Vol. 56, No. 6, June 2007.

[0183] In particular, the apparatus may be implemented in one or more suitably programmed processors. In particular, the artificial neural network may be implemented in one or more such suitably programmed processors. The various functional blocks may be implemented in separate processors and / or may, for example, be implemented in the same processor. An example of a suitable processor is given below:

[0184] 9 is a block diagram illustrating an exemplary processor 900 according to an embodiment of the present disclosure. Processor 900 may be used to implement one or more processors that implement the aforementioned devices or elements thereof (including, inter alia, one or more artificial neural networks). Processor 900 may be any suitable processor type, including, but not limited to, a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable array (FPGA) (wherein the FPGA is programmed to form a processor), a graphics processing unit (GPU), an application specific integrated circuit (ASIC) (wherein the ASIC is designed to form a processor), or a combination thereof.

[0185] Processor 900 may include one or more cores 902. Core 902 may include one or more arithmetic logic units (ALUs) 904. In some embodiments, core 902 includes a floating point logic unit (FPLU) 906 and / or a digital signal processing unit (DSPU) 908 in addition to or instead of ALU 904.

[0186] The processor 900 may include one or more registers 912 communicatively coupled to the cores 902. The registers 912 may be implemented using dedicated logic gate circuits (e.g., flip-flops) and / or any memory technology. In some embodiments, the registers 912 are implemented using static memory. The registers may provide data, instructions, and addresses to the cores 902.

[0187] In some embodiments, processor 900 may include one or more levels of cache memory 910 communicatively coupled to cores 902. Cache memory 910 may provide computer-readable instructions to cores 902 for execution. Cache memory 910 may provide data for processing by cores 902. In some embodiments, computer-readable instructions may be provided to cache memory 910 by local memory (e.g., local memory attached to external bus 916). Cache memory 910 may be implemented with any suitable cache memory type, such as, for example, static random access memory (SRAM), dynamic random access memory (DRAM), and / or any other suitable memory technology, e.g., metal-oxide semiconductor (MOS) memory.

[0188] Processor 900 may include a controller 914. Controller 914 may control input to processor 900 from other processors and / or components included in the system and / or output from processor 900 to other processors and / or components included in the system. Controller 914 may control data paths within ALU 904, FPLU 906, and / or DSPU 908. Controller 914 may be implemented as one or more state machines, data paths, and / or dedicated control logic. Gates in controller 914 may be implemented as stand-alone gates, FPGAs, ASICs, or any other suitable technology.

[0189] Registers 912 and cache 910 may communicate with controller 914 and core 902 via internal connections 920A, 920B, 920C, and 920D. The internal connections may be implemented as buses, multiplexers, crossbar switches, and / or any other suitable connection technology.

[0190] Input and output for processor 900 is provided via bus 916, which may include one or more conductive lines. Bus 916 may be communicatively coupled to one or more components of processor 900, such as controller 914, cache 910, and / or registers 912. Bus 916 may be coupled to one or more components of the system.

[0191] The bus 916 may be coupled to one or more external memories. The external memory may include a read-only memory (ROM) 932. The ROM 932 may be masked ROM, an electronically programmable read-only memory (EPROM), or any other suitable technology. The external memory may include a random access memory (RAM) 933. The RAM 933 may be static RAM, battery-backed static RAM, dynamic RAM (DRAM), or any other suitable technology. The external memory may include an electrically erasable programmable read-only memory (EEPROM) 935. The external memory may include a flash memory 934. The external memory may include a magnetic storage device such as a disk 936. In some embodiments, the external memory may be included in the system.

[0192] FIG. 10 is a block diagram illustrating another illustrative embodiment of the present disclosure, a maxRGB-based tone mapper for converting from high dynamic range to high, medium, or low dynamic range, or vice versa. A lightness measure other than luminance can be used. For example, even when processing three color components in parallel, R, G, and B are related to lightness change rather than more general color change, even when processed similarly. For example, the maximum of these three color components, R, G, and B, can be used as the lightness measure. For example, in a color quadrant dominated by the red component, this red component functions as the lightness measure (and uses the EETF division embodiment for it). In this illustrative embodiment, RGB component video is defined in the ST2084 domain and denoted as R″G″B″. This pixel color is the input of Input EETF 1001, which converts the ST2084 video components to the logarithmic domain according to the EETF division principles described above. The output of EETF1001 is connected to the input of Input Component Maximum Calculator 1002 to ensure that the maximum color component acts as the lightness (for the lightness processing track), and three inputs R log , G log , and B log The output of maxRGB 1002 (a value called maxRGB) is connected to the input of the tone mapper 1003. The tone mapper 1003 can perform any tone mapping based on maxRGB as needed (for example, it usually applies a tone mapping function to maxRGB as an input, and applies tone mapping communicated by the creator or determined by the device itself), and it can output a gain g TM This gain g TM is added to all the video components R in the lower branch by adder 1004. log , G log , and B log. Note that, as mentioned above, addition in the logarithmic domain represents multiplication in the linear domain. The output of adder 1004 is input to output EETF 1005, which performs a conversion from the logarithmic domain to, preferably, ST2084 (i.e., the inverse or substantially inverse of the input EETF) for all video components. Thus, the output video is a tone-mapped result of the input video represented by ST2084. Note that this principle can be modified, for example, by including an additional input in the component maximum calculator 1002 line, for example, a fourth input for luminance. Those skilled in the art will appreciate that some of the variations illustrated in this figure, e.g., addition instead of multiplication, can also be performed in other embodiments such as FIG. 4. The present invention can be implemented in any suitable form, including hardware, software, firmware, or any combination thereof. The present invention may optionally be realized at least in part as computer software running on one or more data processors and / or digital signal processors. Elements and components of embodiments of the present invention may be physically, functionally, and logically realized in any suitable way. Indeed, the functionality may be implemented in a single unit, in several units or as part of other functional units. Thus, the invention may be implemented in a single unit or may be physically and functionally distributed between different units, circuits and processors.

[0193] Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the appended claims. Moreover, while certain features may appear to be described in connection with particular embodiments, those skilled in the art will recognize that various features of the described embodiments may be combined in accordance with the present invention. In the claims, the term "comprising" does not exclude the presence of other elements or steps.

[0194] Furthermore, although individually listed, a plurality of means, elements, circuits, or method steps may be implemented by, for example, a single circuit, unit, or processor. Moreover, although individual features may be included in different claims, these features may be advantageously combined, and the inclusion of features in various claims does not imply that such combinations are not feasible and / or advantageous. Furthermore, the inclusion of features in one claim category does not imply any limitation to this category, but rather indicates that the features may be applied to other claim categories as well, where appropriate. Furthermore, the order of features in the claims does not imply a particular order in which the features must be performed, and in particular the order of individual steps in method claims does not imply that the steps must be performed in that order. Rather, steps may be performed in any suitable order. Furthermore, a reference in the singular does not exclude a plural. Thus, a reference to "first," "second," etc. does not exclude a plural. Reference signs in the claims are provided solely as examples for clarity, and these examples should not be construed in any way as limiting the scope of the claims.

Claims

1. a receiver for receiving an image including a first pixel brightness (Y'_HDR_PQ) encoded according to a perceptually uniform electro-optical transfer function (EOTF); a converter that converts the first pixel lightness to a second pixel lightness (Y'_LOG), the second pixel lightness being encoded according to an EOTF defined by a logarithmic mapping from luminance to the second pixel lightness; an image processor circuit that applies a brightness adjustment process to the second pixel brightness; The converter comprises: a first converter circuit that generates a first intermediate pixel color by applying a first logarithmic function to the first pixel color and applies multiplicative scaling to the first intermediate pixel color to obtain a scaled first intermediate pixel color, the scaling multiplier being an exponent having a value greater than one; a second converter circuit that generates a second intermediate pixel lightness by applying a second logarithmic function to the output value of the perceptually uniform EOTF for the first pixel lightness divided by a divisor equal to a power function of the first pixel lightness raised to the exponent; an adder that adds the scaled first intermediate pixel brightness and the second intermediate pixel brightness to obtain the second pixel brightness; an image processing device comprising:

2. 2. The image processing apparatus of claim 1, wherein the converter scales the second pixel brightness by a scale factor such that the converter maps a maximum pixel brightness of a range of possible values ​​of the first pixel brightness to a maximum pixel brightness of a range of possible values ​​of the second pixel brightness.

3. The second converter circuit has the following formula: [0012] generating the second intermediate pixel color using Here, E ｉｎ represents the first pixel brightness, and EOTF (E ｉｎ 3. The image processing apparatus of claim 1, wherein γ represents the output value of the perceptually uniform EOTF, γ represents the exponent, and x represents the base of the logarithm.

4. The first converter circuit has the following formula: E １ｓｔｍｏｄ (E ｉｎ ) = γ log ｘ (E ｉｎ ) generate the first intermediate pixel brightness using E ｉｎ The image processing device according to claim 1 , wherein x represents the first pixel brightness, γ represents the exponent, and x represents the base of the logarithm.

5. 5. The image processing device according to claim 1, wherein the index γ has a value of 1.1 to 4.

6. 6. An image processing apparatus according to claim 3, wherein the converter scales the second pixel brightness by a scale factor having a value in the range of 0.05 to 0.

1.

7. The image processing device according to claim 1 , wherein the logarithm is a logarithm to the base 2.

8. The image processing apparatus of claim 1 , wherein the perceptually uniform EOTF is the Motion Picture Television Engineers (SMPTE) ST2084 EOTF.

9. The image processing apparatus of any one of claims 1 to 8, wherein the perceptually uniform EOTF is the Motion Picture Television Engineers (SMPTE) ST2094-20 EOTF.

10. The image processing device according to claim 1 , wherein the perceptually uniform EOTF is an EOTF defined in ETSI TS103433.

11. The second converter circuit includes: storing at least two functions that map the first input lightness to the second intermediate lightness for every subrange of values ​​that the first input lightness can span, each of the at least two functions being a polynomial function; selecting a first function from the at least two functions as a function of a range within which a first pixel brightness falls; and determining a second intermediate pixel value of the first pixel color by applying the first function to the first pixel color.

12. receiving an image including pixels having a first pixel brightness encoded according to a perceptually uniform electro-optical transfer function (EOTF); converting the first pixel lightness values ​​to second pixel lightness values ​​encoded according to an EOTF defined by a logarithmic mapping from luminance to corresponding values ​​of the second pixel lightness values; applying a brightness adjustment process to the second pixel brightness; The converting step includes: applying a first logarithmic function to the first pixel brightness to generate a first intermediate pixel brightness by multiplicative scaling with an exponent having a value greater than one; generating a second intermediate pixel lightness by applying a second logarithmic function to the output value of the perceptually uniform EOTF for the first pixel lightness divided by a divisor equal to the exponent of the first pixel lightness; obtaining the second pixel brightness by adding the first intermediate pixel brightness to the second intermediate pixel brightness; An image processing method comprising:

13. The second intermediate pixel brightness is calculated as follows: [0013] where E ｉｎ represents the first pixel brightness, and EOTF (E ｉｎ 13. The image processing method of claim 12, wherein γ represents the output value of the perceptually uniform EOTF, γ represents the exponent, and x represents the base of the logarithm.

14. The first intermediate pixel brightness is calculated as follows: E １ｓｔｍｏｄ (E ｉｎ ) = γlog ｘ (E ｉｎ ) where E ｉｎ 14. The image processing method according to claim 12 or 13, wherein γ represents the first pixel brightness, γ represents the exponent, and x represents the base of the logarithm.

15. A computer program comprising computer program code means for performing all the steps of the method according to any one of claims 11 to 13 when said program is run on a computer.

Images