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

[kolak]

Main problem is that HDR holds a lot of data and you need to squeeze it into much "smaller" signal. It's not easy to make algorithm which knows what to pick, so human eye is happy. It's more than strict/pure math- it's like PSY encoding optimisation- at the and is eye which is not easy to be pleased.
This is why most advanced pro algorithms (eg. Dolby box) operate per scene on very complex math.

I think your approach with not adjusting pixels which are inside SDR signal is totally wrong here. It's more about relative pixel values not absolute. You need to convert HDR in the way that SDR "has the same look as HDR", so you definitely need to process all pixels in my opinion (but I'm not an expert). Image is a relative signal, not only inside the frame (+between the frames), but even to surrounding environment.

[jpsdr]

This is why most advanced pro algorithms (eg. Dolby box) operate per scene on very complex math.

Are you talking about (1) creation/mastering/encoding phase, or are you talking about (2) the decoding/display phase ?

If it's (1), as i've explained my thought, it's not an issue.

If it's (2), it would go on the oposite direction of display/decoding should be easy, simple. This way, product will be easy to mass product, and "cheap" enough for people to be able to buy, and manufacturer to sell.

Maybe you're right, maybe HDR display device implement high complex chipset/algorithm just to be able to display HDR video stream... But... doing something like this feels realy inappropriate according the "display must be easy" policy... This is the part i've realy a hard time do deal with, and for now (maybe at wrong), still not convinced...

I'm probably lacking the information of how a screen which is HDR compliant display/handle HDR stream. What are the steps between the HDR Y,U,V (or Y',U',V') informations of a specific pixel, and the "voltage" applied to the LCD/Oled of this specific pixel on the screen.

For SDR stream, it will be for sure a simple formula using only the value of this specific pixel to know what "voltage" (or how to "light on") is to be set on this specific LCD/Oled of the screen.
Now, if you said that for HDR stream, the display device needs a lot of complex analysis/information of a lot a pixels just to know how to "light on" one specific pixel, and not just only the informations of this specific pixel... Ouuua !!!
For me, it doesn't make sense, again, the "simple" policy is totaly broken.

But, if you're sure it's working like this...

Edit :
Something else which bothers me it it's realy like this. First, this would mean that there is not a unique precise spec (or a defined precise specific way) for displaying HDR (strange... but...).
And it would also result on the following situation :
I buy an HDR 4k Blu-Ray player, i buy an HDR 4k BR, and i buy 2 differents TV of differents manufacturer, but of course with the exact same quality/technology display (saying Oled).
According what you're saying (unless misunderstanding from my part), if i plug the 2 TV on the same player with the same disc, i may have different results because the 2 manufacturer may use different algorithm/chipset to make the display...???
That's... nonsense ! I can't beleive a specification (or a "no specification") like this.

[kolak]

I'm talking about HDR to SDR conversion, but...

In the same time even displaying HDR on TV which is HDR capable is hardly ever "passive" atm. There is massive processing (HDR TVs have crazy powerful video processors) going on in about every consumer HDR TV as in most cases they are not hitting 1000nits or are above this. Each TV does it in its own way.
HDR TVs will take mastering display info from video stream and use complex processing (which each company keeps as secret and puts a lot of R&D into) to convert ideal HDR 1000nits signal to its capabilities- e.g. they have to adjust gamut, max peak, etc
Read reviews for different TVs (e.g. here http://www.hdtvtest.co.uk) and you will see that 1 TV clips highlights, other has big smooth roll-off etc, etc. We are still far from every HDR TV look like reference displays. We are not really there even for Rec.709 after so many years!

You are correct- not only there is no fix formula (no SMPTE etc defined standard) for HDR to SDR conversion, but even for HDR displaying rules itself. TVs still do a lot of (own) processing (except reference TVs which use just PQ curve). Even reference ones (e.g. Sony BVM-X300) have some limitations which are taken into account during grading. At least they are calibrated to eg. P3, 1000nits and PQ "gamma".

Exception from this is DolbyVision which at least provides some standard processing and uses embedded Dolby metadata to "correctly" adjust signal to TV possibilities (and this is per scene!).
DolbyVision is mastered to e.g. 1K 2K or 4K nits (on reference TVs which can properly display such a signal), but also in the same time such a stream is accompanied by metadata which tells TV how to process signal in case TV peak value is e.g. 1400nits, or just 700nits. This is why DolbyVision look should be most consistent on different TVs. This is the whole idea and beauty of DV- to display HDR on TVs as close as possible to reference look on grading monitor.
Dolby has also special box (now also SDK I think) which allows you to "quickly" convert HDR into SDR using their specific math. This is designed to give visual "same look" for HDR and SDR (and also works per frame/scene).
Of course DolbyVision algorithm is strict secret and shared with software/TV manufactures after signing licensing agreement. At the moment this is probably the most advanced and defined HDR ecosystem out there. HDR 10(+) as far as it's defined format it's also a very wild "world" in the same time :) It may change soon once some (e.g. SMPTE) guidelines will be defined/published.

[kolak]

According what you're saying (unless misunderstanding from my part), if i plug the 2 TV on the same player with the same disc, i may have different results because the 2 manufacturer may use different algorithm/chipset to make the display...???
That's... nonsense ! I can't beleive a specification (or a "no specification") like this.

Well, in theory they should look the same, but practice is quite different. Even Rec.709 HD is still quite a big mess in consumer TVs.
In case of HDR there is way more to go wrong then in case of Rec.709. Simple things like how you map 1000nits master to e.g. 700nits (which is where most OLEDs are) as there are no defined standards or even guidelines for this.

Some TVs after calibration (consumer LG TVs now allow CalMAN to plug in into its internal color engine!) should be quite close to reference look, but you really need to make an effort to get "reference" look. If you have 6K£ buy Panasonic EZ1002, which can be calibrated (good PQ matching curve) very close to reference look, but still does only 700nits peak.

[jpsdr]

I had no idea HDR was such "a mess", and no SMPTE defined standard for even just HDR display is totaly... :eek:
It realy give a feeling of unfinished business, but release anyway, and leave each others deals with...:(

Well, thanks for all these informations, it makes things clear now (well... in a way of speaking...:p).
Knowing now what a mess it is, i think i'll give up my idea of trying to do an HDR to SDR convertion.
:thanks:

[kolak]

Why give up ?
Maybe you will come up with the best method out there :)

[jpsdr]

My idea was : Using the BT.2100/BT.2390, rolling back until camera/light information (revert EOTF, revert OOTF), and feed back again to an SDR system.
But... what you don't see in the BT.709 and the BT.2100 (because they don't talk about), and discover in the BT.2390 in Fig 7, 10, 11 & 12, it's the "surprise" step called "Artistic Adjust" after OOTF...

So, my idea was, if you look at Fig 12 for exemple, rolling back at least to "Image sensor" information... or, even more if possible, rolling back to light information what was in front of the camera. Then, replace the system by the one in Fig 10, feeding to it the "Image sensor" information, or, even more if possible, feeding the light information to the camera...

Of course, before seeing the BT.2390, i wasn't aware of the "surprise" step. Nevertheless, maybe it should be possible to "ignore it", and reversing the OOTF with the "artistic adjusted" data, considering the artist adjust was in fact a god who ajusted the light before the camera... ;)
When you look at these BT.xxxx, you see just straight pixel formula, and nothing more. Nothing which looks like complex image processing, so, nothing which prevent to do it. According these BT.xxxx, it's just direct math formula from A -> B, so, i can revert and doing B -> A.

But, it seems it was just a dream... Because if it was so simple, it would have allready been done.

[kolak]

I still dont get why these very new docs reference so much to CRT! It's time to forget about CRT, how it looked etc. Different reality. Yet they keep talking about CRT and referencing things against it.
They adjust OLED 6500K white point look to match old CRT look- what for? For whom- 60+ years old SMPTE members who remember CRT so well?

[jpsdr]

As i'm personnaly an ... "old" (cruel reality...) CRT guy, i may understand and explain the "why". My PC screen at home is a CRT.
First, we are here on subjectif aspect. My personnal point of view, is that i've until now found nothing which beats CRT on :
- Brightness/Darkness.
- Color restitution, how a flashy bright red, or a true deep blue is seen. (Also, big anime fan talking... ;))
So, resolution totaly appart, for me, it's the CRT which produce the best color result restitution. Nothing beats a good Sony Trinitron... ;)
LCD is a total no go for me. Plasma is good, well close but still not totaly... Oled is also probably good, but i've never had, so, never realy tested, so, i can't say, but it's my hope for my TV the day my plasma will die, as unfortunately, the SED technology seems a faillure because cost were too high.
So, personnaly i'm not surprised to see that CRT are used as "look" reference.
Never said CRT is perfect, for exemple, tune geometry is a nightmare, and will never be as perfect as "pixels" screen, and others flaws, but we are not here for that.
It may be different reality, but it doesn't mean you have to lower the quality of your reference.
After, there is a lot of subjectif aspect here. Maybe in a few decades you'll have your wish true... :D

[kolak]

Well- CRT is gone and it's a FACT, so don't agree that we have to keep coming back to it. CRT would not be practical in current reality- try making 50inch HDR CRT :) CRT geometry was terrible.

I also don't like the look of any LCD, but this is different matter. OLEDs looks more like CRT. Both are current technologies and this is what people look at, so what is the point to coming back to CRT look?

[kolak]

Nothing beats a good Sony Trinitron... ;)


Nope- Sony BVM-X300 is much better in about every aspect (even compared to old Sony reference CRTs).

[jpsdr]

Arrrghhh !!!!!!!!!! The price !!!!!!!!!!!!!!
I didn't know this, and i doubt i will be able to see one in my life :D.
But... it's "small", so even if i win at lotery, i'll probably not buy one.
Otherwise, it's Oled, so, even if i can't see it, i'll trust you for this one... ;).

[kolak]

This is much lower price than Sony CRT reference TVs costed at their times :) It's small as Sony struggles to make as good panel at bigger size. It's different panel than all consumer OLEDs are based on.

It's reference TV, but any OLED will do, e.g. LG OLED65B7.

[jpsdr]

...as in most cases they are not hitting 1000nits...

Unless i've misread the BT.2100 and the BT.2390, but according specs it can go up to 10000 ? (SDR go only up to 100).
I'm good ?
In that case, if i don't misunderstood the mastering information of my UHD BR, it says that max lum is at 4000 !!!
What the point when TV hardly achieve 1000... Another mystery.

[kolak]

This is another issue- Rec.2020 and HDR PQ are very forward looking standards and currently are "almost" impossible to achieve in practice (specially on consumer level).

This also why you hove those conversion problems. PQ is defined up to 10K nits, but most masters are using only 1K nits.
4K nits masters are DolbyVision ones which are graded on TV which is more like a prototype than real product (last I've heard it was using 23 AMPs:p ). There are also only few of them.
DolbyVision has some special metadata which TV (if DolbyVision compatible) uses to show 4K nits graded master on TV which is 700nits or 1K nits or 1.5K nits etc. In theory you know how this 4K nits master will look at lower peak brightness TVs. 4K nits masters are done as future proof. In next few years TVs will most likely be able to do 4K nits, so then your masters are ready and no need to spend money on grading session again. With DV 4K nits masters make some sense as it's closed and predictable ecosystem (your TV has to pass certification before it gets DV badge).
For HDR10 there is no such a defined math, so even bigger mess.

[jpsdr]

Ok, :thanks:

If i wanted to try HDR -> SDR, it that i wanted, for the title i've bought, make a denoising.
If i denoise the 4k video and then resize to 2k, i think the detail loss will be less noticeable than directly denoising 2k. For exemple, if the detail loss is 1 pixel radius, it will have less effect on 4k video resized to 2k, than directly applied to the 2k.
But the HDR -> SDR is so much troublesome, than i'll probably lose more on this part than i can gain on the other, so, i'll work directly on the standard Blu-Ray. Which is allready a little better (most part in the colors) than the previous 10 years release.

Ah... my dream would be one day to have access to a lossless video master file before compression, because compression breaks the total random part of the noise introducion not random parterns... :( But, it's also something i'll probably never seen in my life... For now, i have to deal with BR as masters. It's not bad, but i'm still dreaming... ;)

[jpsdr]

...DolbyVision has some special metadata which TV (if DolbyVision compatible)...
Does it mean that in the video stream there is more metadata than the "standard" SEI mastering information ?
Do you know, if, in the case of a classic configuration like this :
[Player] --HDMI-->[A/V Receiver]--HDMI-->[TV]
Is the TV being "DV" enough, or does all devices in the chain need to be "DV" ?
If not "DV", can these special metadata not be transmitted to the TV, meaning lost in the chain ?

[kolak]

Metadata travels with video over HDMI to TV (it just needs correct HDMI spec eg. 2.0b not sure). In theory it can be per frame, but in practice I think it's more like per scene.
When you create DV master you get video and XML which has this metadata. During H265 encoding for eg. UHD Blu-ray this metadata is inserted into SEI headers. There are also few version for some parts of it for eg. 1k nits, 700nits etc.

[jpsdr]

Ok, so only the TV needs "DV" label, and all the others devices in the chain just need the HDMI correct level.

[kolak]

Yes, player and TV need to be DV compatible- between them is just a standard HDMI (at correct level).
I assume same is for HDR10+ which is coming (except I don't know a software which generates metadata and how well it's "standardised"). As I said- DolbyVision is quite closed ecosystem, so can be controlled and give fairly consistent results (eg. like Apple products). In the same time it costs money (licensing is not cheap) and also makes all TVs look about the same (which is what TV manufactures don't want :) ).

[jpsdr]

In Fig.37 of BT.2390 there is a "scaling" step, to adjust white level.
If i have an (R0,G0,B0) pixel with white point at (X0,Y0), what is the formula (or where can i find it) to get the new (R1,G1,B1) values with the new white point at (X1,Y1) ?
If someone can help me with this, thanks...

Edit : Post edited, question more accurate.

[jpsdr]

I've been looking for SMPTE ST 2084 and SMPTE ST 2086 reference documents, but without succes. When i search, i found a lot of documents talking about them, making reference to them, but never themselves.
Does anyone know where i could find these documents ?
Thanks.

[videoh]

http://ieeexplore.ieee.org/document/7291452/

http://ieeexplore.ieee.org/document/7291707/

[jpsdr]

Thanks for the links.

Ah... You have to buy them, they are not free like the REC.BT.xxxx.
I understand now indeed why i wasn't able to directly find these documents. Obviously...

[videoh]

Welcome to the real world. ;)

[jpsdr]

Yes. They could have been like the Rec.BT.xxxx, but they weren't.
As i'm realy curious, i'll see later (probably next month) if i can buy them, and in both money aspect than just "Can anybody just buy them like that".
Or does it need to be affiliate/associated to something. Well... Anyway, it's not the point here, i'll see...

[shekh]

Metadata travels with video over HDMI to TV (it just needs correct HDMI spec eg. 2.0b not sure). In theory it can be per frame, but in practice I think it's more like per scene.
When you create DV master you get video and XML which has this metadata. During H265 encoding for eg. UHD Blu-ray this metadata is inserted into SEI headers. There are also few version for some parts of it for eg. 1k nits, 700nits etc.

I looked up HDMI in wikipedia and there is sentence "Static HDR metadata (SMPTE ST 2086)".
May someone explain at what point it becomes static? Is it hardcoded in the output port? Encoded in some kind of reset packet? Why it cant be sent per frame?

[kolak]

HDR10 defines only static metadata, so 1 for whole movie. It should be repeated at every new GOP. This is fixed set of info (gamut, white point, max light etc) which is added to h265 headers during encoding. It fixed already at grading/encoding stage.
HDR10+ adds dynamic metadata to sort of match DolbyVision. Still DolbyVision mastering and later TV decoding of this metadata is better defined and more controlled, so it gives more consistent results on different TVs. DolbyVision mastering stage is strictly controlled and dynamic metadata is exported from app which supports it. This is always done through Dolby licensed SDK, so gives the same result in different grading software. Later it's 'decoded' in every TV by the same math which is also licensed from Dolby, so together it's well defined system which gives 'consistent' end results. As far as I understand HDR10+ is not so well defined for grading or 'TV decoding' stage, so different TVs will give different end results.

[shekh]

I understand the idea at file level, but not how it is applied to HDMI. Well, I deduce that it is probably well unique per frame, just is the kind of metadata which belongs to "static" standard.

[kolak]

I assume there is a special 'data' channel so it travels with video+audio over HDMI (per frame).

[jkilez]

There is now a tone-mapping plug-in for avisynth+ that allows for HDR->SDR conversions: http://rationalqm.us/DGTonemap.rar

It currently supports both the hable and reinhard methods for tone-mapping.

[FranceBB]

There is now a tone-mapping plug-in for avisynth+ that allows for HDR->SDR conversions: http://rationalqm.us/DGTonemap.rar
It currently supports both the hable and reinhard methods for tone-mapping.

Any chance to get it working in normal Avisynth with Dither Tools at 16bit?


Ah... my dream would be one day to have access to a lossless video master file before compression, because compression breaks the total random part of the noise introduction not random patterns... :( But, it's also something i'll probably never seen in my life... For now, i have to deal with BR as masters. It's not bad, but i'm still dreaming... ;)

I work in Broadcast and we don't get uncompressed masters either; we generally get XDCAM (MPEG-2) or XAVC (H.264) or DNxNR at very high bitrates, but still compressed...
We also rarely get AppleProRes, which is lossless, but not mathematically lossless... Still it's an "hurray, hurray" when we get it.
If we are shooting something ourselves then it's different, but still, it's a sad sad world... :'(