I Have Published a HDR10 to HLG Converter

[frank]

Then -l = 203/48 = 4.23 equals -r 48
right?
Thanks, I'll test again.

[wswartzendruber]

Yes. --ref-white and --lum-scale are mutually exclusive and end up setting the same internal value.

-r 48 and -l 4.23 are principally the same.

[frank]

Great, William, that's it, it worked with -r 48! :thanks:
Now the movie looks fine.
And that morons still sell the messed up uhd for 30 Eur. :devil:

[frank]

I'm using mpv on my notebook (500nit FHD+ display) to watch the conversion. It has excellent tone mapping but you have to set it yourself for best colors.
For portable using create the folder mpv/portable_config/ and copy the files:input.conf, mpv.conf
Edit mpv.conf:vo=gpu-next
hwdec=auto-safe
tone-mapping=bt.2390
hdr-compute-peak=no You'll get excellent HLG/HDR tone mapping. No brightness flickering at start-stop.
For more settings see the manual in /mpv/doc/.
vlc is also good but doesn't have that many options.
___________________
Dell XPS 15 9510, Win10 Pro

[FranceBB]

Alita: Battle Angel is the worst I've run into simply because it's a direct cinema XYZ transfer to PQ with botched metadata.

Wait a sec...130 for MaxCLL? This movie is also a naïve XYZ transfer.

Yep. Looks like is more common than it seems


And that morons still sell the messed up uhd for 30 Eur. :devil:

The thing is that there's nothing wrong in using the DCP transfer to create the UHD-BD version, but metadata MUST be right and that's unfortunately something they got wrong... :(


vlc is also good but doesn't have that many options.

Yeah, I use MPV as well, it's the best.
The only time I use VLC is when my poor computer struggles with decoding and I'm willing to accept a quality reduction as long as I can still watch it in real time...
But yeah, if I had infinite computational power, I would totally use MPV for everything.

[wswartzendruber]

I have begun to experiment with using skin tones to set reference white. I'm going to throw a few Zack Snyder movies at this technique to see how robust it really is.

[frank]

Next example of wrong UHD mastering.

Top Gun: Maverick UHD 2022
max-cll 617,496
Release is too dark. Again they mismatched the white level.
I found that -r 100 for HLG is comparable to the BD bt709.

So it is created for DCP 100 nits, EOTF PQ, P3.
What do you think?

[wswartzendruber]

I don't have Maverick yet, but if they put reference white at 100 nits, that is actually correct. Well, depending on your point of view.

HDR10 is static metadata around either ST.2084 or ST.2086. And it's one of those that says reference white should be at 100 nits in a reference environment.

Well, the ITU came in later and did their own tests and determined that reference white should be at 200 nits in a reference environment. So their BT.2408 paper says to put it at 203 nits, as this corresponds to 75% HLG, which is where reference white is at that format.

[frank]

OK.
My "reference environment" is the living room and tv, not a dark basement. I think 90% of viewers don't sit in the dark to watch a movie on tv. UHD publishers don't get it.
That's why I convert to HLG.
And 200nits look better on my notebook too.

[wswartzendruber]

I think 90% of viewers don't sit in the dark to watch a movie on tv. UHD publishers don't get it.
This is half the reason HLG was created to begin with.

[FranceBB]

Well, I sent you a present, William. ;)
It's my Christmas gift. :)

https://cdns-images.dzcdn.net/images/cover/f852c18fcb3f41987b0de1f905b38ade/264x264.jpg

[Balling]

OK.
My "reference environment" is the living room and tv, not a dark basement. I think 90% of viewers don't sit in the dark to watch a movie on tv. UHD publishers don't get it.
That's why I convert to HLG.
And 200nits look better on my notebook too.

I do. Many people do, cause why BT.709 was for a dark room, end to end gamma 1.2.

While sRGB was for office environement.

[kolak]

OK.
My "reference environment" is the living room and tv, not a dark basement. I think 90% of viewers don't sit in the dark to watch a movie on tv. UHD publishers don't get it.

Maybe Dolby did:
https://professionalsupport.dolby.com/s/article/Dolby-Vision-IQ-Content-Type-Metadata-L11?language=en_US

I wonder how well it works in real life.
Actually system may be bit limited in functionality atm.

[Balling]

Maybe Dolby did:
https://professionalsupport.dolby.com/s/article/Dolby-Vision-IQ-Content-Type-Metadata-L11?language=en_US

I wonder how well it works in real life.
Actually system may be bit limited in functionality atm.

And BTW, it is not dark basement. That would require 2.6 gamma for SDR. It is just dark room with 5 nits of D65 lamps. So 5 candles not in front of the TV.

Dolby IQ works great, just as D93 light color managment. The patent on Dolby IQ is solid. Just like for TrueTone though.

See IQ patent. It is fuxxing nuts. https://patents.google.com/patent/WO2018119161A1/en

[wswartzendruber]

Jack Daniel's thoughts follow:

The HLG EOTF doesn't scale the display outlet linearly. As it increases brightness, the gamma value changes. If the HLG EOTF is doing this, then I should have pq2hlg do this when --lum-scale is applied.

I need to do the math (I suck at math) abstract the HLG parts out of a working model.

[wswartzendruber]

The Lord of the Rings appears to have reference white at 100 nits. This is with linear brightness scaling.

The Argonath (https://www.youtube.com/watch?v=1Yn12ELtE5Q)
Isildur's Account (https://www.youtube.com/watch?v=nUGePo_boeU)
A Wizard Is Never Late... (https://www.youtube.com/watch?v=6o7zCsl1rys)

[Balling]

Ambient environment SEI is now apparently used by iPhone, so they can reproduce D65 or D93 illuminants, or ony color as white point. Nice. https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230111185707.22132-4-jeebjp@gmail.com/


Applied!! https://github.com/FFmpeg/FFmpeg/commit/5de565107a32414aec9f079940c76812265157c5

ffprobe -select_streams v:0 -show_frames -i "iPhone11_4K-recorder_59.940DV+HLG.mov"

side_data_type=Ambient viewing environment
ambient_illuminance=3140000/10000
ambient_light_x=15635/50000
ambient_light_y=16450/50000


side_data_type=Dolby Vision RPU Data

[SIDE_DATA]
side_data_type=Dolby Vision Metadata
rpu_type=2
rpu_format=18
vdr_rpu_profile=1
vdr_rpu_level=0
chroma_resampling_explicit_filter_flag=0
coef_data_type=0
coef_log2_denom=23
vdr_rpu_normalized_idc=1
bl_video_full_range_flag=0
bl_bit_depth=10
el_bit_depth=10
vdr_bit_depth=12
spatial_resampling_filter_flag=0
el_spatial_resampling_filter_flag=0
disable_residual_flag=1
vdr_rpu_id=0
mapping_color_space=0
mapping_chroma_format_idc=0
nlq_method_idc=-1
nlq_method_idc_name=none
num_x_partitions=1
num_y_partitions=1

pivots=63 132 362 618 874 911 927 935 942

mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=-409680 16721463 -20276640


mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=-119056 13575212 -12867889


mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=1317527 5338528 -948122


mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=2119979 2065496 2288524


mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=7982780 -11367226 9973944


mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=53792084 -114243184 67724328


mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=112973872 -244837568 139764480


mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=236828416 -518849056 291306944



pivots=0 1023

mapping_idc=1
mapping_idc_name=mmr
mmr_order=3
mmr_constant=-4200453
mmr_coef=9094176 31944476 739652 -27103344 -3431599 -11015088 22758042 -2028643 -30021218 -906885 26272992 7291404 16488745 -78087176 -1487777 12496543 762460 -4281948 -5768035 -7843163 103636960

[kolak]

Some document which may have useful info:

https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-7-2019-PDF-E.pdf

[wswartzendruber]

It looks like we only need to mess with gamma when increasing brightness due to the ambient environment providing distractions?

[kolak]

No idea. I just shared doc thinking it may be useful.

[Balling]

Is Ultraviolet/infrared light as ambient white allowed? Interesting.

[Balling]

It looks like we only need to mess with gamma when increasing brightness due to the ambient environment providing distractions?

It is not only gamma, it is primaries too. Anyway. E.g., imagine you have Ledvance, former OSRAM, halogen lamps. Twelve of 12 V 300 lumen, so 12 V can be direct current too, so no pulses from alternating current. On the newer 2021 generation there is QR code into EU database EPREL (European Product Registry for Energy Labelling), this is mine https://eprel.ec.europa.eu/screen/product/lightsources/714468?navigatingfrom=qr

As you can see it has Correlated colour temperature 2 800K and Chromaticity coordinate
x: 0,452 y: 0,409, that is far from D65 6504 K x: 0.31271 and y: 0.32902. Lol.

[wswartzendruber]

Version 1.1.0 is out.

Included in this release are:

1. The new hlg2pq utility, which allows for conversion to PQ at arbitrary display levels up to 10,000 nits.

2. Adding --hlg-compensate (-c) to pq2hlg, which addresses excessive saturation in a single channel by diverting to the other two channels.

3. The pqprev.sh / pqprev.ps1 script, which will grayscale a PQ frame and output it as an sRGB image without adjustment.

https://github.com/wswartzendruber/hlg-tools/releases/tag/release%2F1.1.0

[wswartzendruber]

I'm starting to learn about how to run a YouTube channel. I've started a playlist that features various commercial HDR10 demos converted into HLG.

https://www.youtube.com/playlist?list=PLkO9wxRVnt-Q6XnwaAeHKMsJiYkzYRm1e

[wswartzendruber]

I've been doing reading on how to best increase image exposure. Because when we're adjusting reference white, that's really what we're doing. I've posted two test clips onto YouTube. The first increases exposure by multiplying the linear RGB values by a factor. The second increases exposure by converting to Oklab and multiplying those components by a factor.

RGB: https://youtu.be/XMdFweclflY
Oklab: https://youtu.be/9hqkMBvwqSc

I'm interested in what others think of the results, as there doesn't seem to be an objectively correct way of doing this.

EDIT: Here are some screenshot comparisons for BT.709 playback via YouTube:

https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-1.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-2.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-3.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-4.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-5.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-6.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-7.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-8.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-9.jpg

[wswartzendruber]

Here's 2.0.0-beta1. (https://github.com/wswartzendruber/hlg-tools/releases/tag/release%2F2.0.0-beta1)

All brightness scaling is now based on Oklab (https://bottosson.github.io/posts/oklab/). In other words, for all the pictures in the preceding post, 1.x (linear RGB scaling) is shown on the left while 2.0.0-beta1 (Oklab scaling) is shown on the right.

To this end, the --lum-scale (-l) flags are gone and replaced with --exposure (-e).

[wswartzendruber]

Here's 2.0.0-beta2. (https://github.com/wswartzendruber/hlg-tools/releases/tag/release%2F2.0.0-beta2)

This features newly-derived RGB<->XYZ matrices using the constants defined in BT.2020 as a starting point at 64-bit float precision.

These new matrices allow for a RGB<->Oklab roundtrip with accuracy to 0.0000000001 nits across all brightness levels.

[ErazorTT]

I'm interested in what others think of the results, as there doesn't seem to be an objectively correct way of doing this.


Don't you have the SDR BluRay to compare against? There you should be able to see how deep the blacks are.

The point is, that of course the one with deeper black seems to look better, subjectively. However, I would be afraid that this might drown all blacks to black.

[kolak]

SDR will be most likely grading trim from HDR, so it's creative step (not some fixed math). It's not that easy to say which one is correct as there is no such a thing like "one correct SDR version". Typically official directors grade is reference and in case of HDR/SDR one can be sometimes quite different than other.

[wswartzendruber]

The objective with incorporating Oklab is to say: "The HDR10 grading represents some artistic intent. That intent should be preserved as the exposure is adjusted to increase reference white."

RGB is not perceptually uniform.

[ErazorTT]

The objective with incorporating Oklab is to say: "The HDR10 grading represents some artistic intent. That intent should be preserved as the exposure is adjusted to increase reference white."

RGB is not perceptually uniform.

Yes, but you're increasing the brightness for the reason to match the total brightness of the HLG stream to that of the SDR stream.

So I think it would be best if you compared these with the SDR stream to see which of these better match the blacks.
RGB: https://youtu.be/XMdFweclflY
Oklab: https://youtu.be/9hqkMBvwqSc

[ErazorTT]

I tested the v2.0.0.b2 against the v1.1.0, and I am seeing exactly no differences, apart from rounding to +/-1 at 10 bits. And I scrolled through the whole movie. What am I missing?
Here is my script:

LoadPlugin("C:\...\dgindexnv\DGDecodeNV.dll")
pq=DGSource("C:\...\pq.dgi")

pq=pq.z_ConvertFormat(chromaloc_op="top_left=>center",width=pq.Width()/2,height=pq.Height()/2,pixel_type="RGBP16",colorspace_op="2020ncl:st2084:2020:limited=>rgb:st2084:2020:full",dither_type="none",resample_filter="spline36",resample_filter_uv="spline36")
hlg1=pq.Cube("C:\...\1.1.0\lut_2.75_1000.cube")
hlg1=hlg1.z_ConvertFormat(chromaloc_op="center=>top_left",pixel_type="YUV420P16",colorspace_op="rgb:std-b67:2020:full=>2020ncl:std-b67:2020:limited",dither_type="none",resample_filter="spline36",resample_filter_uv="spline36")
hlg2=pq.Cube("C:\...\2.0.0.b2\lut_1.4_1000.cube")
hlg2=hlg2.z_ConvertFormat(chromaloc_op="center=>top_left",pixel_type="YUV420P16",colorspace_op="rgb:std-b67:2020:full=>2020ncl:std-b67:2020:limited",dither_type="none",resample_filter="spline36",resample_filter_uv="spline36")

StackVertical(hlg1,hlg2,Subtract(hlg1,hlg2))
ConvertBits(10,dither=0)

The v1.1.0 lut was created with that command:
./pq2hlg.exe lut_2.75_1000.cube --max-cll 1000 --lum-scale 2.75 --size 65 -c

The v2.0.0.b2 lut was created with that command:
./pq2hlg.exe lut_1.4_1000.cube --max-cll 1000 --exposure 1.4 --size 65

I came to the lum-scale and exposure by comparision to my SDR source.
Please create lut files using the parameters above with 1.1.0 and compare them yourself against 2.0.0.b2.

[wswartzendruber]

Here's a screenshot comparison. The bottom two are done with 2.0.0-beta2.

https://wswartzendruber.net/images/alita-comparison-1.png

https://wswartzendruber.net/images/alita-comparison-2.png

https://wswartzendruber.net/images/alita-comparison-3.png

https://wswartzendruber.net/images/alita-comparison-4.png

https://wswartzendruber.net/images/alita-comparison-5.png

Regarding LUT comparison between 1.1.0 and 2.0.0-beta2, if your source was monochrome, there might not be a difference at all. If Oklab is to be believed, scaling linear brightness by a fixed factor is perceptually uniform, so long as no color (non-D65) is involved. This, at least, is what I found when I experimented with it.

But when color is involved, things change. Here's line 168,269 from each one:

1 1 0.9537389

1 1 0.94303465

Or line 39,788:

0.008232022 0.66472024 0.10244914

0.01649015 0.6643379 0.102354646

[ErazorTT]

if your source was monochrome, there might not be a difference at all.

Crap, yeah it was monochrome, because I was interested in the brightness side of things. Ok so I will retry with color.

[wswartzendruber]

Awesome, that probably explains things, then.

Remember that if no reference white adjustment is needed, both versions should generate identical LUTs.

[wswartzendruber]

Here's 2.0.0-beta3. (https://github.com/wswartzendruber/hlg-tools/releases/tag/release%2F2.0.0-beta3)

This corrects SDR black and white previews. Those were using BT.2020 coefficients earlier in beta2.

EDIT: That is, taking a black and white preview shot of a BT.709 Blu-ray now uses the BT.709 conversion matrix to go to Oklab for better brightness assessment.

[wswartzendruber]

In today's segment of Useless Trivia™, The Fifth Element declares a MaxCLL of 10,000 nits. These levels can be seen on the tiny lights highlighting the aliens's armor at the beginning of the movie.

[FranceBB]

In today's segment of Useless Trivia™, The Fifth Element declares a MaxCLL of 10,000 nits. These levels can be seen on the tiny lights highlighting the aliens's armor at the beginning of the movie.

LOL making something no one can see, including the ones who actually created it, cool xD
I guess this is their way of saying that their Pogo Stick is bigger than everyone else's... but it's not.

(it's a Modern Family reference, go look it up if you didn't get it).

[wswartzendruber]

I used Oklab to push the peak brightness down from 10,000 nits to 100 nits, but otherwise did no tone mapping:

https://wswartzendruber.net/images/excessive-maxcll.png

[ErazorTT]

Another question converning v2. How come that the -c parameter is not needed anymore? Is this due to the oklab processing?

[wswartzendruber]

Another question converning v2. How come that the -c parameter is not needed anymore? Is this due to the oklab processing?
No. It's that I decided it was dumb.

-c was in 1.x because HLG has limits on how much value a single color channel can have when the other two channels aren't present. Ergo, the maximum value a single color channel can have increases as the other two channels accompany it. The only time R, G, and B can be at their max is when all three are at their max.

-c worked by saying, "I've got a red channel by its self calling for 262 nits, but I can only take this to 201 nits with HLG. I'm going to divert some of the overall signal strength from this red channel to the other two. Saturation will be lost but overall brightness will be preserved."

Except that not even that is true, because linear RGB is a terrible predictor for perceptual brightness.

Note that HLG allows isolated channels to go high enough that this shouldn't even be something anyone runs into.

EDIT: This is discussed in BT.2408-4 page 25, in section 6.5

[ErazorTT]

Ok I see. Since you mention BT.2408-4, please be also aware that the current release is now already at BT.2408-7.

https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-7-2023-PDF-E.pdf

[wswartzendruber]

Ok I see. Since you mention BT.2408-4, please be also aware that the current release is now already at BT.2408-7.

https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-7-2023-PDF-E.pdf
Oh for crying out loud. I wanted to release 2.0.0 on New Year's Day.

But I should examine this first.

EDIT: Okay so they have made an attempt to address the issue of linear RGB scaling. They're clarifying how two separate adjustments can be made, one to RGB and then the other to Y. And they're attempting to get more perceptually accurate color modeling using data from BBC and ARIB surveys. Converting from RGB to Oklab, scaling, and then converting back to RGB is going to be more expensive, but the LUT only needs to be generated once. And whereas BT.2408-7 only covers scaling from SDR to HDR, Oklab can (theoretically) scale to and from any brightness. Oklab has been modeled using an extensive data set from color perception surveys.

So I'm currently planning to leave Oklab in place for 2.0.0. I would need someone to tell me that Oklab scaling looks bad on a high-end grading monitor (which I don't have).

I need to just shell out the money on an Asus ProArt monitor.

[ErazorTT]

I would need someone to tell me that Oklab scaling looks bad on a high-end grading monitor (which I don't have).


Anything specific to look out for? What would be the critical places in the LUT? I have a LG EP950, which has 33 point 3D hardware calibration and has the same JOLED display as the OLED ProArt.

[wswartzendruber]

Anything specific to look out for? What would be the critical places in the LUT? I have a LG EP950, which has 33 point 3D hardware calibration and has the same JOLED display as the OLED ProArt.
Find something that needs a lot of correction (stress test). Some of the 20th Century Fox stuff is graded really dark placing reference white at 48 nits. Alita is one such movie. If you find a movie like that, try this command with both 1.x and 2.0.0-beta3:

pq2hlg -m 162 -r 48 -s 128 pq2hlg.cube

The 2.x LUT should look a lot more like an exposed representation of the original than the 1.x. You may specifically find that hue changes with 1.x and the midtones might be overexposed.

Basically, 2.x should just look like a brighter take on the original while 1.x looks off.

[ErazorTT]

I really don't understand why you see differences between the new and the old LUTs. I don't see any.

Please take a look at the script here. It generates a calibration pattern, then transforms it using the old and the new LUT, and then compares the outputs. There arn't any differences. Looking at the calibration pattern, I would have thought that there should be differences.

Thats the script:
https://drive.google.com/file/d/1dSvGPK02ybH2rurAov7Bpt9tM_B1rGfT/view?usp=drive_link

Thats the calibration pattern the script generates which then gets transfomed by the LUTs:
https://i.postimg.cc/DJtCdJ7h/Color-Brightness-Steps-All000089.png (https://postimg.cc/DJtCdJ7h)

To use the scirpt you need to generate the LUT files and adapt the paths to the LUT files at the very bottom of the script.

[wswartzendruber]

Sweet Fancy Moses. You're right. I have no idea how or why, but 1.1.0 and 2.0.0-beta3 produce visually identical results despite the large differences seen in the previous page.

I'm investigating...

EDIT: So far, scaling linear RGB by a factor, and scaling Oklab by a much smaller factor.............produce the same results. This shouldn't be the case at all. Not even close... This also doesn't explain the differences on the previous page.

EDIT: Increasing image exposure via linear RGB appears to be "correct" for now anyway. Oklab does return different brightness levels when monochroming an image (like in preview mode).

EDIT: Okay, so...

1. Linear RGB may not be perceptually uniform, but it still suffices for increasing image exposure.
2. 2.0.0 should simply revert to using linear RGB for exposure (reference white) adjustments.
3. Oklab still has a place in black-and-white preview mode (which can be used to determine exposure).
4. YouTube has likely changed the way BT.709 is generated from HLG uploads, explaining the differences on the preview page (uploaded a year apart).
5. Be more thorough in monitoring differences (this has bitten me in the ass before).

EDIT: I grabbed a HDR Windows machine and screenshot the two YouTube clips with HLG playback. They appear to have identical levels.

[wswartzendruber]

Titanic (which just came out on 4K) declares a MaxCLL of 283 nits.

[FranceBB]

Well, that's in line with other UHD re-scanned movies like Goodfellas which declares 247 Nits.
To think that it was only a few years ago, in 2016, when I've got the Apple ProRes FULL HD re-scan and encoded an XDCAM-85 out of it (back when the "XDCAM SHD - aka Super HD" slogan was still a thing 'cause Sony didn't know how to cope with newer and better 10bit standards so they just reckoned they could push more bitrate into a dying MPEG-2 8bit standard to go from 50 Mbit/s (XDCAM-50) to 85 Mbit/s (XDCAM-85) totally missing the point about the issues MPEG-2 had and its problems with banding etc.
Anyway, I remember that day as if it was today, it was a weekend, Sunday morning, in 2016, I was at work and given that the last time I watched Titanic was back when DVD were a thing, I re-watched the entire movie in XDCAM-85.
I went into one of the QC rooms at Sky, the QC Room 3, at the third floor, 'cause we had one and only one Harmonic Omneon playback port capable of playing XDCAM-85 files (all the other VS7 ports were only capable of up to XDCAM-50) and watched it.
Aside from a few places in which the film was clearly ruined, the overall picture was rather sharp but it had plenty of grain.
Back then I thought "this is amazing" 'cause I could see way more details than the ones I remembered on the DVD, although there were a few scenes with water that presented banding anyway (despite all the grain) and I clearly thought "why is the world sticking with MPEG-2 8bit? why?!".

Well, fast forward to 2023, 7 years later, and we have the 4K Remaster where they probably re-scanned the old film once again.
At this point I'm curious to see that one as well and see whether there are effectively more details compared to the FULL HD scan or if it's just more grain like in Goodfellas.
If I get my hands on it, I'll be back with a few screenshots.
The only thing I don't understand about those Remasters, though, is the fake PQ 'cause no matter how much you play around with it, the source will always be SDR (and in some case, even worse than 100 nits SDR, depending on the condition of the film). I mean, sure, you can bring some highlights up, mask some reflections and treat them differently etc but why?

[wswartzendruber]

Well, that's in line with other UHD re-scanned movies like Goodfellas which declares 247 Nits.
To think that it was only a few years ago, in 2016, when I've got the Apple ProRes FULL HD re-scan and encoded an XDCAM-85 out of it (back when the "XDCAM SHD - aka Super HD" slogan was still a thing 'cause Sony didn't know how to cope with newer and better 10bit standards so they just reckoned they could push more bitrate into a dying MPEG-2 8bit standard to go from 50 Mbit/s (XDCAM-50) to 85 Mbit/s (XDCAM-85) totally missing the point about the issues MPEG-2 had and its problems with banding etc.
Anyway, I remember that day as if it was today, it was a weekend, Sunday morning, in 2016, I was at work and given that the last time I watched Titanic was back when DVD were a thing, I re-watched the entire movie in XDCAM-85.
I went into one of the QC rooms at Sky, the QC Room 3, at the third floor, 'cause we had one and only one Harmonic Omneon playback port capable of playing XDCAM-85 files (all the other VS7 ports were only capable of up to XDCAM-50) and watched it.
Aside from a few places in which the film was clearly ruined, the overall picture was rather sharp but it had plenty of grain.
Back then I thought "this is amazing" 'cause I could see way more details than the ones I remembered on the DVD, although there were a few scenes with water that presented banding anyway (despite all the grain) and I clearly thought "why is the world sticking with MPEG-2 8bit? why?!".

Well, fast forward to 2023, 7 years later, and we have the 4K Remaster where they probably re-scanned the old film once again.
At this point I'm curious to see that one as well and see whether there are effectively more details compared to the FULL HD scan or if it's just more grain like in Goodfellas.
If I get my hands on it, I'll be back with a few screenshots.
The only thing I don't understand about those Remasters, though, is the fake PQ 'cause no matter how much you play around with it, the source will always be SDR (and in some case, even worse than 100 nits SDR, depending on the condition of the film). I mean, sure, you can bring some highlights up, mask some reflections and treat them differently etc but why?
I've got one clip up so far:

Titanic: Rose Arrives in Southampton [HDR-HLG] (https://www.youtube.com/watch?v=p18Zi9IumPQ)

EDIT: If you want something up in the original PQ, I can do that too so long as it's kept under two minutes.

EDIT: Titanic: Ending [HDR-HLG] (https://www.youtube.com/watch?v=8gnF5_xJf0E)