Convert HDR to SDR

[zub35]

Hello!
How to make HDR conversion in SDR (fullrange 8bit bt709)?

Here are two examples, HDR and SDR.
HDR 2160p (UBDRip): https://yadi.sk/i/wP4oZQjo3F6BnZ
SDR 1080p (BDRip): https://yadi.sk/i/aXC0fsF73F6Bnh

If use a conversion madVR
http://s012.radikal.ru/i319/1703/4a/30402f28b209.png
That result looks like this
http://screenshotcomparison.com/comparison/202580/picture:0

upd: more samples https://cloud.mail.ru/public/2iEk/CiyUARGZy

[FranceBB]

FFMpegSource2 or LibawVideoSource can dither it down to 8bit 2160p for you, then all you need is a resizer and colormatrix.

Something like:

FFMpegSource2("video.h265", fpsnum=24000, fpsden=1001)

Spline64Resize(1920, 1080)

Converttoyv12(interlaced=false, matrix="PC709")

It's really simple as that. :)
Feel free to use Spline64ResizeMT for better performance, or any other resizer. If you want even more quality, use NNEDI, even though, for downscaling, Spline64Resize is generally enough.

[zub35]

FFMpegSource2 or LibawVideoSource can dither it down to 8bit 2160p for you, then all you need is a resizer and colormatrix.

Therein lies the difficulty, I could not figure out how to make this conversion, so that it is consistent with the result madVR and SDR-source :rolleyes:

[sneaker_ger]

It's really simple as that. :)
No, it's not. Much more complicated.

[MisterXDTV]

I have the same problem: I don't know how to encode/convert an HDR sample to SDR. Is it possible with avisynth?

[FranceBB]

Therein lies the difficulty, I could not figure out how to make this conversion, so that it is consistent with the result madVR and SDR-source :rolleyes:

Ok, so if both ffms2 and libaw screw levels while dithering, then maybe how about using the 10bit hack to import the HDR source directly into avisynth and then use the Dither Tool to dither down to 8bit instead?

[zub35]

FranceBB, I think that the Y-component needs to be cut somehow before converting from 10 to 8 bits.

Simple conversion gives a faded result. Without contrast аs SDR.
MadVR does this via pixel shading, additionally applying filtering compress highlights.

From 10 bits to 8 bits, this is one case with the application of dithering.
But the conversion of HDR to SDR here is already a more complicated case, and is not limited to just dithering.

Example of a file with HDR and example necessary result - I gave. If necessary, I will provide more examples of HDR&SDR sources.

Maybe for proper conversion, is needed new plugin or new instructions in Avisynth+

[kolak]

FFMpegSource2 or LibawVideoSource can dither it down to 8bit 2160p for you, then all you need is a resizer and colormatrix.

Something like:

FFMpegSource2("video.h265", fpsnum=24000, fpsden=1001)

Spline64Resize(1920, 1080)

Converttoyv12(interlaced=false, matrix="PC709")

It's really simple as that. :)
Feel free to use Spline64ResizeMT for better performance, or any other resizer. If you want even more quality, use NNEDI, even though, for downscaling, Spline64Resize is generally enough.

It's way more complex and to get decent results you need very clever adaptive algorithms. It needs something as revolutionary as e.g. NNEDI3 etc. Big companies (e.g. Dolby, Technicolor) are working on it.

[FranceBB]

Unfortunately, yes, I noticed.
When I did it and I saw washed out colours and blacks I was disappointed as I didn't think it was a complex thing, but I was wrong. :(

[jpsdr]

No, it's not. Much more complicated.
Do you have a link, by any chance, which explain where the complexity lies ?
Because i didn't realy understand where it could be.
The only thing i may see whould be just if there is a non-linear function somewhere, and instead of just a linear matrix :
YUV (REC2020) -> RGB -> YUV (REC709)
you would have :
YUV (REC2020) -> (linear matrix) R'G'B' -> RGB (with non linear function) -> YUV (REC709) (linear matrix).
So, if you have any link which may explain the detail/specificiation of it, and why it's more complex, i'm curious.

[sneaker_ger]

It is non-linear. I don't have a good link, though. Try searching for HDR10, Perceptual Quantizer (PQ) or SMPTE ST 2084PQ.

[kolak]

Unfortunately, yes, I noticed.
When I did it and I saw washed out colours and blacks I was disappointed as I didn't think it was a complex thing, but I was wrong. :(

Try using Resolve for this:

http://www.mysterybox.us/blog/2016/10/27/hdr-video-part-5-grading-mastering-and-delivering-hdr

[jpsdr]

I have the feeling i'm missing or don't understand something.
The video (in H265 for exemple), has to be decoded to "standard" RGB values to be displayed, otherwise the display will be wrong. I can understand that in the process of the creation of the UHD Blu-Ray (for exemple), there is some non-linear parts, but, after, this has to be displayed, so the decoder during one step of the process has to "reverse" this, to create a "standard" RGB. Meaning, there is a "simple" equation/formula to do this, otherwise, it would not be possible to display such streams.
... There something i've the feeling i'm missing...

[manolito]

Have you seen this post in the VapourSynth thread? Looks interesting...
https://forum.doom9.org/showthread.php?p=1800667#post1800667

[Andrew25]

Try using Resolve for this:

http://www.mysterybox.us/blog/2016/10/27/hdr-video-part-5-grading-mastering-and-delivering-hdr

That's a pretty useful link! Thanks for that.

[jpsdr]

I've got informations here :
BT.2020 (https://www.itu.int/rec/R-REC-BT.2020/en)
BT.709 (https://www.itu.int/rec/R-REC-BT.709/en)

From what i've understood (some, anyone else is free to read and correct me if necessary) :
The gama correction formula is the same between BT.709 and BT.2020.
But, in BT.2020, there is two YCbCr possibilities, when there is only one in BT.709.
If you are in what they call "Non-constant luminance", the standard linear matrix formula will work, and the usual method used for doing BT.601 <-> BT.709 conversion will also work with BT.2020.
But, if you are in what they call "Constant luminance", things are differents !
But with these documents, we have all necessary formula to make HDR/SDR conversion (i think...).

[kolak]

"Non-constant luminance" is used way more for Rec.2020.
For HDR you actually need to look at HDR10 (SMPTE ST-2084, HLG, etc), which I assume should give you some hint how to go from HDR to SDR. Also, looks like things going to be shifting into Rec.2100 with new ICtCp color space, which meant to improve compression by 10%.

[jpsdr]

The problem, is if you are in "Non-constant luminance", i don't see what could prevent HDR/SDR conversion like described in post #2 working...:confused:
Except in post 2 it's missing BT.2020 somewhere...
I would see more
ConvertToRGB(matrix="REC2020") (don't remember exactly the name of matrix).
ConvertToYV12(matrix="PC709")
But according document, doing this should work on "Non-constant luminance".

[kolak]

I don't know, but HDR to SDR is not trivial. It's more about how to shrink all these HDR info into much "tighter" SDR signal avoiding any tint, hue shifts etc. I know that eg. Technicolor is trying to make some tools for semi automated conversion. This tool analyses each scene an uses some adaptive conversion.

It ca be doe with fixed math- Resolve has node (and LUT) for it and this is rather simple fixed math.

[jpsdr]

I see nothing of the sort in the R-REC-BT.2020-2-201510-I!!PDF-E document, maybe this document is not enough to convert BT.2020 and don't cover the whole part, but i thought it would be... :(
Or... i've missed it in the document...?
Didn't see the edit part, i'll look for this.

Edit
Found things here (https://www.itu.int/md/T17-SG16-170116-TD-PLEN-0082/en) on ITU... But access only to ITU users... Seems to be difficult to get proper informations.
It seems maybe there is things here (https://www.itu.int/rec/R-REC-BT.2100/en). Bigger than others, it will take a little more time to understand properly i think.
There is also the R-REP-BT.2390-2016-PDF-E document.

Edit 2
WTF !!! I've begin to try to read the R-REC-BT.2100-0-201607-I!!PDF-E document, it's horrible, and yes... not so easy at all.

[dipje]

First thing to learn about HDR (to SDR) is that it's not as simple as converting bitdepths and colorspaces. There is a different gamma-encoding at play too, and more importantly, HDR talks about light levels, not 'pixel values'.
HDR files can contain soo much more light and color gamut than a regular SDR encode, that you can't 'save it all'. If you just convert the bitdepth, gamma and color primaries you still up end up with _way_ too much signal to display in a regular 0-255 range, resulting in most of the movie will be _very_ dark and undetailed, and only in certain scenarios will it use the full brightness in the direction of '255' values. Think of a few explosions or a single shot straight into the sun or something.

So the simplest thing to do is to clip a bunch of the (high)lights, and adjust the resulting video with a gamma-change till you think _most_ of the movie looks OK. If some scenes are too dark or clip too much, well, that's too bad.
If you don't just use a gamma change but also some kind of highlight compression you can maybe save more highlights, but still.

This is where the magic of MadVR's HDR-to-SDR stuff comes in. It's basically constantly re-evaluating the boost, the cut-off, the compression in highlights, the compression in shadows, the compression in gamut to have something 'enjoyable' to watch.
Unless you can capture the output of MadVR, or you have similar filters / algorithms in Avisynth or Vapoursynth, there is no way to get 'the exact same' effect as MadVR.

Using a Lut with transform functions sits somewhere in between. It's a more advanced gamma-change, but still a static mapping, not a dynamic one as I believe MadVR does.

The best method is to load it into a video editor and go on it with a scene-by-scene basis where do you want the blackpoints, whitepoints, shadow compression and highlight compression to be.. and the saturation to control the gamut. But this is tedious work

High bitdepth stuff I mostly do in Vapoursynth.
Having loaded the source, I convert it to RGB taking the bt2020 transform into account (There are two, or even more, not a single 'bt2020' watch it :)). That RGB I convert to linear-RGB (make sure to be at least in 16 bits, maybe even 32-bit float) saying the source gamma (once again, there are multiple gamma encodings for different HDR standards). Once in linear RGB you can convert the color primaries to your target primaries (from bt2020 to bt709 I'm guessing, but once again, there are different files and standards out there). Not that color primaries is not the same thing as the yuv<->rgb color matrix, although you will see things as bt2020 and bt709 in both.
Then, while in linear RGB but in the correct color primaries, I use Vapoursynth 'levels' to clip of some highlights, and do a gamma adjustment. Then I convert from linear-RGB back to gamma-correct sRGB, and then from there it's 'easy' to go back to yuv444 in bt709 and then subsample to yuv420 , dither and encode as a regular yv12-8bit sdr encode. The 'levels' and 'gamma change' are according 'to taste', there is no magic number here (and like said before, will not be perfect for a whole movie but you do the best you can).


Remember, as I see it in a dumbed-way-down kind of way: HDR files don't talk about pixel values anymore, there is _no_ simple conversion. They describe the amount of light (and in what color) that should be coming out of your monitor / TV. Then, your monitor / TV tries it's best to actually realize that or come up with a interpretation that best fits it. If a file talks about light levels of 1500 nits or more, and most TV's have a maximum brightness of (well) under 1000 nits, there has to be some algorithms to come up with 'the best interpretation of...'. The HDR light data is 'mapped' to whatever your monitor / TV / projector is capable of. And yes, this differs per monitor / TV / projector since they all have different capabilities,
So, judge a 'HDR monitor' not only by how bright it can go and how much of the color gamut it can match, but also by the quality of the algorithms that try to map the HDR data onto it's screen, since there is no 'single answer' or '_THE_ algorithm' for this. The same reason that the HDR-MadVR conversion asks for the maximum number of nits of your screen. And also why HDR files need metadata like the minimum and maximum light levels encountered in the file, so the algorithms know what to expect (although without these you can still make a good effort).


Basically, if you just do the colorspace / gamma/ primaries / bitdepth conversion, you still end up with 'raw' HDR data displayed on a SDR screen. What then is missing is the 'tone mapping' step in between. Everybody who shoots with a (good) digital camera and played with the bayer-RAW files (or X-trans for the Fuji guys :P) from these camera's know what the tone mapping is... HDR photographers who merge multiple exposures to get a HDR shot and play around with HDR software knows what 'tone mapping' is.

[jpsdr]

So, you mean that a player supposed to be able to play HDR and send it to "any" display screen (so outputing standard RGB value by HDMI for exemple) has a hell of things do do ?
What's happening if i get an... HDR mkv file for exemple and start it on my PC ? Will it be finaly displayed properly or not ?
Because in all of this, you have in final to have something which output standard RGB to be able to be displayed ? Or am it still missing something (it's realy the feeling i have).
Or, if i play an UHD Blu-Ray (but maybe these are not HDR...), to be displayed properly on any screen, the player has to output standard RGB... Again, i'm a little confused with it.

[zub35]

In HDMI 2.1 there was a so-called dynamic HDR (HDR dynamic metadata)
Maybe this will help somehow ...

Dynamic HDR ensures every moment of a video is displayed at its ideal values for depth, detail, brightness, contrast, and wider color gamuts—on a scene-by-scene or even a frame-by-frame basis.

upd: In the first post I added a link to more samples

[sneaker_ger]

What's happening if i get an... HDR mkv file for exemple and start it on my PC ? Will it be finaly displayed properly or not ?
In most players it will look washed out. You can use MPC-HC + madVR and set-up the display in madvr to get some kind of proper output.


Or, if i play an UHD Blu-Ray (but maybe these are not HDR...), to be displayed properly on any screen, the player has to output standard RGB... Again, i'm a little confused with it.
UltraHD Blu-ray supports HDR and indeed the player converts to SDR unless the display has support for HDR input via HDMI.

[wonkey_monkey]

Using Avisynth+, what's the best way to open the HDR rip in the first post to get back 10-bit frames?

I've tried installing LSmashSource and using LWLibavVideoSource but that just gives me what Avisynth claims is a YV12 clip which is green and stripey.

Alternatively, could someone make a 16-bit PNG, or as stacked 8-bit PNG, out of this frame (screenshotcomparison.com/comparison/202580/picture:0) that I could play with?

[sneaker_ger]

Try ffms2. L-smash doesn't output native 10 bit as supported by AviSynth+.
But if you don't know about >8bit handling in AviSynth you will have problems...

[wonkey_monkey]

Not mainstream ffms2, though? I need one of the forks, right?

(Gah, this is confusing)

[sneaker_ger]

If you want native AviSynth+ formats you can use latest mainstream ffms2. If you want "hacked" use l-smash.

[jpsdr]

UltraHD Blu-ray supports HDR and indeed the player converts to SDR unless the display has support for HDR input via HDMI.
So, it means, staying in the exemple of UltraHD Blu-ray, that in the... H265 stream for exemple, with the YCbCr data, there is also additionnal informations allowing proper HDR decoding ?
So, if these data are present in an HDR stream, it means that it's up to the codec to use them to proper decode HDR stream, but for now, the codec are not updated or able to use them.
The thing i have trooble with is, when i read all of this, the first feeling is that "nothing can properly read HDR stream". Which is totaly stupid and illogical, so, i must miss something.
An UltraHD Blu-ray player can convert HDR to SDR, so... What prevent a PC player codec to do that ?
Is it because on PC, no coded/player is able to get the added meta data in the video stream ? If i get an HDR stream, these data have to be in it, otherwise, nothing would be able to play it.
Is it because the informations needed to do that are "closed" ?
This is what i've trouble with.
I mean if you said, for exemple "Indeed, in your H265 HDR stream, there is the YCbCr compressed video information, and there is also metadata avaible to properly decode the HDR, but for now, the codecs are only able to decode the video, and are not able to use the meta data information for... whatever reason (license, closed, etc...)", Ok fine.
But, i would like, if possible and if anyone know why, having an answer. Why a PC can't do what an hardware player can...:confused:

[sneaker_ger]

An UltraHD Blu-ray player can convert HDR to SDR, so... What prevent a PC player codec to do that ?
Is it because on PC, no coded/player is able to get the added meta data in the video stream ? If i get an HDR stream, these data have to be in it, otherwise, nothing would be able to play it.
Like I said earlier: MPC-HC/LAV + madvr can play it - well, at least the common HDR10/VP9 PQ kind. They can read the HDR metadata that's contained in an HEVC stream or MKV/WebM container and use it. (What madvr does not yet support is using the "native" HDR format of HDMI. The Microsoft APIs for that are fairly recent.)

Is it because the informations needed to do that are "closed" ?
It's always that way with new technology. How long till MPC-HC/madvr supported 3D? Part is lack of interest of developers. Part is missing APIs. Part the "closed" nature of some specs or simply missing samples to test with (e.g. in the case of Dolby Vision). "Missing samples" also implies "lack of interest" because it means no one needs the feature.

[jpsdr]

Ok, thanks, i have my answer now.

[dipje]

Basically understanding the video signal is not closed, and not 'that' special really.

But the video-information that is in an HDR file (after decoding) then needs to be 'mapped to the screen'. Since this is different for every screen, this 'mapping stage' is done _in the screen_ so to say. This tone-mapping stage was not (really) present in SDR, and is an aspect of the HDR-movement that a lot of people (even here on doom9) don't know of or seem to forget.

If you're on an older monitor (or maybe even an HDR screen) the best method I know of now is to play HDR files through a (very) recent MPC-HC with a somewhat recent MadVR as has been stated here. You then need to tell MadVR how bright your screen can go (since MadVR has no way of knowing this) and it will do it's best to display it.
Yes, that means that if you have a 8bit (or even 6 bit like is more common that you might think) SDR panel and you tell MadVR your screen is around 300 nits, it will do a very descent HDR-to-SDR conversion.

If you have a new fancy screen with good contrast and very high brightness (SDR or HDR, doesn't matter now) you can tell MadVR you have a brighter screen and it will take that into account while doing the conversion / tonemapping.

Mapping the light-and-colour-intensity information in an HDR file to pixel values (like RGB or YUV) needs information of the screen you're displaying it on..and since a screen knows itself the best, the tone-mapping algorithms are in the screen, not the media player. (things like your lightning situation _around_ the screen, the ambient lightning, also matter and good HDR tvs will have different presets or something for this). Also, there is no 'standard' or 'one true correct way' to do this tone mapping, so it also isn't part of the HDR standard or something. The HDR media-file-standard just presents you with light and colour intensities. You have a screen that wants RGB values for the pixels. How you go from A to B is not part of the standard.

This is why a lot of people now play HDR content by placing the HDR file on an USB stick or something and plugging it into the TV, and let the smart-TV portion of the TV play the file. This is the simplest method :).
Otherwise, madVR on the desktop. Maybe recent things like Windvd or something have some sort of HDR support? I'm just guessing there.

[kolak]

So, you mean that a player supposed to be able to play HDR and send it to "any" display screen (so outputing standard RGB value by HDMI for exemple) has a hell of things do do ?
What's happening if i get an... HDR mkv file for exemple and start it on my PC ? Will it be finaly displayed properly or not ?
Because in all of this, you have in final to have something which output standard RGB to be able to be displayed ? Or am it still missing something (it's realy the feeling i have).
Or, if i play an UHD Blu-Ray (but maybe these are not HDR...), to be displayed properly on any screen, the player has to output standard RGB... Again, i'm a little confused with it.


That's why Blu-ray stores this info in h265 headers:


SMPTE ST 2086 mastering display color volume SEI info, specified as a string which is parsed when the stream header SEI are emitted.
The string format is “G(%hu,%hu)B(%hu,%hu)R(%hu,%hu)WP(%hu,%hu)L(%u,%u)” where %hu are unsigned 16bit integers and
%u are unsigned 32bit integers. The SEI includes X,Y display primaries for RGB channels and white point (WP) in units of 0.00002
and max,min luminance (L) values in units of 0.0001 candela per meter square. Applicable for HDR content.

Example for a P3D65 1000-nits monitor, where
G(x=0.265, y=0.690), B(x=0.150, y=0.060), R(x=0.680, y=0.320), WP(x=0.3127, y=0.3290), L(max=1000, min=0.0001):

G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)

--max-cll <string>
Maximum content light level (MaxCLL) and maximum frame average light level (MaxFALL) as required by the
Consumer Electronics Association 861.3 specification.


Example for MaxCLL=1000 candela per square meter, MaxFALL=400 candela per square meter:
–max-cll 1000,400



Ideally you want TV which can meet this parameters, but if it doesn't then it may have some processing built in to compensate possible differences.

DolbyVision goes step further as it standardises math behind this needed conversions in order to have consistency. It can also use dynamic metadata which is stored per scene in order to optimise end experience per scene depending on the user screen.


First:

The Dolby Vision workflow is very similar to existing color-grading workflows.
The goal is to preserve more of what the camera captured and limit creative trade-offs in the color- grading and mastering process.
The Dolby Vision HDR reference monitor (capable of up to 4,000 nits luminance) is used to make the color and brightness decisions.
The goal of the Dolby Vision grading process is to capture the artistic intent in the reference grade. Directors, editors, and colorists
should use the grading system and the monitors to make the best, most engaging imagery they can, taking full advantage of
the dynamic range of the display.
After the reference grade is fnished, the Dolby Vision color-grading system will analyze and save the dynamic metadata that
describes the creative decisions made on the display. The content mapping unit (CMU) maps the content with the metadata
to a reference display at a standard brightness (100 nits).
After the Standard Dynamic Range version has been approved, the colorist exports the images with metadata.
The dynamic metadata generated to create the SDR grade can be used to render the Dolby Vision master on displays, which may
offer a wide performance range.
A 600-nit TV will look great; a 1,200-nit TV will look even better— both referencing the same metadata and Dolby Vision
reference images. The same algorithms used in the Content Mapping Unit for off-line grading can be used to create a traditional
compatible grade for live broadcasts in Dolby Vision.

Then:

A major difference between the Dolby Vision approach and other HDR solutions is the metadata that accompanies each frame
of the video all the way to the display manager in the consumer-playback device. Systems with generic HDR carry only static
metadata that describes the properties of the color-grading monitor that was used to create the content and some very basic
information about the brightness properties (maximum and average light levels) for the entire piece of content.
Dolby Vision adds dynamic metadata that is produced during content creation; the dynamic properties of each scene are captured. With this
information, the Dolby Vision display manager is able to adapt the content to the properties of the display much more accurately. It allows
hues to be preserved properly, which is critical for display of skin tones. Even with mass- market edge-lit TVs,
the overall impression of colors is preserved much more accurately.
Guided by the Dolby Vision metadata, the Dolby Vision display manager enables great visual experiences on a wide range of display devices
ranging from higher-end OLED TVs with stunning black levels to LCD TVs with advanced technologies like quantum dot, all the way down to
mass-market edge-lit TVs.

More TVs are getting DolbyVision, so with correctly mastered HDR Blu-ray your end result should be very decent regardless if you have high-end TV or rathe basic one (assuming it has DolbyVision support).

[jpsdr]

videoh has updated the DGIndexNV tools to HEVC-10/12 bits, and also has the possibility to extract the HDR metadatas (when present).
For now, they are put in the index dgi file.
It may be not the perfect thing, but at least there is something, and it's a big first step.
Now, to try to improve this and make a second step, does anyone has any idea how these data could be send directly to avisynth's frames, without the need to get them on an external file ?

The only stupid thing i tought is to use the alpha channel plan...:p

[pinterf]

videoh has updated the DGIndexNV tools to HEVC-10/12 bits, and also has the possibility to extract the HDR metadatas (when present).
For now, they are put in the index dgi file.
It may be not the perfect thing, but at least there is something, and it's a big first step.
Now, to try to improve this and make a second step, does anyone has any idea how these data could be send directly to avisynth's frames, without the need to get them on an external file ?

The only stupid thing i tought is to use the alpha channel plan...:p
Implementing frame properties, like VS

[videoh]

Implementing frame properties, like VS Does Avisynth+ support frame properties? If so, where is it documented? Thank you.

[pinterf]

Does Avisynth+ support frame properties? If so, where is it documented? Thank you.
No, does not support, that's why it needs to be implemented :-)

[jpsdr]

I've looked at R-REC-BT.2100-0-201607-I!!PDF-E, and want to check if i've understood properly.
In case of PQ configuration, if i want to do a HDR to SDR convertion, with input parameters Y, Cb, Cr comming from an HDR h265 stream, i have to do the following :
Compute R,G,B from Y, Cb, Cr using standard linear matrix BT.2020 coeff.
Then, "delinear" R, G, B to R0, G0, B0 using function (for R for exemple) R0=f(R) with f(x)=EOTF with EOTF is L(V) in the eq.1 page 15 (Annex
3).
Then, finaly, do a (BT.709 matrix for exemple) linear combination of R0, G0, B0.
Is it right ?

What is the relation between the parameters in the formula, and the SEI mastering information in for exemple an HDR h265 data stream ?

mastering_display_colour_volume =>
display_primaries_x[0]
display_primaries_y[0]
display_primaries_x[1]
display_primaries_y[1]
display_primaries_x[2]
display_primaries_y[2]
white_point_x
white_point_y
max_display_mastering_luminance
min_display_mastering_luminance

content_light_level_info =>
max_content_light_level
max_pic_average_light_level

[TheFluff]

I'm not sure if I understand you correctly but you might be interested in this discussion: https://github.com/sekrit-twc/zimg/issues/61#issuecomment-269100013

[jpsdr]

I'm not sure i've understood properly, and i can't correlate the SEI HDR informations with the parameters in the formula.
For exemple, L(V)=((c-(V-m)*s*t)/(V-m-s))^(1/n). So, how do i get c, m, s, t, n values from the following mastering informations values :
mastering_display_colour_volume =>
display_primaries_x[0]
display_primaries_y[0]
display_primaries_x[1]
display_primaries_y[1]
display_primaries_x[2]
display_primaries_y[2]
white_point_x
white_point_y
max_display_mastering_luminance
min_display_mastering_luminance

content_light_level_info =>
max_content_light_level
max_pic_average_light_level

Edit :
After reading, my question would be more : How do you use these mastering informations in the equation formula ?
It seems that c, m, s, t, n are static defined values.
Despite reading docs, i still can't figure out the equation of the last step : Non linear R,G,B to linear R,G,B.
The EOTF is clearly involved, but how the mastering informations are used, and how exactly the EOTF equation is used ?

[kolak]

What is the relation between the parameters in the formula, and the SEI mastering information in for exemple an HDR h265 data stream ?

mastering_display_colour_volume =>
display_primaries_x[0]
display_primaries_y[0]
display_primaries_x[1]
display_primaries_y[1]
display_primaries_x[2]
display_primaries_y[2]
white_point_x
white_point_y
max_display_mastering_luminance
min_display_mastering_luminance

content_light_level_info =>
max_content_light_level
max_pic_average_light_level

This maybe the part which is up to you. Simple math won't give good result over long HDR master. It rather has to be adaptive system which analyses each scene and adapts depending on its nature. You can also have simple system which uses constant formula, but includes these mentioned parameters. I assume you would do it differently if master would have average light of 300 nits and e.g. 2K nits.

[jpsdr]

It rather has to be adaptive system which analyses each scene and adapts depending on its nature.
From my point of view, it "can't" be that, for the following reason : Display devices have to be able to display properly on any screen, so they have to be able to convert/revert 4k HDR to the linear componants, in real time, without the need of ultra high speed and ultra high cost capable processor which would have to analyse each frame before converting => There must be a proper conversion formula using these SEI/Mastering informations, otherwise it would not be possible to make display devices at "low" cost, and also, what purpose would have these informations ?

[kolak]

There is, but results are far from perfect.
Min. light, average light etc. are not going to add that much into your formula- some scenes will still look bad (as they will be e.g. way below or above average light). About all HDR master are graded to P3 now, so you can use this blindly (or read from headers).
Atm. no one really watches HDR content as SDR on their TVs. Low cost TVs will do crappy conversion as most cheap TVs have crap panels/processing anyway.

That's why you have DolbyVision (which is spreading into many TV brands now) which requires proper chip to handle all conversion in realtime per scene. This was made exactly for that reason- to accurately "convert" HDR master to screen possibilities. I'm not an expert, but I know that converting HDR to SDR is not that easy at all and big boys work on such a software/boxes and they are rather adaptive.

[zub35]

Every day the HDR content becomes more and more. Is there no way to convert?
Otherwise it turns out that the computer resources are essentially wasted on multiple hdr conversion in sdr using madvr. Again and again
While it is rationally to do this once.

madshi Perhaps read this, and help society create a avisynth plugin ;) thank

[TheFluff]

I think twc has been looking at ITU-R's "standard" display mapping methods in BT.2930-2 for implementation in zimg, but nothing yet.

[tyee]

This guy has a very interesting article (http://www.wesleyknapp.com/blog/hdr) on grading an HDR video using a REC.709 monitor. He includes a download that has a LUT. Maybe we can use it for HDR-SDR conversion.

[jpsdr]

From what i've understood, UHD BR can be HDR, but it's not mandatory. 4k/UHD doesn't always mean content is HDR, these are two different things.
So my question is (even if UHD BR not HDR may be very unlikey), i bought an UHD BR, i manage to rip it, is there a way i can chek it the content is SDR or HDR ?

[microchip8]

From what i've understood, UHD BR can be HDR, but it's not mandatory. 4k/UHD doesn't always mean content is HDR, these are two different things.
So my question is (even if UHD BR not HDR may be very unlikey), i bought an UHD BR, i manage to rip it, is there a way i can chek it the content is SDR or HDR ?

media info reports that. Check if it has mastering display and content light level side data. if it does, it most likely is hdr

[kolak]

From what i've understood, UHD BR can be HDR, but it's not mandatory. 4k/UHD doesn't always mean content is HDR, these are two different things.
So my question is (even if UHD BR not HDR may be very unlikey), i bought an UHD BR, i manage to rip it, is there a way i can chek it the content is SDR or HDR ?

Check Transfer Function value.
If it's:
16 SMPTE ST 2084 (PQ)
or
18 ARIB STD-B67 (HLG)

it means it's HDR. It can be also DolbyVision which is yet another story and it uses own flagging. There is nothing opens source which can read DolbyVision atm. so you don't have to worry about this one.

As you said in other thread- UHD doesn't mean HDR. UHD signal can be also SDR mastered as Rec.709 or P3 or Rec.2020.

[jpsdr]

Over and again the same thing...:(
I'm still struggling with some points i've hard time to deal with, maybe somes of you can inlight me.
Big post, explaining how i undestand/see things. Maybe what i see or thing is not what is the real case, so you can correct me if i'm wrong.
For the record : I don't have an HDR display device.

Since the first age of television, it has always been the same, video can be hard/difficult/not cheap to make or record (would it be PAL/NTSC/SECAM modulation or H264/H265 encoding), but display devices has to be simple. Simple means easy to manufactur in large number, easy for fix and cheap, so you can sell them. So, one word, simple.

Now (correct me if i'm wrong on this) not all 4k TV can display HDR content. From what i'vve understood, you have on TV channels (Netflix is one of them) 4k videos but not HDR.
You can also buy a 4k BR player, and 4k Blu-Ray. I can't imagine, in a manufacturer/money/selling part point of view, that someone who buy a 4k TV, a 4k player, will be unable to watch his Blu-Ray just because the TV is not HDR, and the 4k Blu-Ray he bought is. I don't see any big sticker saying "WARNING !!! Having a 4k TV is not enough, your TV must also be HDR" on 4k Blu-Ray.
And remember, simple. So, if i assume a 4k Blu-Ray player can display HDR on SDR display, it can't be complex thing like histogram or picture analyse, it's not simple, so i'ts not cheap, and it has to be.

Other things (but correct me also if i'm wrong here), technology is still "the same". It's the same LCD/Oled you have on SDR or HDR. So, in all the process of converting original video stream to the electical signal lighting up the pixel, at one point, they have to converge so the same thing, because the final output is the same. So, the HDR and SDR chain process to display, has to meet at some point.
If you have a full HDR set-up : 4k Blu-Ray player and HDR display device. You bought a title which have both Blu-Ray and 4k HDR Blu-Ray. If you put BR or 4k HDR BR on your player, they will both be displayed properly, and they'll be visualy "the same", meaning, at the final stage, the voltage to light up the LCD/Oled pixel is "the same", so, begining with 2 different video stream, display device produce the same final information.

HDR (Xh) -> Processing \
(Vdisplay) -> voltage to light pixel.
SDR (Xs) -> Processing /

So, basicaly, we have Vdisplay=Fhdr(Xh)=Fsdr(Xs).... I would said, Xs=Fsdr-1(Fhdr(Xh))
Of course, HDR extand the display range of SDR, so there is things which can be displayed only on HDR, so these parts will be displayed differently between BR and 4k BR. But :
- Nothing prevent you to create HDR content, but with content staying within the range of SDR.
- For the HDR video, not all the pixels, even not all the areas of the picture will be outside SDR range. For these parts, where on the HDR video content stays in the SDR range, the display result will be exactly the same.

Another thing, SDR/HDR don't work the same, so, this is why you can't display HDR on SDR display. But, the other way is the same. If HDR TV were "pure only" HDR, they shouldn't be able to display SDR, but they can, so, what's happening here ?
Do they convert SDR to HDR ? In that case, knowing how it's done may help for converting HDR to SDR.

This i why, i can't take of my mind, that mastering informations you find in HDR stream are used by HDR display devices to properly display content. My issue is even reading again and again BT2100/BT2390, i didn't see any link, and can't see where or on what step they have to be used.

Question : Does anyone how have an HDR display device have tried (don't know if it can easely be done) to take an HDR video, change only the mastering information, and see if it's still displayed properly ? (One way to do this would be to decode/re-encode with different mastering information).
If the content is not displayed properly anymore, it would mean that HDR device needs this information at one point, and that i'm at least "right" somewhere. But again, where and in what formula are they used ? There is nothing about it (or i've missed it) in the BT2100/BT2390.
I think the result of this experiment would be very interesting, so if someone is able to make this experiment, it would be very helpfull.

Now, talking a little about the REC-BT.xxxx.
When i look at them, there is THE first non-linear step :
E'=F(E) (E'=R' or G' or B').

E is : voltage normalized by the reference white level and proportional to the implicit light intensity that would be detected with a reference camera color channel R,G,B; E' is the resulting non-linear signal.

From what i've read (unless i've missread), if we can easely convert by simple linear matrix BT.601/BT.709/BT.2020 SDR video, it's beacause :
- F is the same for all.
- The "reference white level" is the same for all.
Now, HDR :
- F is not the same.
- The "reference white level"... well... could it be where mastering information are used in...?
So, my question is, for HDR to SDR, what prevent from doing the following :
- Convert back E' values to E values.
- Denormalize (Still question, is it here mastering value are used ?).
- Re-normalize but now with SDR values.
- Convert E to E'.
Basicaly, the global rough idea is to retreave the light information that was in front of the HDR recorder, but it in front of the SDR recorder, and record back.
This may seems complex, but it's a lot less that histogram or anything picture analysis. Even if it uses more complex mathematic function that simple multiplication/addition, we are in a single line function process :
(Y',U',V') -> (R',G',B') -> (R,G,B) -> Denormalize HDR -> Normalise SDR -> (R,G,B) -> (R',G',B') -> (Y',U',V').

Your toughts...:confused:

It's of course absolutely not related to the fact that yesterday i got in my hand my first UHD Blu-Ray, and that i've been able to rip it on my HDD because i have a "friendly" drive... :D