I can also confirm all of the above bugs and have reported them to the development team. They are working on a fix, but it is a complex issue so it may be a bit before they can get it implemented and tested. Hang in there.

@Yelandkeil your screenshot shows it going well above 100 nits on the waveform monitor, it's only on the histogram that is shows it cut off... I can definitely get above 100 nits, but my issue is that the color and brightness blow out too easily if making adjustments to the exposure, and if you adjust curves, levels, or saturation too much, you get the random colored pixel noise/solarization the OP mentions.

There's a lot of work to do on HDR still. They are rewriting the video engine entirely, and this is one area they plan on fixing as soon as they can.

Everything can matter.

Using ACEScc, he can.

As far as I can tell, AP0 and AP1 are both wider gamuts than Rec2020, and AP1 actually more closely matches the gamut of Rec2020.

@Yelandkeil

But you are no teacher at all. Fact is, that by useing ACEScc it is possible to grade log footage with a luminance level up to 1000 nits. At least here it works. While we have a lot of issues with the HDR modus in Vegas, and a lot of points are true. But it is not true that you cannot grade the luminance higher then 100 nits, if you apply ACEScc.

Edit: the picture shown by frOsty shows it quite well - you can grade the footage also with APEScc. Even if I would prefere the even wider gamut from AP0 - but that is what we have today.

I addition, I have a fine HDR preview on my HDR monitor. But what I have seen some minutes ago only, is that Vegas Pro 22 seems to allow to enable an HDR preview only, if you start Vegas on an HDR monitor. That is new maybe - in the past it was only necessary to enable HDR on one monitor in your system I think.

Whether I'm a teacher or not, my business.

What is not your business it to tell users, who are looking for support, the points going in the wrong direction. It is possible to grade HDR with Vegas today, even if there are some shortcomings.

Whether you will break the rule or not, your business.

I do not see which rules where broken by me.

@fr0sty, discussing color/space seems a number higher to me, send you 🌷🌷🌷.

And then you know that we cannot use ACEScc? I use it, and at least that works. But as said, there is still enough to do.

I have had no problems with HDR10 footage in Vegas at 1000, 2000, and 4000 nits. I have tested VP 18-21, but not VP22.

Note: The Youtube player for the example below matches the HDR10 spec exactly only at 2000 nits, not the Vegas default of 1000 nits.

I can probably locate the source files if someone would like them for personal use. I believe they match the ST2084 format specs perfectly.

I can also confirm all of the above bugs and have reported them to the development team. They are working on a fix, but it is a complex issue so it may be a bit before they can get it implemented and tested. Hang in there.

Thank you for confirming they are known defects. I actually forgot to mention another one I have seen in VP21 where the scopes stop working in HDR and the program requires a reboot.

Just for reference for anyone else interested in seeing visually what I have written about here are two clips. The first clip made on VP21 shows the block sky issue. The same clip rendered on VP22 now also has sparkly pixels all over the image.

Since the defects are confirmed, I am not looking for any help with this. I'll look for other solutions for HDR.

Vegas 21:

https://drive.google.com/file/d/1jM7Sa82imwubq7L4YQNktZt8QoUbP1Si/view?usp=sharing

Vegas 22:

https://drive.google.com/file/d/1h0hESoDd3h_pI2hn_6NFlHqCMdGGpsqj/view?usp=sharing

Where exactly do you read, that ACEScc cannot be used for HDR??

While the ACES gamut is wider, the ACEScc works at the moment.

 

Vegas 21:

https://drive.google.com/file/d/1jM7Sa82imwubq7L4YQNktZt8QoUbP1Si/view?usp=sharing

Vegas 22:

https://drive.google.com/file/d/1h0hESoDd3h_pI2hn_6NFlHqCMdGGpsqj/view?usp=sharing

Without access rights, nobody will be able to download that to support you.

And which one is the original footage? Would be great to have that too, to support you.

And as said - we need the footage specification too.

Color space doesn't, as you mention, define intensity of light.

Rec2020 contains the full gamut of colors needed to represent 10 bit 1000 nits (though it's still possible to have 10 bit rec709, you're just going to be limited to a smaller palette of colors to choose from for those 1024 shades).

Rec2020 and AP1 are pretty much completely identical as far as the gamut they cover, as the image I posted above shows. If AP0 was required, then Rec2020 would not be capable of HDR10 either.

 If AP0 was required, then Rec2020 would not be capable of HDR10 either.
 

Unfortunately, @Yelandkeil still does not get that.
 

But still posts wrong points, like this:

Without the AP0 no HDR10 video. 

what is simply not true.

AP0 is a theoretical color space far wider than any display can show. Having a smaller one is easier to deal with for color correction (fewer out of gamut colors to confuse you) and there's no reason why you can't map from AP1 to Rec2020 (or Rec 709).

ACEScc uses AP1 wide-gamut set of primaries and a logarithmic transfer characteristics, which means the control representation is more proportional to visual perception —a desire of traditional color-correction operators. This encoding can be internally used for color grading/correction

https://acescentral.com/knowledge-base-2/aces-working-spaces/

Once again, a messy conflation of standards and formats has crept into the discussion, making further comments meaningless. A moderator may wish to close the thread.

HDR10 ST2084 and OpenEXR ST2065 are different standards and different formats. No obvious relationship between the two exists, except that they are both registered with IEEE.

Why should we close a thread, where @Andrew-Stevenson, a user - who pointed out issues in Vegas in a clear and fact oriented way - asks for help?

Why should we close a thread, were possible solutions were mentioned - but then disturbed by a „theoretical discussion“ without enough foundation about the wideness of different gamuts?

Instead of focusing in the discussion to a pragmatic solution for this user? Instead of testing suggested solutions, reviewing the results?

This behaviour is ridiculous. No, I will not close this thread. Simply, because it could be that @Andrew-Stevenson may be still interested in discussing and testing suggested solutions. Up to him if we can try something with his v-log footage.

And everybody else, who cannot contribute here anything to a solution, should avoid to post here now any more.

My query was answered by the acknowledgment at the top that these are known defects awaiting resolution.

Would be great if Magix could implement new features or codec/hardware support without taking a wrecking ball to the existing feature set.

Thanks to all who replied.

Would be great if Magix could implement new features or codec/hardware support without taking a wrecking ball to the existing feature set.

This unfortunately is the curse of working with a 20+ year old code base... turn a wrench here, a spring flies out over there. This is why they are rewriting the entire video engine from the ground up currently, but that too is going to come with its growing pains. However, once completed, these issues shouldn't be a problem anymore, and upgrading stuff shouldn't easily break other stuff.

What @fr0sty states is correct. The video engine is under rework.

And yes, there are issues with HDR grading in Vegas. But my experience with vlog footage from my EVA1 - and you mentioned vlog in earlier threads- is, that it can be graded in the actual version. At least here, and if one avoids some pitfalls:

1. what is broken is the ACES default color space, true. Results in a 100 nit clipping also in the waveform monitor. But switching to ACEScc allows still to grade vlog. Maybe not ideal, but it works.

2. what is broken is the internal HDR buttom in the preview window - here the side ratio is not maintained if one enables that. Together with

3. what is broken is that the waveform monitor freezes, if one disable this internal HDR buttom. Requires to disable and enable again the scopes.

2 and 3 means for me, that it is clever to avoid to use the internal HDR buttom

4. Many of the adjustment bottoms in color grading portal are for log footage much too sensitive today. Even small movements may result in clipping. So perform small movements only - by holding STRG during the movements.

5. The preview on a secondary HDR display works - but you have to enable in Windows the HDR mode before you start Vegas. New to me is, that this seems to be required on both monitor 1 and 2 (earlier it was necessary only on monitor 2 here. Maybe a difference is, if monitor 1 is HDR capable. Still exploring that). So enable the HDR modus.

With this points it is possible to grade vlog footage here. Also BRAW footage.

What I have not seen so far are coloured pixels on transitions (I tend to use no transitions), or that the secondary HDR preview (with the GPU and HDMI to an external HDR monitor) crashes completely. Will be important to see that, to be able to test that for upcoming versions.

I've demonstrated the default space is broken on my NVIDIA systems with no CGP in use. ACEScc works. This is for non HDR modes as I lack such a monitor.

@Yelandkeil

you seems to be unable to reflect the findings by other uses, even if they are so experienced as Roger is. Similar, you seems to be unable to accept if 3 other experienced uses tell you, that ACEScc can be used for HDR grading. Not easy to understand, but it is as it is.

Seems to be that you have not tested the logical combinations in the project settings of an HDR project:

1. ACES-Default + CGP applied - clipping at 100 nits take place
2. ACEScc + CGP applied - no clipping at 100 nits take place.

Your conclusion cannot be confirmed on my machines, nor on Rogers system. And - iI the filters in the CGP would be broken, then they would not work fine with ACEScc. But you can test by yourself easily.

Unfortunately, your personal struggle to fix the HDR bugs makes it impossible for you to even consider such possible solutions (which is unacceptable when user asks here for help). As much as I want these bugs to be fixed too, but you know exactly that they work on that.

 

RogerS wrote on 8/21/2024, 2:30 PM

I've demonstrated the default space is broken on my NVIDIA systems with no CGP in use. ACEScc works. This is for non HDR modes as I lack such a monitor.

This findings by @RogerS are that same that I see on my nvidia based systems.

A workaround I have found to the above problem when using the Default(ACES2065-1) colorspace is as follows;

1. Create your HDR10 video using the Default(ACES2065-1) colorspace and View transform to "Rec.2020 ST2084 1000 nits (ACES)"

2. Open the Color Grading Panel with your video selected

3. Open the HSL Tab and move the luminance slider to around 1.400

4. Toggle the HDR Preview button "On" and "Off" three or four times. Ensure the Preview is "Off" after toggling.

5. Deselect your video so the Color Grading Panel is disabled.

6. Reselect your video at a different spot on the timeline.

7. Your video scopes should be black at this point. Turn your video scopes "Off" and then "On" again.

8. Turn the HDR Preview back on and Happy Editing.

This method works consistently on my system. If this did not work for you, I would suggest repeating the procedure.