Current options for affordable HDR monitoring

I searched the forums and there are a few other threads (HDR Metadata Linux Blackmagic, Aja t tap pro, OLED monitor for Flame - #6 by naveen), but none a conclusive.

A common config for Flame is a Rocky Linux system with BMD DeckLink and NVidia GPU. Should be ideal for an occasional HDR job. With HDR reference display still very expensive and only for those that finish HDR all the time, many however have access to a variety of good but not completely reference grade HDR monitors (Asus, Dell, etc.). Many of them are HDMI based. These setups work quite well on Resolve or Mistika among others.

Two problems arise - one is to get HDR meta data to the monitor, the other is convincing Flame to output HDR signals.

It’s well documented that on Flame HDMI tunneling is only supported on AJA. And that presumably is Kona cards. I seem to recall that AJA IO4K+ (which I happen have) is not supported period. And there was no answer to the T-Tap Pro in the other thread.

Which begs the question, is there a viable path of getting an HDR signal out via DeckLink SDI, as one presumably would use with a SDI based HDR reference display? If so, could that SDI signal then converted to HDMI with one of many available converters, and then also inject the meta data through an external box, which also exist?

And presumably you can’t have two broadcast monitors to have an FSI SDR and am HDR monitor at the same time?

Am I overlooking something?

In my case I have an HDR capable Dell 31" UltraSharp that I’d like to setup. It has all the menus for HDR, but doesn’t pick up any HDR signal from Flame, only my other systems.

Thanks,
Jan

Ah yea ive been down this rabbit hole, best is if you can just switch the display to PQ, then you dont need to worry about metadata…

I think the most affordable way right now to monitor HDR is the Sony A95K oled, I have to check later wether I can manually switch it to PQ (i should be). Otherwise the LG 32E0950 works GREAT for hdr and does not need any metadata for sure.

Can you not just switch the dell to … PQ and output PQ from flame? I mean I have tested rhe dell before but I am not 100% if we needed metadata.

The other thing that many calibrators are talking about is that calibrating for HDR modes on most displays is next to impossible, apparently the way to go is to use the default SDR mode and then create a lut to make it HDR, this requires the monitor to have high luminance in SDR modes. (because you can mostly not bypass the tonemapping stuff). This seems to make sense to me.

One thing that you can do however is to inject hdr metadata with something like a HD-Fury, my old murideo (8bit only) lutbox also triggers hdr on my tv with a button,

Another thing is dual monitoring of SDR/HDR, how resolve does it , is to use 3D left/right , left image is hdr, right image is SDR, maybe you could whip ip something like that in flame also. Its very buggy in resolve though. But thats also how DolbyVision mapping to SDR works but its kinda useless if you dont have trims… so it depends

I found it generally better to just make a downmapping lut from HDR to SDR using resolves colormanagement nodes and use that in a lutbox downstream…

Sony consumer monitors have a very simple menu to just choose your color space and HDR mode. LG’s have a secret menu to do the same.

1 Like

I checked with my friend that has the dell and he says you can just flip it to PQ there is no metadata needed for grading/monitoring at all in any case, so flipping flame to to PQ output should be all thats needed to get HDR from flame via decklink.

Thanks @finnjaeger. Last time I tried it a week ago, I did switch the monitor, but it only ever got SDR signals from Flame. Must have done something wrong on the colorspace / broadcast config. Thought I double check everything, but will try that again.

if you habg out in discord when trying , hit me up it should be straightforward, in the end PQ is just a flat looking image there is nothing special about it :smiley: (rec2020 transfer matrix is a thing though but anyhow)

Right, I was going by the status display of the monitor. It said ‘HDR’ on/enabled but signal status remained on ‘SDR’… I was referencing Grant’s DolbyVision tutorial for all the color space settings.

On location today, but when I’m in the office tomorrow I’ll try again. Might hit you up on Discord if I can’t figure it out. Always appreciate the helpful answers :slight_smile:

1 Like

Just documenting an offline discussion we had yesterday for other folks finding this thread…

My problem was in the monitor menus. On the Dell monitor it required more extensive settings in the menu to configure it manually to the proper color space (ST2084PQ/Rec2020/L1000). With that in place it behaved properly.

Another hurdle was finding a matching broadcast color space in Flame. There is Rec2020/P3/D65 but no Rec2020/ST2048PQ. By label at least. Apparently the choice that’s listed as 2100PQ is the correct one.

I have one last issue to solve in the next few days. I see an HDR image on the monitor, I have switched the scopes on the second display to HDR mode where it uses nits on the scale. Scope color space is set to match broadcast color space. Yet, on the nit scale, everything is still stuck below 100nits on the scope.

Ideally I’ll find some way to verify the verasity of my HDR color pipeline, knowing that that file I have is shown in SDR with tone mapping on the UI and in HDR to proper nit scale on the HDR display (all via ACES ODTs). Right now more things look right, but that may not make them correct though. Especially since in this case we’re overriding monitor settings instead of relying on meta data, making it important to verify things.

The Flame learning channel has unfortunately become all to quiet (we know why), otherwise it would be fantastic to get a tutorial that covers setting up a HDR workflow soup to nuts and verifying that it actually is correct. There is an older Dolby Vision episode, but it is more focused on DV of course and has some gaps. From the messages on this board it seems a decent number of folks do HDR work, and there are more starting to. So this seems like an appropriate topic.

1 Like

Its actually rather simple, and you have all the pieces, should just work now.

there is no metadata that you would need, just like with atmos you are just sending a PQ signal without metadata to the screen, all processing and tonemapping is done by you in flame not by the monitor.

only benefit is that resolve would send metadata to trigger hdr mode on monitors, funny enough only on consumer stuff on the hx310 you still need to manually enable hdr iirc.

Only thing you want to check is what the display is actually capable of and to disable things like tonemapping, this is pretty essy to do, just send a white frame at 2000/5000/1500 NITS and see if it makes a difference (without any ODT/colormanagement) . it should not - if the monitor correctly clips at the given max lumiance of 1000. this issue also usually applies more to consumer TVs.

thats really about it. HDR isnt that magic, the aces 1.1 HDR/SDR transforms are not very well matched though so its normal to see a pretty large descrepancyx

1 Like

It seems you hve mostly had your questions. Feel free to hit me up with anything via DM.

I did this a few years ago, not sure if it helps or not

It seems to me that a few people are struggling with the setup behind HDR?

2 Likes

Thanks, I hadn’t come across this one. I just scanned it, and it looks like it may fill in the gaps. Will watch in detail.

In theory it’s not hard, and I’ve done HDR in Resolve and Mistika before. But it always takes a bit to find all the settings in each software, but more importantly also to make sure that they’re producing a proper color-managed workflow. It shouldn’t just look like it, but be right.

It is amazing how much you cannot cover in an hour so if you have any questions that I didn’t cover then please let me know.

1 Like

We’ve been running into similar issues, and this thread has been great to at least confirm that it is how the Flame outputs the signal, rather than an isolated issue.

Running a Flame SDI output to a suite with a Sony PVM for the operators ref, and then converting out to HDMI for a domestic OLED for the client ref. The PVM is fine as it can be set to ignore any input and be forced to HDR. The domestic runs into the issue of not changing over to ‘HDR mode’ without it recognising a tag on the input signal.

The way I’ve gotten round this in the past is using an AJA Hi5 for that SDI to HDMI conversion. The AJA mini config app can then be used to manually toggle SDR/HDR for the conversion.

Are there any thoughts of if this is something that Autodesk would look at? As has been said here, many other softwares handle this same situation without any difficulty

1 Like

You can put a HD Fury in the HDMI path to inject a HDR tag.

1 Like