Encoding 4K HDR 4:2:0 10bit BT.2020

[surami]

I would like to make a test encoding to 4K, HDR, 4:2:0, 10bit, BT.2020, something like I found here (http://www.demo-uhd3d.com/categorie.php?tag=hdr) (these are playing back properly on my TV), but if I use this line, then I get a video with strange yellowish, bluish colors:
avs4x26x-x64.exe -L "F:\x265\Win64_16bpp\x265.exe" --seek-mode safe --preset slow --subme 7 --no-open-gop --crf 17
--profile main10 --level-idc 5.1 --colorprim bt2020 --colormatrix bt2020nc --input-depth 8
--output "D:\encoding\x265_4k_420_10bit_bt2020.hevc" "signpost.avs"
pause

Should I have to write additonal commands too? --chromaloc --master-display --max-cll --min-luma --max-luma
or where is the problem?

I know, that I have 8bit input source, but this is just experimenting.

[Asmodian]

I assume your source is not really BT.2020? You need to convert the gamut to bt.2020 if you want the colors to be correct. The --colorprim and --colormatrix options set the information but do not covert. You are probably viewing BT.709 gamut video as if it was BT.2020 video so the colors are wrong.

I don't believe Avisynth's normal convert handles BT.2020 but Dither tools (http://forum.doom9.org/showthread.php?p=1386559#post1386559) does.

This should work:

Dither_convert_yuv_to_rgb(matrix="709")
Dither_convert_rgb_to_yuv(matrix="2020")

[surami]

The main source is a RGB24 AVI file made by the Advanced FrameServer (http://sourceforge.net/projects/advancedfs/) in After Effects.

In the AVS I have this:

AVISource("D:\rendering\signpost.avi", audio=false).AssumeFPS(25,1)

ConvertToYV12(matrix="Rec709")

Dither_convert_yuv_to_rgb(matrix="709")
Dither_convert_rgb_to_yuv(matrix="2020")

The situation is the same. On my PC with MPC-HC 1.7.9 it plays back with right colors, but on my TV not. So somewhere at the x265 file is the problem. I would like to generate files like we can find on the above mentioned site.

If I play those HDR files on my PC, the colors are wrong, they look like the mentioned problem with my x265 files on the TV, but if I play those files on TV, the colors are fine. :)

[Asmodian]

If you are already RGB all you need is:

AVISource("D:\rendering\signpost.avi", audio=false).AssumeFPS(25,1)

Dither_convert_rgb_to_yuv(matrix="2020")

Are you using madVR with MPC-HC? I believe madVR is required to respect gamut flags on the PC.

I wouldn't expect you to need any other flags set for your TV to understand BT.2020 but I am not sure.

[surami]

I'm using MPC-HC without madVR on my PC. In the morning I tried with madVR too, but there wasn't any difference.

I think there are some other flags that is necessary, because those HDR videos are runing fine on the USB port of the TV (Samsung UE40JU6000 (http://www.samsung.com/uk/consumer/tv-audio-video/televisions/uhd-tvs/UE40JU6000KXXU)).

[vivan]

When using madVR press Ctrl+J to display OSD - it will say what matrix it's using and why.

[surami]

I did that, the video from the hdrsample.com is using BT.2020, but MediaInfo shows this info too.

The playback with clean MPC-HC install or using madVR renderer doesn't make any difference in colors.

I forgot to mention, that I also run my hevc file through MP4Box with the following command:
mp4box -add "output.hevc" -brand hev1 "output.mp4"
pause

I uploaded my own experiment file here (https://drive.google.com/open?id=0B9p82xjTYmAxXzE3eS1YNkRfcUU), please test it.

Maybe the TV decoder gets extra info from somewhere or my encoding isn't valid for TV playback, I don't know.

[Jamaika]

I also make mistakes, but maybe something like this:
ffmpeg.exe (http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20151008-git-5911eeb-win64-static.7z) -s 3840x2160 -r 25.000 -i "import.mp4" -an -sn -f rawvideo -pix_fmt yuv420p10le - |
x264.10bpp.exe (http://komisar.gin.by/old/2597/x264.2597kMod.10bit.x86_64.exe) --demuxer raw --threads 4 --input-depth 10 --input-csp i420 --input-res 3840x2160 --output-csp i420 --keyint 25 --min-keyint 1 --bitrate 40000 --vbv-bufsize 120000 --vbv-maxrate 120000 --open-gop --fps 25.000
--preset veryslow --tune stillimage --range tv --colormatrix bt2020nc --colorprim bt2020 --transfer bt2020-10 - --output "output_x264.h264"

x265.10bpp.exe (https://encoder.pw/x265/default/x86_64/10-bit/x265_latest.zip) --input-depth 10 --input-csp i420 --input-res 3840x2160 --output-depth 10 --keyint 25 --min-keyint 1 --bitrate 40000 --vbv-bufsize 120000 --vbv-maxrate 120000 --open-gop --fps 25.000
--preset slow --range limited --colormatrix bt2020nc --colorprim bt2020 --transfer bt2020-10 - --output "output_x265.h265"

vpxenc.exe -v --threads=4 --bit-depth=10 --input-bit-depth=10 --i420 -w 3840 -h 2160 --kf-max-dist=25 --kf-min-dist=0 --target-bitrate=40000 --drop-frame=0 --fps=25000/1000
--good --profile=3 --codec=vp9 --passes=1 --pass=1 --cpu-used=3 --color-space=bt2020 --aq-mode=1 - -o "vp90_422p10le.webm"
MP4Box doesn't use to files 10bit!
ffmpeg.exe (http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20151008-git-5911eeb-win64-static.7z) -s 3840x2160 -r 25.000 -i "output_x264/x265.h264/h265" -i audio.aac -i subtitle.srt -f mp4 -c copy -movflags faststart -pix_fmt yuv420p10le "output.mp4"

[surami]

I found an interesting discussion about HDR (http://www.avsforum.com/forum/166-lcd-flat-panel-displays/1970346-official-2015-samsung-4k-suhd-js8500-series-tv-thread-140.html) from #4174, so I thought right, we need --master-display and --transfer commands too.

[CruNcher]

I see no strange colors or do you mean by that the Dynamic Range representation of the output result on the Target 10 bit ? Monitor itself ?

10->8bit
http://i2.sendpic.org/t/qE/qEUf1eniFX11PyhP2vkbZ0t1r0o.jpg (http://sendpic.org/view/2/i/wzQ1FiIgkimj8fBo6jaKH38Of6f.png)
http://i1.sendpic.org/t/7d/7diX0fCxcDMsLfWl2OuSgYTcMk1.jpg (http://sendpic.org/view/1/i/jzbnztU9OmgQ7ACXiPDHeJuDZlA.png)
http://i2.sendpic.org/t/8c/8cZrVpXcAXJ9Sao1ar1ALUZgKNP.jpg (http://sendpic.org/view/2/i/67T2wuV2fiAw175cmPStLPuWWlh.png)

[surami]

MP4Box doesn't use to files 10bit!
I'm just using that for writing right meta info, I think my command doesn't make any other changes.

I see no strange colors or do you mean by that the Dynamic Range representation of the output result on the Target 10 bit ? Monitor itself ?
On my PC it looks right, as the source, I see the same good looking video on my display as you. The TV playback isn't fine, it's weird flat yellowish, bluish. Try the movies by downloading the samples from here (http://hdrsamples.com/), you will see weird flat movie (the same movie looks fine on my TV) and read the above mentioned forum too, there are infos to understand things.

[CruNcher]

Interesting they gain some dynamics with Samsungs Magic Bright Cinema Preset

Very big difference though unusable for Desktop usage (kills the eyes)

http://www.samsung.com/sg/support/skp/htg/17189

biggest impact i see especially on the skin representation

Sharper ,Colder and more Contrast is how it looks

Wow i could further improve the output result these samples are perfect for tweaking

[Jamaika]

I'm just using that for writing right meta info, I think my command doesn't make any other changes.
The display color matrix isn't affected. I have a problem with scrolling.

[foxyshadis]

I'm just using that for writing right meta info, I think my command doesn't make any other changes.


On my PC it looks right, as the source, I see the same good looking video on my display as you. The TV playback isn't fine, it's weird flat yellowish, bluish. Try the movies by downloading the samples from here (http://hdrsamples.com/), you will see weird flat movie (the same movie looks fine on my TV) and read the above mentioned forum too, there are infos to understand things.

The TV has to understand BT.2020 as well, if it's going to play the files. Are you sure it does? Otherwise it's probably just interpreting it as BT.709.

[surami]

Well I think it understands BT.2020, because the downloadable HDR samples are playing fine on my TV.

Update: Ohh I'm starting to get something in my head? If the TV understands BT.2020 then it plays the video as HDR and if it doesn't understands it plays as BT.709 LDR or how is this?

I found info (http://www.parabolaresearch.com/blog/2015-09-03-parabola-4-hevc-hdr-analyzer.html) about the HDR video (http://demo-uhd3d.com/fiche.php?cat=uhd&id=113) provided by the FOX (https://www.linkedin.com/grp/post/3724292-6036912974852018176).

[surami]

My source is BT.709, so that's why the encoded BT.2020 flagged HEVC video gives strange colors on TV and it plays fine on PC?

[Asmodian]

My source is BT.709, so that's why the encoded BT.2020 flagged HEVC video gives strange colors on TV and it plays fine on PC?

If you used the conversion in AviSynth your source is no longer BT.709. That is why you need the conversion. :)

Dither_convert_rgb_to_yuv(matrix="2020")

There may be something else for HDR than simply using the BT.2020 matrix?

[Jamaika]

This is due to two variants standards High Dynamic Range UltraBluray. The above I described unknowingly SDR. The problem is that how many standards HDR. Is for any brand of TV is different SMPTE. Is this variant we use the function --range.
http://www.ip.philips.com/data/downloadables/1/9/7/9/philips_hdr_white_paper.pdf
For Panasonic, I see that it is recommended encoding of the HDR video the ST 2084 EOTF.

[benwaggoner]

If you used the conversion in AviSynth your source is no longer BT.709. That is why you need the conversion. :)

Dither_convert_rgb_to_yuv(matrix="2020")

There may be something else for HDR than simply using the BT.2020 matrix?
Correct. While TVs should be able to play 2020 content in some fashion, the size of the luma range and gamut are so huge that good tone mapping isn't technically practical, as possible luma and chroma values are so far out of what even the best consumer TVs today support.

The "HDR-10" format which is what everyone is using for actual HDR content on real displays uses the PQ Curve (SMPTE 2084) instead of gamma to map luma codes to actual brightness.

That uses --transfer 16 smpte-st-2084.

Gamma has been baked into our assumptions about video for, what 70 years now? So pretty much no tool has much of an idea for how to handle a polynominal mapping between Y' and actual display brightness. Processing needs to be done in linear light, and even tools like After Effects don't have the ability to export from their internal linear light space to PQ, and I'm told the existing icm/icc file format can't even describe the transform adequately.

Very few tools actually support converting to and from that color space today, and nothing that's FOSS I'm aware of. It's more like the colorists use a special display configured to provide that format, and then do a separate color grade based on that. It's not something that is done automatically; instead it as a re-grade from HDR source content, using various RAW-like formats that high-end digital cinema cameras can record.

Master-display and max-cll are optional metadata. You'd need to know what nominal display you are doing your conversion to HDR to know what those values are supposed to be, since real TVs don't support 100% of rec2020 (10K nits, huge color gamut). In practice most are targeting 1000 nits and the P3 color space used in digital cinema.

It's awesome that you're trying to do this, and I won't try to dissuade you by telling you any more about how incredibly hard it is to do in 2015.

I've done more HDR encoding than probably anyone else on the planet, and I wouldn't even know how to start in trying to personally convert and existing consumer HDR image or video to consumer HDR-10.

[CruNcher]

Interesting this old Samsung PLS Panel can actually drive this in the Samples not bad i never saw the Cinema Preset so expanding the quality on DVD content or stuff before then the impact it has on these Ateme 4K HDR Encoded Film Samples :)

I would say it's a decent Tone Mapping result also though i don't know the Pro Hardware result you use of course but Samsung Consumer stuff allways fascinates me here once again ;)

[surami]

If you used the conversion in AviSynth your source is no longer BT.709. That is why you need the conversion. :)

I see now, thanks. :)

Master-display and max-cll are optional metadata. You'd need to know what nominal display you are doing your conversion to HDR to know what those values are supposed to be, since real TVs don't support 100% of rec2020 (10K nits, huge color gamut). In practice most are targeting 1000 nits and the P3 color space used in digital cinema.

Thanks for the explanation Ben, I'm selfeducated, everything helps for me.

So if I'm working in AE in Rec.709 colorspace, my display can show me the same colorspace and the max cd/m2 is 300, then this RGB information (https://en.wikipedia.org/wiki/Rec._709#Primary_chromaticities) is needed right? And the command line should look like this: --master-display (http://x265.readthedocs.org/en/default/cli.html#cmdoption--master-display) "G(15000,30000)B(7500,3000)R(32000,16500)WP(15635,16450)L(3000000,1)"
(maths for green first value: 0.30/2*100000=15000)

What about this commands? --chromaloc, --max-cll, --min-luma, --max-luma, --temporal-layers

It seems, that playing BT.2020 video on my TV switched some settings automatically??, so that's why I saw those yellowish weird thing. I switched back the settings and now my experiment HEVC file runs fine and the colors are good now, but I will expand my script with some above mentioned additonal commands, I will report back soon.

[CruNcher]

Though as benwaggoner said it makes not much sense for a lot of content when it wasn't shot with the right equipment, also medical researchers warned from to much artificial blue wavelength light consumption and the blues get really pushed out here.

https://justgetflux.com/research.html

[surami]

My workflow looks like this till now:
1. Canon CR2 RAW frames
2. TIFF 16bit frames from Lighroom
3. ProRes 4:4:4 10bit MOV from ffmpeg prores_ks
4. grading in After Effects
5. AdvancedFrame Server RGB24 AVI from AE
6. Avisynth script dithering RGB to YUV BT.2020
7. x265 HEVC script
8. MP4Box script

The Canon CR2 RAW (Auto ETTR (http://www.magiclantern.fm/forum/index.php?topic=5693.0)) source should be good enough to test things, I don't own high-end camera, but my workflow isn't correct from nr. 5 and many other meta infos have to be added to the files as I read in this weekend to have correct HDR HEVC playback on the TV. I don't understand clearly yet, it's not simple and not usual workflow. :)

I read earlier, that every LED panel behind the seen picture is blue and it's not too healthy, maybe that's why Philips uses Ambilight and it's suggested to put a little lamp behind the TV for sparing the eyes and our brain, but please stay on topic.

I found Bill Mandel (https://www.linkedin.com/in/bmandel), he has many info about HDR.

It seems that the -transfer smpte-st-2084 has to do someting with the above mentioned extra meta infos (how to and what has to be generated? I have already a flat 10bit 4:2:0 YUV file converted from the 10bit 4:4:4 MOV), because it's also a switch for the UHD TV-s. I just encoded files with and without that and the contrast on my TV stayed the same, when I missed the command.

[Jamaika]

My workflow looks like this till now:
3. ProRes 4:4:4 10bit MOV from ffmpeg prores_ks

I wonder one thing. ProRes has colormatrix bt601 from ffmpeg. We're talking more about HDR cheated, since the scope of reduced number of colors.

BT.2020(10,000cd/m2) & BT.709(100cd/m2); Yxy (https://wikileaks.org/sony/docs/05/docs/HDR/HDR_Sony%E6%8F%90%E6%A1%88_140717_Body.pptx.pdf)
http://i58.tinypic.com/2dlp5y0.jpg

[surami]

I wonder one thing. ProRes has colormatrix bt601 from ffmpeg. We're talking more about HDR cheated, since the scope of reduced number of colors.

My MOV file in MPC-HC MediaInfo doesn't shows any info about colormatrix and it seems it's good so (http://ffmpeg.gusari.org/viewtopic.php?f=16&t=802). Yes, I saw that SONY presentation too.

[Jamaika]

Video
ID : 1
Format : ProRes
Format version : Version 0
Format profile : 422 HQ
Codec ID : apch
Display aspect ratio : 16:9
Color space : YUV
Chroma subsampling : 4:2:2
Matrix coefficients : BT.601
Video
ID : 1
Format : ProRes
Format version : Version 0
Format profile : 4444
Codec ID : ap4h
Display aspect ratio : 16:9
Chroma subsampling : 4:4:4
Matrix coefficients : BT.709

[surami]

If I see my Samsung TV specs, then there is a number called picture quailty index: 800, I think that is the maximum brightness value (PQ EOTF (https://www.smpte.org/sites/default/files/2014-05-06-EOTF-Miller-1-2-handout.pdf)) what it can show us.

So a 10bit video with the BT.2020 and SMPTE ST.2084 command should = 8bit color info + 2bit for meta stuffs (EOTF PQ infos?). This way the TV switches to the propely settings to watch HDR movie, that's why we see flat picture on PC with MPC-HC, it can't decode that meta info yet, so it shows us simple BT.2020 without any contrast, brightness, saturation settings. Later HDR-12 will be 10bit color info + 2bit extra meta. Is this right?

I hope somebody comes and explains this things.

[nevcairiel]

If I see my Samsung TV specs, then there is a number called picture quailty index: 800, I think that is the maximum brightness value (PQ EOTF (https://www.smpte.org/sites/default/files/2014-05-06-EOTF-Miller-1-2-handout.pdf)) what it can show us.

Thats an arbitrary number Samsung invented to rate their own TVs, its not the brightness.

[surami]

Thats an arbitrary number Samsung invented to rate their own TVs, its not the brightness.

I read that too, but it seems so it's equal with the LED panel's cd/m2 (nits) capabilities. Take a look at this:

http://www.display-central.com/wp-content/uploads/2014/05/Dolby_HDR_Test_Results_resize.jpg

As I read here (Dolby Vision White Paper (http://www.dolby.com/us/en/technologies/dolby-vision/dolby-vision-white-paper.pdf)) und if I understand well, the graded video stuff has to be analyzed and maped to get those extra meta infos, so I think it's too early to do something with Avisynth, ffmpeg, x265 etc...

[benwaggoner]

So if I'm working in AE in Rec.709 colorspace, my display can show me the same colorspace and the max cd/m2 is 300, then this RGB information (https://en.wikipedia.org/wiki/Rec._709#Primary_chromaticities) is needed right? And the command line should look like this: --master-display (http://x265.readthedocs.org/en/default/cli.html#cmdoption--master-display) "G(15000,30000)B(7500,3000)R(32000,16500)WP(15635,16450)L(3000000,1)"
(maths for green first value: 0.30/2*100000=15000)
Those are in units of nits, which is linear light. The problem is there's no way to get back to PQ instead of gamma from After Effects that I know of.

What about this commands? [FONT="Courier New"]--chromaloc, --max-cll, --min-luma, --max-luma, --temporal-layers
x265.readthedocs.org (http://x265.readthedocs.org) is your friend :). For HDR, chromaloc of 2 works well. Max-cll is actually the Max Content Light Level (nits of brightest single pixel in the title), and Max Frame Light Level (average nits of the brightest frame in the title). Both optional metadata. The other ones don't have anything in particular to do with HDR.

It seems, that playing BT.2020 video on my TV switched some settings automatically??, so that's why I saw those yellowish weird thing. I switched back the settings and now my experiment HEVC file runs fine and the colors are good now, but I will expand my script with some above mentioned additonal commands, I will report back soon.
Could be. The problem is that "true" 2020 isn't displayable by any extant TVs, and there are no standards for how a TV is supposed to display them. So YMMV massively between manufacturers, and even displays from the same manufacturer. Native 2020 is fun to play around with, but it won't be a practical delivery standard for years, if ever.

Also, note that 10-bit Rec. 2020 is just expanded color primaries, but no extra luma range (just good old gamma). Expanded luma range comes with the 12-bit version of Rec. 2020. Which nothing AFAIK can decode AND display.

[foxyshadis]

Also, note that 10-bit Rec. 2020 is just expanded color primaries, but no extra luma range (just good old gamma). Expanded luma range comes with the 12-bit version of Rec. 2020. Which nothing AFAIK can decode AND display.

I did NOT know that, thanks for mentioning it! Does that also hold between constant and non-constant?

I'd think you would be able to at least calibrate a screen as closely as possible to BT.2020, even if you can't get the primaries to actually hit it. Have any calibration tools come out yet?

[CruNcher]

I did the calibration so far per eye with the Ateme Samples i wonder if Samsungs Magic Bright could be partially converted into a PP Shader except the Brightness which isn't artificial :D

What was really interesting once you hit it and then playback normal compressed content you will see compression artifacts much faster (comparable to a luminance amplified input), but in those Ateme Samples you get much more Data out which results in clearer percepted images.

And on the sRGB Desktop it's gonna kill your eyes.

[huhn]

I did NOT know that, thanks for mentioning it! Does that also hold between constant and non-constant?

I'd think you would be able to at least calibrate a screen as closely as possible to BT.2020, even if you can't get the primaries to actually hit it. Have any calibration tools come out yet?

http://calman.spectracal.com/blog/category/all

calman 5.6 can calibrate dolby vision HDR.

argyllCMS can calibrated for BT 2020 without HDR.

[surami]

The display color matrix isn't affected. I have a problem with scrolling.

Use x265 with --no-open-gop, but with my MP4Box generated file I have problem with seeking too.

I'd think you would be able to at least calibrate a screen as closely as possible to BT.2020, even if you can't get the primaries to actually hit it. Have any calibration tools come out yet?

Yes to calibrate the screen is needed, I followed this (http://www.rtings.com/tv/reviews/by-brand/samsung/ju6500/settings?uxtv=8151466000c1) incase my TV set, but there is an option in picture menu, called native and my before mentioned custom settings looks very close.

x265.readthedocs.org is your friend. For HDR, chromaloc of 2 works well. Max-cll is actually the Max Content Light Level (nits of brightest single pixel in the title), and Max Frame Light Level (average nits of the brightest frame in the title). Both optional metadata. The other ones don't have anything in particular to do with HDR.

I set the max content light level to 800 (my TV's maximum nits value) and the avarage to 400, so --max-cll "800,400"

The problem is that "true" 2020 isn't displayable by any extant TVs, and there are no standards for how a TV is supposed to display them. So YMMV massively between manufacturers, and even displays from the same manufacturer. Native 2020 is fun to play around with, but it won't be a practical delivery standard for years, if ever.

Maybe there should be two video tracks, 1 for old TVs (BT.709) and 1 for newer TVs (BT.2020) and this later mentioned TV should get/know/decode the info from meta, that it have to play the BT.2020 track. Yes it's double the weight on the video track side, but this is a possible way or maybe dithering.

I uploaded a new experiment (ST.2084) (https://drive.google.com/open?id=0B9p82xjTYmAxRktTMjFYcUJiaWs), it's without audio track (TV says that unknown audio format) and seeking is problematic, but the colors, contrast, brightness are fine.

[sneaker_ger]

Use x265 with --no-open-gop, but with my MP4Box generated file I have problem with seeking too.
Try L-Smash muxer (https://www.dropbox.com/sh/7jjrz5i4wcxhf49/AADZlN98OhKAvLHVwfaXYK4da?dl=0) instead of mp4box.

[CruNcher]

The FOX Studio HDR Fire Sample leaked ;)

http://demo-uhd3d.com/fiche.php?cat=uhd&id=113

And another HDR Demo from Samsung :)

http://demo-uhd3d.com/fiche.php?cat=uhd&id=115

This also makes manual profile tuning easier being able to cross peak @ different results ;)

[kolak]

FOX is pushing for HDR. This content will be most likely graded in P3, as it's pointless to do BT.2020 due to non-existing displays.
FOX is doing some deal with Samsung and this content is meant to look good on Samsung latest displays.

File is flagged as BT.2020, but it will be graded to "only" around 85% of BT.2020 gamut as they use Sony 4K OLED reference monitor. When it comes to consumer displays this will be way out of correct colours/saturation as gamut of the best consumer displays is even below P3.

[CruNcher]

Oh great in the End we gonna have the same disaster as with High Quality Audio and High Quality Music :D

[foxyshadis]

FOX is pushing for HDR. This content will be most likely graded in P3, as it's pointless to do BT.2020 due to non-existing displays.
FOX is doing some deal with Samsung and this content is meant to look good on Samsung latest displays.

File is flagged as BT.2020, but it will be graded to "only" around 85% of BT.2020 gamut as they use Sony 4K OLED reference monitor. When it comes to consumer displays this will be way out of correct colours/saturation as gamut of the best consumer displays is even below P3.

As long as the player or TV converts to colors that can be displayed (probably with an enable/disable HDR option), that won't matter much. It certainly won't be worse than the situation now, since consumers basically never calibrate their monitors. When HDR is disabled, it would scale HDR content back to BT.709 via something like audio compression/limiting (or just saturate it). Then it's only a problem if the data isn't tagged, but that shouldn't happen.

[benwaggoner]

As long as the player or TV converts to colors that can be displayed (probably with an enable/disable HDR option), that won't matter much. It certainly won't be worse than the situation now, since consumers basically never calibrate their monitors. When HDR is disabled, it would scale HDR content back to BT.709 via something like audio compression/limiting (or just saturate it). Then it's only a problem if the data isn't tagged, but that shouldn't happen.


Downconverting from HDR to SDR automatically is at.least as hard as.going in the opposite direction. In practice, HDR content simply won't be sent to non-HDR displays.

[kolak]

As long as the player or TV converts to colors that can be displayed (probably with an enable/disable HDR option), that won't matter much. It certainly won't be worse than the situation now, since consumers basically never calibrate their monitors. When HDR is disabled, it would scale HDR content back to BT.709 via something like audio compression/limiting (or just saturate it). Then it's only a problem if the data isn't tagged, but that shouldn't happen.

If displays gamut is way smaller than BT.2020 than everything will be very unsaturated.

[Stacey Spears]

For HDR, chromaloc of 2 works well.

Only if you used that when downsampling to 4:2:0. Type 0 is the same as current MPEG Progressive 4:2:0 used on DVD, Blu-ray and streaming services. Type 1 is JPG and type 2 is new. Seems like something everyone will get wrong if you stream 4:2:0 to the display for UHD 60p. I would stick with type 0.

[surami]

I did an extreme curve comparison (something like I read here last year (http://cineform.blogspot.hu/2014/02/quicktime-16-bit.html)) on a frame with VirtualDub (64bit) (http://virtualdub.sourceforge.net/) + the gradation curves plugin (64bit) (http://www.hlinke.de/dokuwiki/doku.php?id=en:virtualdub_pluginlist).

Dithering bt2020 in Avisynth brings back some information as I see.

Comparison was done in AE (16bit project, sRGB colorspace):
1. tif 16bit -> advanced frameserver rgb24 avi (https://drive.google.com/open?id=0B9p82xjTYmAxTFF3cXh0c1piVWs)
2. prores 444 10bit intermediate file -> advanced frameserver rgb24 avi (https://drive.google.com/open?id=0B9p82xjTYmAxNnlTNzRoQmwxVFE)
3. prores 444 10bit intermediate file -> advanced frameserver rgb24 avi -> dithering bt2020 avs (https://drive.google.com/open?id=0B9p82xjTYmAxZjkxdTd4MVdaV1k)

What would be the best? Encode the tif 16bit frames into a better intermediate file to maintain the quality as much as we can till x265 encoding?

[kolak]

Not sure what exactly you have done. Your pipe should be 10bit+ up to dithering.

If you have 10bit+ source and dither it on uncompressed level than difference can be day and night compared to plain conversion to 8bit. This is irrelevant to BT.2020. With wider gamut sources difference should be even bigger.

[surami]

Not sure what exactly you have done. Your pipe should be 10bit+ up to dithering.

If you have 10bit+ source and dither it on uncompressed level than difference can be day and night compared to plain conversion to 8bit. This is irrelevant to BT.2020. With wider gamut sources difference should be even bigger.

I just tried to compare my source tif 16bit frame with the prores 444 10bit frame (through that advanced frameserver thing) and with the bt2020 dithered stuff in avisynth, that what happens with colors.

I found an interesting site, according to different dithering technics (https://www.nmm-hd.org/newbbs/viewtopic.php?f=5&t=707&sid=2f431c586086bfa177d9c8633b1f2c34) (see the chart at the end) and there is a smpte group report about HDR (https://www.smpte.org/sites/default/files/Study%20Group%20On%20High-Dynamic-Range-HDR-Ecosystem.pdf).

[CruNcher]

FOX is pushing for HDR. This content will be most likely graded in P3, as it's pointless to do BT.2020 due to non-existing displays.
FOX is doing some deal with Samsung and this content is meant to look good on Samsung latest displays.

File is flagged as BT.2020, but it will be graded to "only" around 85% of BT.2020 gamut as they use Sony 4K OLED reference monitor. When it comes to consumer displays this will be way out of correct colours/saturation as gamut of the best consumer displays is even below P3.

It seems 20th Century Fox is in close collaboration with Samsungs R&D Sait institute with HDR content Quality

So Samsung is collaborating with Ateme and 20th Century Fox here, not bad ;)

The SUHD re-mastering engine automatically analyzes the brightness of images to minimize additional power consumption while expressing ultimate contrast levels, producing images with much darker blacks and an elevated brightness up to 2.5 times brighter than conventional TVs. and twice the color adjustment points for the most accurate color display.

By collaborating with the leading Hollywood studio 20th Century Fox, Samsung has been able to optimize content to meet premium quality SUHD standards. This allows for consumers to have an unrivaled UHD viewing experience.
Most recently, Samsung partnered with the Fox Innovation Lab to re-master multiple scenes from its critically acclaimed film, Exodus by Ridley Scott, specifically for the SUHD TV. The result was spectacular - generating more vivid colors and lifelike scenes.

Furthermore, Samsung’s SUHD TVs use environmentally friendly technology to deliver best-in-class energy efficiency and reliability.

So all the Content we actually see encoded with Atemes 10 Bit Encoder is especially optimized for their Display Results might be that why my Samsung PLS Monitor with their PP Engine creates such nice output results for the Exodus Sample ;)


The SUHD re-mastering engine automatically analyzes the brightness of images to minimize additional power consumption while expressing ultimate contrast levels.

They call this Optimal Contrast in their PP Engine on their Monitors, it works quiet nice and adapts relatively quickly

Does somebody know more about Samsungs Super Resolution algorithm they use in these SUHD TV Lineup and compared to Sonys Content Upscaling Results ?

http://i2.sendpic.org/t/56/56ESwJOnWZnCdOTkHRaWuymSZLV.jpg (http://sendpic.org/view/2/i/zMFoenLCuvkRjqxdxPrSVcH30l1.png)

[benwaggoner]

So all the Content we actually see encoded with Atemes 10 Bit Encoder is especially optimized for their Display Results might be that why my Samsung PLS Monitor with their PP Engine creates such nice output results for the Exodus Sample ;)
Hardly "all the Content" :). There's 50+ episodes and several movies in HDR available on Amazon Video today, for Samsung, Sony, and LG TVs.

[kolak]

It seems 20th Century Fox is in close collaboration with Samsungs R&D Sait institute with HDR content Quality

So Samsung is collaborating with Ateme and 20th Century Fox here, not bad ;)



So all the Content we actually see encoded with Atemes 10 Bit Encoder is especially optimized for their Display Results might be that why my Samsung PLS Monitor with their PP Engine creates such nice output results for the Exodus Sample ;)



They call this Optimal Contrast in their PP Engine on their Monitors, it works quiet nice and adapts relatively quickly

Does somebody know more about Samsungs Super Resolution algorithm they use in these SUHD TV Lineup and compared to Sonys Content Upscaling Results ?

http://i2.sendpic.org/t/56/56ESwJOnWZnCdOTkHRaWuymSZLV.jpg (http://sendpic.org/view/2/i/zMFoenLCuvkRjqxdxPrSVcH30l1.png)

Just to add- Technicolor is also part of this "collaboration".

[surami]

There is a new Sony 4K HDR BT.2020 10bit 59.940fps demo (http://demo-uhd3d.com/fiche.php?cat=uhd&id=144) to watch, "Camp" (nature).

[benwaggoner]

If displays gamut is way smaller than BT.2020 than everything will be very unsaturated.
Assuming that the TV doesn't do any tone mapping to display capabilities. I expect that the results from a >P3 gamut 2020 stream will vary a lot between models and manufacturers.

"Native" 2020 support isn't a big priority for any manufactuers, and there aren't any displays that can do a full 2020 display. Native 10-bit 2020 has no HDR for luma and more colors than are practical to display. That's why HDR-10 emerged, which allows for HDR in 10-bit, includes some basic metadata for luma range, and has an implicit assumption that only the P3 subset of 2020 chroma will be used.

Rec. 2020 12-bit does support HDR for luma, but we don't have 12-bit decoders or pipeline support in most HDR capable devices. And if we had 12-bit, I don't see any clear advantages for why the Rec. 2020 luma curve would be better than just using the PQ curve in 12-bit. An HDR-12 with support for up to 10K nits and full 2020 primaries would be a pretty trivial extension from what's being done today.

I doubt we'll see substantial real-world use cases for Rec. 2020 before 2020 :).